Incremental Delivery and Continuous Design

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.


About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Paul Hatcher

    Regarding technical vs business priority I’ve found it useful to assign a number to both and then it becomes a discussion at the start of the sprint as to which tasks to schedule.

  • Choy

    In your interview on .NET rocks (I think), you talked about how the community was being viewed as angry and mean-spirited — that Scott Belware and others had created this atmosphere.

    This bashing of Frans Bouma seems pretty mean-spirited to me. His post was hardly “wrong about everything.”

    I mean like why are you attacking him?

  • Frans Bouma

    I don’t think you even have the slightest clue what I am talking about in my blogpost. I don’t say SOLID or whatever acronym used to group patterns isn’t important, I said it’s not THAT important, because (!) code isn’t the source of what you’re doing, in fact, it’s the last step of your process. I.o.w.: what you write in code follows what you already designed earlier, which is much more important. Or, in more layman terms: how you write the code (with whatever pattern etc.) is dictated by the algorithms you have picked anyway. Not the other way around.

    “As usual, I think Frans is almost completely wrong about everything and fairly shortsighted”
    Are you really convinced that bashing me with these first-grader flames makes you look smarter and a person who knows it better? Group all the bashing in those two paragraphs you wrote about my article and re-read it. Does that look like text written by an adult who tries to produce a well-thought out reply based on reasoning?

    I don’t think so. It more looks like a piece of text from a person who was personally insulted by an article about how *I* write software. How on earth can that happen? I didn’t even refer to you.

  • Jade

    Re: Thinking before coding:

    I actally clicked read your MSDN article (first) and then read Frans’s link that you posted.

    1. I actually don’t think you are that far apart, just based on just those two articles (new to your blog, so maybe there is more to this). Your topic about (sometimes) modeling first doesn’t seem that different from his article’s topic of thinking first.

    2. Also, his article seems to be more about coding complex tasks, i.e. algorithms that make up the core of a large system. I mean, if he’s saying that you shouldn’t write a loop without sitting down and thinking about it first, then that’s really bats**t. But I don’t read it to mean that.

    To a large degree, I don’t see how you can fundamentally disagree with his article, outside of maybe a few datails, like not thinking SOLID principles are important.

  • zvolkov

    Refreshing. “As usual, I think Frans is almost completely wrong about everything” and “I do not just vomit code onto the screen” are my favorite non-politically-correct statements of the month.

  • Rob

    Good article(s). I definitely like the concept of incremental delivery although I’m not sure if we’re set up for it just yet. As you mention it’s difficult to do.

    We need to move away from primarily working on the trunk in my opinion and look at using branching more often. In fact I’d like to branch per every feature, have it fully developed and tested, then merged into the trunk. This has it’s own set of problems, but means the trunk is stable and always in a releasable state which fits more closely with incremental delivery.

    Task order is a difficult concept too, and comes down to the situation. Business priority is the guideline, but a team should be reactive to change or problems, and pick the solution that provides the most value. Sometimes that isn’t order of business priority.

    There’s also the ages old problem of skillsets. We have UI developers, but if there’s no UI work the team may lower their commitment. The team should react to this, and should talk to the product owner, weigh up the options and pick a solution that offers most business value. That may still mean doing the current work, or changing it slightly.

  • Michael Hart

    Would be great to hear some comments on how you tie these approaches in with your project planning. Time/cost estimates for projects especially.

    Do you plan/cost x increments ahead? And how do you cost an entire project?

  • Ward Bell

    You won’t escape MSDN’s clutches that easily; certainly not with a well-written, harmless essay like this one . I might even have thought that you had only the familiar pews to preach to.

    Ah but then there is Frans whose post I read again after you reminded me of it. Not sure how he does it. Smart as a whip yet perenially pointing in the opposite direction of whereever I am headed … a compass pointing south.

    Regarding task ordering, I agree 99%. There are corner cases. I have heard it argued, persuasively, that one should tackle early the tasks which pose the greatest project risk. These are not always the ones that the business would put first … or even know to care about. But the technical implications of some business requirement may be so disturbing that you had better make sure of your footing before long.

    That’s the “eat your vegetables”, “do your homework first” school of thought. Follow it and you may find you are tackling some infrastructure ahead of features. The contrarian in me had to bring it up … if only to solicit your views. To your fundamental point, let’s not make a habit of it. Go vertical.