Debugging programs into existence

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?

Whiners vs Entrepreneurs

What do you do when the smelly stuff hits the fan? What goes through your mind when users are having problems? Do you whinge, whine, and say things like: "Damn those pesky lusers", or something equally insulting? Perhaps you see an opportunity in the making to shine, or make the user's day better?

It seems that the IT camp, much like American politics, is a two party state.

On the one side are the “Whiners”, those people who think the whole world should operate according to their rhythm. They hate having to deal with problems, especially if they are the cause. A problem is something that must go away, either by dropping it on someone else's lap, or redefining it as a “system” issue that cannot be fixed, or just ignoring it. And when it cannot be ignored, then whine, whine, whine and whine some more. Maybe, they will be forced to do something about it, in that case, something gets done; quickly, dirty and not necessarily fixing the problem but the annoying boss, user, or whoever wielding the whip is satisfied. For goodness sake, they have work to do, and interesting problems to work with, like that Rails 2.0 application, or optimising the database to squeeze an extra 10ms out of it. Important stuff. Whiners do not always whine out loud, but they will do anything to avoid having to work on stuff that is “boring”.

In the other camp, are the “Entrepreneurs”. These guys love problems. Every problem is an opportunity to make their life and the lives of all those around them better. By making the client happy, they gain a good reputation. Problem happens, opportunity happens, and stuff gets done. These people realise that without problems, there cannot be solutions and IT is all about solutions. There is a reason that entrepreneurs do well, they are not afraid of getting the job done, and are willing to take the time to do it well (even though that is boring). Theirs is a career, not a “job”.

Which are you?