Waiting for the paint to dry, in software development

I am actually waiting for the paint to dry in my bathroom right now.

C and I Did Some Stuff to the bathroom of our new house two weeks ago. We thought we should have the contractor paint one wall a contrasting color after they ripped out, you know, the Stuff, and as part of replacing the Stuff.

This turned out to be a really bad idea for several reasons:

• It was slightly the wrong type of paint.  This part was a case of imprecise specification on my part; C got high-gloss enamel rather than semi-gloss enamel.
• Partly because it was the high-gloss, every non-expert brush stroke showed on the wall.  This part was a case of lack of training on the contractor's part.  See below.
• As it turned out, we hated the new color anyway.  This part was a case of user interface design needing full acceptance testing before the job could be considered done. 

That's okay, sometimes it happens.  We're agile enough to deal.

While I was re-painting this week, I had some time to think about my long-ago training in house painting, and how that training distinguished my paint job from the contractors'.

The name of the old painter who passed along the advice I'm giving you here was named Art Fuller.  I kid you not.  What a great name for a great painter, and he was a wonderful guy too.

The contractors were in a hurry. I don't blame them, and their rush was partly on my behalf. They were trying not to go over time and not to bill me for more than our quote. 

They told me (with the assurance of the very young) "This is great paint, it covers really well.  We can do one really thick coat, you won't need to do any more.  One thick coat is almost always better than two thin coats.  We're really laying it on here." 

They were laying it on in more ways than one, as it turned out. The one thick coat painting theory showed up in the results: messy and obvious brush strokes. We'll not belabor the part where they ripped off the masking tape while the paint was still wet, in an effort to be "done-done" before they left.  Everybody likes closure on a job.

Art Fuller was never in a hurry, at least not so much that it showed.  And Art always said "Two thin coats cover better than one thick coat, no matter how good the paint.  And make sure you give the first coat time to set.  Go do something else while you wait!" 

Of course, Art was right. 

I didn't have much paint left of the color that we were going to use as a replacement, so I put down a really thin first coat.  This new color was also a much lighter color than the very dark tone we had chosen before.  Still, two thin coats did beautifully.  If I hadn't really liked the new color, also, I would have had the time to sit and consider my next step.

What does this have to do with software development? 

A great deal, or so it seems to me at the moment.  (Feel free to tell me it's just the paint fumes <g>.)

Don't belabor your first design.  If you see flaws as you work to implement it, that's okay.  Don't patch over them and don't feel the need to implement every last detail.

Give your design time to set, consider it in full.  Give your users some time to consider it, at this early stage, too.  Don't be afraid to acknowledge that it's not complete.  What you hear may be dispiriting if you try to rush to fix everything right then — don't.

Work on something else before you finish. I'm sure you have something else you can do; you won't waste this time. Come back to this feature or this module later and do a real second pass, when you're fresh and have energy for it again. 

You'll end up adjusting more than you would have changed in a single pass, but you'll have a better product.

We're often in a hurry — often with our customers' interests in mind. But we had better not let it show.  Two thin coats take very little more time than the one thick coat would have taken, and they may possibly take less, in the long run.