Codephobia

Grady Booch had come to Manchester for a couple of days last month and I’d gone for his talk about "The promise, The limits, The beauty of Software". There were several interesting themes explored, but it was one comment made by him, almost in passing, which really struck a chord with me

He mentioned how he’s seen organisations which seem as if they’re afraid of code and that jibes with what I’ve noticed as well. An organisation or project or team which is completely tied up with process, to the extent that almost nothing can be done without reams of paper being produced, is usually a victim of codephobia. Before a single line can be written or modified, several Word documents will have to be either produced or updated, items in the project tracking system will have to be massaged, meetings will have to be called, recalcitrant team leads will have to cudgelled into submission and developers will have to be dragged to their seats – their nails leaving deep groves in the carpeting as they go.

Now mind you, this isn’t the usual screed by frustrated programmers against the horrors of ‘Process’. The ability to track, managed and control a project is vital to it’s success. However, smart, successful firms realise that all of these things are a means to an end. The customer wants a working application, not reams of design documents and lists of tracked defects. All of these are meant to enable you to write code better and faster.

This simple concept however, seems to be beyond the ability of many people. They act as if the various artifacts of process adherence were what the customer was paying them for and not the actual application. At heart, it’s all about being afraid of putting pen to paper - of producing the code - because that’s when the inadequacies will start to show and the incompetence will start to bubble to the surface, like marsh gas from a bog. In other cases, it’s the managers fear of the unknown. Most project managers are code-illiterate and so fear what they cannot understand or accurately track. They understand documents though and are happy to lose themselves in them. They’d love to have people code in Word if they could. Notice the popularity of code generators in such teams. It’s a dead give away :-)

In any successful team that I’ve seen, the focus is completely on the code. Everything is subservient to it and team is made up of and lead by competent programmers. Only a minimum amount of ‘process’ is tolerated and it’s all about knuckling down and churning out working code as soon as possible. Codephobic teams postpone code generation to the last moment and have to be dragged to their compilers kicking and screaming…

Which is kind of poetically just, because that is exactly what their customers end up doing when they see the end result.