Copyright: 2008
Publisher: Addison-Wesley
ISBN: 978-0-321-50936-9
"Emergent Design: The Evolutionary Nature of Professional Software Development" is a must read for anyone in the software development field. Whether you are a manager, a developer or a consultant, this book will help you view the profession differently. Scott does an incredible job of being a down-to-earth visionary... someone who can see things clearly from 50,000 feet, but has the technical legs to stand on the ground and look the code in the eye. What follows here does the book no justice but is a limited compilation of nuggets gathered from the book.
What is is all about?
What is software development all about? What is this profession that I work in really trying to do? Where did we come from to get where we are at? Scott manages to supply answers to these questions without seeing to struggle with platitudes and lofty language. At it's core, software development is a profession but so far it has not seen itself as one nor has it behaved as one. Scott argues convincingly that we need to get our act together and start acting more professionally.
Scott points out that software projects fail far too often. But in order to understand what failure is, we must first know what it means to succeed. He offers these benchmarks for success:
- Software is ready on time
- Software costs what it is supposed to cost
- Software does what it needs to do
- Software is not crippled by bugs
- Software gets used and makes a positive impact
Some Notes
- Business communication is about human interaction and this is inherently lossy
- The lesson of Pandora's box is not that Hope is good.. but that it is the greatest of evils
- Object Oriented principles came out of some of the best principles of procedural design
- Small methods
- Encapsulate / protect the data
- Patterns themselves should be flexible
- Need to understand them well
- Need to know forces and constraints
The Great Coupling Debate
Take any two object oriented programmers at random and chances are they disagree on some aspect of coupling. What constitutes coupling, how much coupling is bad, the best way to decouple your code... just forming a list like this would be cause for debate among some programmers.
Scott has a different take on coupling. He points out that while most developers talk about "loose" and "tight" coupling when they debate, these terms aren't very useful. More useful terminology would be "intentional" vs. "unintentional" coupling. His point is that you cannot avoid coupling entirely. So when you have coupling in your software, it should be there on purpose.
Unfortunately this part of the book is one where I had to wonder where Scott's editors were at when they read this chapter. Don't get me wrong, he was right on with his notions of coupling in software... but his entire example of "Driveway Coupling" made me cringe.
In short, Scott talks about buying a car and finding out that he couldn't put the car in reverse. When he called the dealer he found out that there was an interlock that kept you from putting the car in gear unless your foot was on the brake. Scott wrongly interprets this as "poor coupling". He reasoned that "the brake system and the transmission do not, logically, interconnect." His thought is that what the engineers really wanted was to keep people from having the gas pressed when they put the car in gear so they should have put a sensor on the gas pedal, not the brake pedal.
In reality, what the engineers wanted to ensure was that the car would not start moving unexpectedly when the transmission was disengaged from "park". If you put your car in neutral by accidentally bumping the lever, your car could roll down a hill without ever touching the gas pedal. Since small children can't reach the shift lever and the brake pedal at the same time, they can't accidentally start a car rolling down the driveway.
Why the editors let this get printed is beyond me... surely editors aren't just glorified spell checkers are they? :)
More Notes
- Difficulty in testing is indicative of problems in your design
- Perspectives in OO
- Conceptual - What am I responsible for?
- Specification - How am I used by others?
- Implementation - How do I fulfill my responsibilities?
- If your sub-class adds public methods, you are no longer polymorphic
- Separate creation from use.
- If an interface changes, you should change either the factory or the client, but not both
- Encapsulate by Policy, Reveal by Need
Conclusion
Quite honestly, most of the books I review on this site I do not own. This is one of the ones that I have access to, in fact because of my generous boss we have two copies of this book in our office. I believe every software shop, whether you are an Agile shop or not, should have at least one copy of this book around. If you have developers who are struggling with the switch from procedural to object oriented, get them this book. If you have developers who are struggling with wanting to "do their own thing" and prove their worth as a programmer, get them this book. If you have developers who simply want to be better at what they do, get them this book. Ok... enough said, I liked the book!