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.