One more time

Nick Bradbury likes to dive into projects code first. He argues that many of the issues that he runs into while developing a new feature cannot be foreseen in a requirements or design phase, so all that work would have to be significantly altered once he did get to the coding anyway.

Eric Wise in Five Signs of the (Development) Apocalypse (thanks Assaf) gives some examples of over-designing from buzzwords. This would be humorous if it weren’t painfully true in past experience. Large projects seem especially prone to getting mired in the design process over points that have little or no bearing on the final product.

But innovative projects need to jump into the code even earlier, for a different reason. The key lies in Nick’s penultimate paragraph:

Here’s the fun part: a week or two from now, after I’m comfortable that the memetracker is working as intended, I’ll then throw the code away and start a more formal design approach. Cowboy coding is a great way to find problems, but it’s no good for commercial software – you’ve got to write well-thought-out code unless you’re willing to be buried in bug reports. So the goal here isn’t to complete a feature quickly (although that’s often a side effect), but instead to discover the gotchas up-front so you can design the feature correctly.

So you see that Nick’s code-first approach isn’t about skipping design work, it’s about prototyping first. Try out the concept to see if it can fly and where it will go. Then throw out the prototype and do it right.

Ken Lidster is one of the founders of Synergex and my long-time mentor. (Disclaimer: Synergex is one of my clients). Ken and I don’t work directly together often any more, but whenever I ask him a question I know that if he has a moment to think it over he will give me an answer that is so elegantly fitting that it will make me wonder why I didn’t think of it myself. I call those “V-8 moments”, from the commercials where the person knocks themselves in the forehead and says, “I could have had a V-8!”

Ken says that when it comes to implementing innovative features, the third time is the charm. The first attempt is filled with vision and excitement but usually fails to take some key dependency into account. The second incarnation learns from that experience, has a solid design, and accomplishes what you intended. But after you’re done with that and have a chance to reflect on all that you could have done instead, then you are ready to design and implement the feature properly. The key is to prevent the company from releasing either of the first two versions without being able to retract them at a later date.