My latest article is up on MSDN magazine for August, and this will be what finally gets me kicked out. This time around I tackled some subjects very near and dear to my little developer’s heart: Incremental Delivery Through Continuous Design
I talked about why incremental delivery maximizes business value, then moved onto how you can approach the process of software design. I discussed:
- The Last Responsible Moment — always a great way to start a low grade flame war. It’s a very important I think you should really, really contemplate.
- Reversibility — Can you change your mind later or add on to existing code later, or do you absolutely have to get it perfect the first time through?
- YAGNI and the Simplest Thing that Could Possibly Work
- Ordering Code Construction Tasks
– Work vertically by feature! Don’t schedule your development in terms
of infrastructure or technical layer. Everything follows from a
business goal. - Balancing predictive (upfront) vs reflective design. I.e., UML modeling is all that and a bag of chips, and design does NOT stop after that first line of code.
- An analogy between software design and pull vs push supply chains that did not impress my buddy Ward Bell, but you just can’t please everybody all the time;)
More Links
A Microcosm of Agile Design
– but, but, but Web Services are easier than they used to be. I don’t
care if it’s easy to build a web service. It’s still more mechanical
work to build a Web Service than a library that runs in process with
the rest of your code. The automated tests run slower if there’s SOAP
in there anywhere, the deployment is a bit more work, and it’s just
more friction all the way around.
Is Design Dead? – Martin Fowler in one of the most quoted papers of all time
Think first, ‘doing’ is for later by Frans Bouma. As usual, I think Frans is almost completely wrong about everything and fairly shortsighted, but it’s still good to consider alternative points of view. In my world order “thinking” and “doing” should never be completely separated. The value of feedback cannot be discounted, and the value of upfront analysis can easily hit a point of diminishing return. Even worse is the fac t that upfront analysis and design in absence of real feedback has a bad tendency to be wrong. And Frans, don’t try to characterize this as “I don’t do any upfront design.” I do indeed do some upfront design, even with TDD (and TDD is a design practice too). I do not just vomit code onto the screen and hope refactoring can solve the problems.
Oh, and Frans is wrong about the importance of SOLID too. The best way to do design well doesn’t have much to do with your choice of upfront processes or adaptive approaches, it’s how much the designer knows about software design. The SOLID principles or design patterns or the GRASP patterns or refactoring from anti-patterns are all lessons learned by our industry over time. Thinking about these good design principles while you are formulating a design is a great shortcut to making a usable design. Learning SOLID is a lot easier than deriving best practices from first causes all by your lonesome. And that statement applies equally to Frans’s predictive design approach as it is to my more reflective design approach. The fundamentals of design are useful to anybody who does design.
While I’m at it, Frans is also being short sighted about TDD as well. One of the best things about TDD is that it makes you think about how to implement the details of your code, and I’d argue that’s in a good way.
Go ahead an argue with me, that was more or less the point of the article.
