Don’t think you know more than you do

On the train this morning I was working on my DevTeach talk about doing design on an Agile project.  I’m trying to explain the concepts of the Last Responsible Moment and delaying technical commitment in terms of Lean Programming.  Part of the theme of my talk is simply to not do anything that you don’t know that you need to do.  “If we do task A now, feature B will be easier later” is an example of speculation, not knowledge.  It might turn out to be a good decision, but do you really know for sure that you’ll actually implement feature B?  If feature B doesn’t actually get built, you might have wasted effort building extra complexity in the form of hooks for a feature that never gets built.

You need to be very cognizant of the difference between “I think designing it this fancier way will help in release 2…” and “we could reduce some duplication if we abstracted the XYZ like this.”  The first statement is an idea that you keep in the back of your mind.  The second statement is something to act on.

Don’t ever let yourself believe that you know what the business wants or needs more than they do.  My poor colleague just got hit by an example of this.  He’d built some nontrivial functionality to interpret trade prices in a new screen to match a specification from our client’s tech lead.  You can probably guess what happened as soon as an actual business person saw the screen for the first time today.  Needless to say, my colleague just started rewriting the implementation of the trade price interpretation (20 unit tests worth of code).  It’s good to know the business domain, but don’t fool yourself into believing that you’re the domain expert instead of the business.

I built a couple complex features this summer that have never, ever been used in production.  Same story, same team lead.  When I finally started talking to the end users (and knowing enough about the domain to actually understand what they were talking about) I found out quickly that these features were more or less useless to them.  The business problem we were trying to address still exists, but the real solution was to make part of the screen behave more intelligently to speed up the entry of Trades.  We blew it by assuming that we knew what the business needed.

If it isn’t entirely obvious, I’m not in an Agile shop at all at the moment.  We’re doing the engineering practices, but the project management isn’t there.  I think one of the biggest advantages of Agile is turning the software development process into more of a “Pull” mechanism instead of the traditional “Push” model of linear waterfall.  I don’t try to guess out what the business might want or find useful.  I’ll make suggestions, but the final decision still has to be from the business.  If the business is setting the priorities then you’ll be building features according to an established business need.  You can cut waste by only designing the software for the features the business has already requested (how you keep the doors open for later features is a much, much bigger discussion some other time).


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.
  • Alex

    I feel like I used to try and “outthink” the business, to be one step ahead to offer some idea they had not considered. In some cases, I would design my solutions for this. Like you mention in your post, I was anticipating the next idea and trying to do too much.

    Now, I feel like I try the opposite. When the business comes to me with an idea and we brainstorm it, I come back to them with something like, “If we did this instead, it would require less resources and we can deliver it sooner. Then we can then determine if the customer finds it useful?”

    I would much rather spend the extra effort designing for a year out when I know the idea the business provides will not be throw away code. So I try to do less up front until we prove the concept. Of course, there are times when I do not have this luxury.