Slow And Steady Wins The Race

When I was a fresh-faced programmer I was the fastest codeslinger around. I could spew code out like nobody's business. I didn't need to bother with design or spec'ing. You want a program to do what? Bam! Here it is. Something not quite right? Bam! Here's a new version. Still not quite right? Bam! Here's an update.

Luckily my manager and mentor showed me the error of my ways. Not to mention that I did a most excellent job of codeslinging my way into a vast morass of incomprehensible and unmaintainable spaghetti code. Making mistakes is the best way to learn, and I certainly did a lot of learning during that time!

It takes me a lot longer to write programs these days, but without question they are much better designed, more easily maintained, and more correct once I do get them written. The net time between starting and achieving what the customer wants is shorter, too. Steve McConnell says that he would be suspicious of a developer who always looks busy, and I agree. I used to always look busy, and I actually was busy - busy recovering from my lack of planning! Coding may not take much forethought, but developing certainly does. One signal I use to tell when one of my team is ready to progress from apprentice to journeyman developer is that the amount of time they spend thinking versus coding flips from more often coding to more often thinking.

I find that this holds true for testers as well. A brand-new tester just starts banging on their app without any forethought. This will find the most egregious problems but not much else. As with developing, a little planning goes a long way. Poking around your app is still useful, but first plan your attack. Don't poke at random but rather target specific aspects. Stay on target, too; as you run across interesting issues outside or tangential to your area of focus, write them down rather than chasing after them right then.

Exploratory testing is a great way to get a handle on an area, and it can be a very effective technique on its own. However, if you treat it as advance scouting and take some time to use your findings to draw up an actual test plan, you can take your testing to the next level.

"Spend time planning" does not necessarily mean "generate lots of documents". Agile developers make a point of traveling light, doing just-in-time modeling and designing, using lightweight documentation such as digital snaps of whiteboarded designs, and committing only the most critical models to more formal modes such as UML diagrams drawn in Microsoft Visio or some other tool (letting the code speak for itself otherwise). Likewise, agile testers do just-in-time feature investigation and test designing, use lightweight test planning, and commit only the most critical test details to more formal modes such as test specs, letting the test code speak for itself otherwise.

A developer or tester who spends more time thinking and less time doing isn't necessarily a good one, but one who seems to always be busily banging away on their computer is almost certainly not being as effective and efficient as they might appear. All else being equal I'll take the thinker every time.

 

*** Comments, questions, feedback? Want a fun job on a great team? I need a tester! Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. Great coding skills required.