Your first ****** stinks!

I know some people admire decisiveness and sometimes it’s justified and valuable.  Other times making a rash decision is going to cause nothing but pain.  I’ve seen this come up lately in regards to both designing software and estimating projects. 

Design 

At my previous client the team “lead” was very intelligent and creative.  In the face of any development challenge he would almost instantly determine a solution and issue marching orders to implement that solution.  One little problem.  He almost always chose a complicated solution instead of continuing the search for a simpler solution.  Udi calls himself the Software Simplist and I used to think that was an odd title, but now I get it.  Paradoxically, achieving simplicity in software design is hard.  There’s a simpler solution out there, but it isn’t necessarily obvious.  Getting fixated on an early design and going full steam ahead without continuing to look for alternatives is a dangerous attitude.  So very often the best design ideas do not present themselves until the development is underway.  Being able to pull simplicity from a complex seeming development task is definitely something to strive for.

In 2001 I was on a project that was mere weeks from going live when I realized that there was a way to eliminate a lot of repetitive code in our web reporting by making some of the reporting metadata driven instead of hard coded.  I completely freaked out my project manager by making the changes so late in the game, but the change paid for itself when we got some last minute requests that we were able to accommodate because of the refactoring that I had made.  I’d been studious about designing each piece of the software as I went along, but I still didn’t have that particular idea until I had some tangible feedback from the code.  Being able to implement that late breaking design change enabled us to deliver more business value in later releases.  I still think it was one of the best decisions I’ve ever made.  The lesson?  Your first cut at a design, no matter the effort level you put into it, isn’t necessarily your best idea.  There’s a simpler solution lurking out there.  You’ve just got to keep looking for it. 

This article about the brain processing these Aha! breakthroughs was interesting. 

Not that long ago we had a series of arguments on the ALT.NET lists about upfront versus evolutionary design.  One of the upfront design proponents accused myself and others for having Attention Deficit Disorder by jumping into coding early without “careful” research first.  I think he got it exactly backwards.  The design hat needs to stay on all the time to look for opportunities to make improvements as you learn more about the code.  Only designing upfront is the truly irresponsible path.

 

Estimation 

I’m in Phoenix this week doing marathon planning sessions to build our story backlog.  On Monday we wrote stories for an enhanced replacement for an existing COBOL product.  We came up with 50+ stories.  When I was asked for a first glance estimate I said a large number.  It caused some consternation because it looked like plans needed to be changed.  The next day I spent some time going back over the stories to do the story point estimation (I’m a developer army of 1 until Chad comes on board).  What I saw was a lot of commonality between the stories.  When I started to do a little preliminary tasking I found some ways to combine cards.  That project suddenly didn’t look quite so big.  Granted, the mass majority of times your estimate is too low, but after that exercise I brought the estimate down quite a bit.

Just to recap that lesson, you’re first estimate always stinks. 

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 http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.lostechies.com/blogs/joe_ocampo Joe Ocampo

    Found this while browsing, thought it might apply:

    Einstein’s words might be applicable:

    “Everything should be made as simple as possible, but not simpler.”

  • http://www.lostechies.com/blogs/joe_ocampo Joe Ocampo

    >The design hat needs to stay on all the time to look for opportunities to make improvements as you learn more about the code. Only designing upfront is the truly irresponsible path.

    That about sums it up! I don’t care how hard you modeled or thought through your code somewhere in there is a simpler design. So everyone….think simplicity. :-)

  • http://chadmyers.lostechies.com cmyers

    The mountain is already being created before me, I see :) I better start sharpening my shovel

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Donn,

    In theory, we moved to the NYC area because my wife had enough of Austin summers. We’ve decided that a little heat was a silly reason to move away from where we were otherwise happy.

  • http://blog.donnfelker.com Donn Felker

    Ahhh… welcome to Phoenix…. I see you visit us when its “nice” outside. This is our “Summer” time. Come back in 7 months… :) But… then again, you’re back in Austin (if I’m correct) and it gets nice and toasty there too. :)

  • http://ww.bluespire.com/blogs Christopher Bennage

    Regarding the argument between BDUF and evolutionary design: I did presentation a few months back at our local code camp on using TDD, and one of my points was one using TDD to discover a better (simplier) design. I had a heckler (yes a real one) who really criticized that idea, and his “excuse” what that he is able to see solutions quickly.

  • http://grabbagoft.blogspot.com/ Jimmy Bogard

    Gotta say, when you use asterisks, it makes it look like you’re bleeping out a word. Short path to a word that fits quite nicely, too.

    I think that’s why feedback is one of the primary values in XP. It’s the acceptance that the first pass probably won’t be the best choice, so drive feedback back into the process to drive improvement. Lots of folks have a fear of change, so designs stagnate instead. Hard to improve without change, though.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    My goodness, I’ve been visited by a gleeman.

    You should have some sort of feedback early to know your estimate needs to go up or down as you go. I’ll blow the surprise and just tell you right off the bat that your estimate stinks.

  • Thom

    Although you won’t _really_ know that your first estimate stunk until you’ve finished the project. But let’s not jinx it. :)