One day I was playing around with putting together a document and I realised something; when I started the spec as a blank page, I did not think of a plan or decide on what I needed to do, I was in a rush and staring at the page, almost angry with it's blankness. I looked at the page as if the emptiness was a bug and I needed to put something there to fix it. So I started with a paragraph along the lines of what I had to say, wasn't the best but it did the job. From those few lines, I added some text above and then below. Did some refactoring and pasted a section from another document. Slowly but surely, the document took shape until it was ready.
The document was a simple thing, just a high-level overview but the way I put it together reminded me of the type of code that I often see, code that works but looks like it was the result of some nuclear explosion and it dawned on me; that code was not written so much as debugged into existence. The programmer started with some code, then added some code around that, fixing bugs as they go along until the program works. Not quite TDD but its cousin from several incestuous unions.
Now don't get me wrong, these programs do work, but the code quality depends on the mind of the person creating it (ie is the mind organised enough to plan in realtime in the right direction?), the size of the solution and the complexity of the problem space.
It is possible to produce quality code without planning but that is very difficult to do and very few people can pull it off. A better way is to think about and solve the major issues but implement using agile methods so no big planning but not going in blind. I personally like that way of doing things but it does not always work out as I expected (some corner cases and gotchas that my simple plan did not uncover). For certain problem spaces, nothing short of a full plan will do; YMMV.
Do you produce programs by debugging them into existence?
Tuesday, August 19, 2008
Subscribe to:
Posts (Atom)