The Old Joel on Software Forum: Part 4 (of 5) - Perfectionism and systems design

Perfectionism and systems design

First: I'm a college student.

Joel's article struck a chord with my today. Where he tackles programmer perfectionism from one angle, and must defend his stance from others, I must defend against my own perfectionist tendencies. I have several warring entities jockeying for my attention every time I sit down to code--I am torn between two interrelated goals:

1) Get it done - simply, do what is required.

2) Satisfy OCD tendencies - refactor the function(s), design the data structures or objects/classes in a refactoring loop, ensure consistent file structures and directory structures, apply code documentation, ensure documentation thematic consistency, check variable naming convention consistency and/or standards adherence, and even crazier things. Crazy, like checking for NULL values for arguments passed to a C function that I only call from one other location, and the calling function will ALWAYS pass a non-NULL value; like rigid error-checking on text inputs on a homework assignment; like properly naming all controls on a VB form, including the lines and labels and things that are never programmatically used.

War party #1 ('Just Do It') is often raided and overwhelmed by war party #2 ('Perfectionazis'). The end result is paralysis--even as I refactor (or debug) the binary tree structure, I'm already thinking of more tangents[1]. When/if I finally meet (some of) the demands of war party #2, I'm often so frustrated that I stop coding altogether. And so I do.

Eventually, time constraints become an issue, and war party #1 subdues war party #2, pulls an all-nighter, and turns in the assignment. Which produces some very interesting code--half well-formed, tuned and pruned, the other half a loping, oozing zombie creature that throws its own limbs (or the code equivalent thereof).

At work, the same parties war, but as I am more familiar with the specific platform/problem domain, war party #2 is dominant only because their demands require no extra effort. In other words, I am so accustomed to doing it correctly, that I do so all the time.

It is only when I am learning a new algorithm, or designing a particularly large system[2], where I come into trouble. Then the parties war, the land is destitute, and I take a 'fifteen minute break' and go play Spider or (dare I say it) check Internet forums or Bloglines for new items of interest. Eventually, after some time, I will return again to engage the enemy.

So as Joel mentions the demands of others for perfection, this helps me at least express the troubles I go through. At some point in my future, I hope to resolve this issue to my satisfaction. Either I will become an expert in everything and code almost supernaturally well, or I will fully subdue the internal voices and will produce nasty, hideous code trolls (and I will feel fine doing so), or I will go insane and attempt to refactor my breathing habits (precisely eighty percent of airflow through the nostrils, but don't consciously THINK about breathing) and algorithmitize driving (never be the fastest vehicle on the road; predict other drivers' behavior; use rigid error-checking during all inter-lane maneuvers). Maybe I'm already insane.

[1] - Tangents, like 'I've used that same thing twice now. I should move that to a function', even though I know I will not use it a third time. Like moving a single boolean operation to a function so that it improves code readability:
http://weblogs.asp.net/OKloeten/archive/2004/04/14/113009.aspx

There are hundreds of these sorts of things. I only named a few that came to mind. Maybe I should fire up the IDE and try coding for ten more minutes. That will produce a bevy of material to draw from.

[2] - for small values of 'particularly large'

pds
Friday, April 23, 2004

I used to be VERY obsessive compulsive about code, but then I got a real job and had to get things done. I still like clean code, but I have had to relax my requirements out of necessity.

The one thing I have learned is that spending time making code nice and factored correctly is a waste of time BEFORE YOU'RE DONE. I used to do that stuff AS I was coding. But if you haven't actually made anything that is "finally" approved by the customer, you're just wasting your time making it nice, because the next thing you know, they change their mind, and you have wasted time on stuff not related the final product (writing the code that is thrown out is not necessarily a waste of time, it is just part of the process of creating something). Out of an hour of coding, if I have spent 10 minutes of time writing comments and that code has to be rewritten, I have just lost 10 minutes forever.

So I think it is most time effective to clean up code and document it properly AFTER it is reasonably "done". Though this does lead to a second unfortunate situation, where because of tight deadlines you never clean up the code, because it already works, and refactoring runs the risk of breaking it, and you have to retest it and such.

So I guess the only thing left is to either live with nasty code (which many do), or clean it up in the downtime between projects. Though that is less than ideal, because it is a lot easier to clean up code you wrote a month ago than code you wrote a year ago.

Roose
Friday, April 23, 2004