10% Coding and 90% Thinking or Just Code It 10 Times

There seem to be two minds about how to write code: in one you spend most of your time planning and thinking about what you are going to code (thinking/coding), and in the other you code as quickly as possible and then start over or refactor several times until you get it right (coding/multiple).

I have seen the good and bad in both points of view. I tend to prefer the latter however and over times it's been good far more often than bad.

Businesses that produce software, whether in-house IT or for-profit products, tend to operate in a pressure environment. Whether driven by market forces or internal politics they often demand the worst of both approaches: plan everything in advance but do it fast and you only get one chance. One place I worked had a project where the deadline for the software completion came before the deadline for the requirements document. Needless to say the project was a failure!

What tends to happen when you try the second style is that people hate to throw out code that they have written and thus fail the idea that each new approach is a different thought based on the failures of the previous one. You've written a ton of unit tests and documentation and so starting over, or doing a major refactoring, is unpalatable and hard to explain to management. So you take a wrong approach and continue down that path to failure.

In the first style the typical problem is being able to identify the issues and solve challenges when you have nothing but thought balloons to go on. So much of what I've worked on is new territory and it is doubly hard to imagine all the problems you will find in the future when you don't know what it will be like. Writing a General Ledger for the 10th time is easy; writing something that no one has ever tried is a different animal. It's easy to write some long design document and then discover in your last 5% of coding time that what you wrote isn't possible.

In some ways you can characterize a Waterfall as the common theme for the first approach and Agile as the second, but it's not really that simple. Thinking/coding could be done in iterations, or coding/multiple each round could each be an entire Waterfall.

In corporate IT thinking/coding is far more common as it seems more manageable but often gets so formalized that most projects never get coded successfully. The coding/multiple style scares management that time is being wasted in rewrites.

Personally I like to minimize the thinking time and spend more time refactoring/rewriting the code until it works correctly. I've also found that despite the worries of management at the start, having visible progress early on where feedback can be gathered and incorporated makes people feel better. Getting feedback from a customer with a 100 page requirements document full of UML is unlikely.

I think the Agile concept requires a little of both styles and gains the benefits of both. Finding organizations that understand this and support it however is still pretty rare.