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.

Comments (6)

  1. Mark Mullin says:

    Interesting post

    I’ve always thought that the degree of separation between test and development is inversely proportional to the complexity of the system. As any system approaches infinitity in it’s universe of hardware,os, and dev tools, it gets real hard to tell test and devt apart.

    I once worked on validation of core numerical and 3D library suites at Taligent where we tried an interesting approach (yeah, I thunk it up, so laugh all you want)

    We created a series of genetic algorithms to exercise most of the basic functions and set their fitness criteria as a function of the bugs they found. After a month or so of fiddling about, those little monsters could find edge cases real quick 🙂

    I only bring this up to argue for meta-thinking. One graduates from randomly banging out code to planning out code, however the journey can continue on into meta levels. I can test explicitly, I can learn more and realize my edge cases all involve infinities. I can also write a program to explicitly (randomly) discover that log() based functions don’t like zero, and then to attack my whole math library with this little factoid —— I don’t think the journey ever ends

  2. Sahil Malik says:

    Sounds like the story of my life :).

  3. Jason Haley says:

    Some more interesting finds this week

  4. Geetika says:

    One small bug in your article.

    "most critical test details tto more formal modes ", should be "most critical test details to more formal modes ". There is a small spelling mistake.

    Sorry for pointing out, but me being a tester, could not stand the bug.

  5. The Braidy Tester says:

    Thanks for the catch, Geetika! It’s fixed now.

  6. Jerome Groopman's book How Doctors Think is about doctors and how they think. It is also about testers