20050712   

File Under: Geek Speak

Michael considered fate at 13:36   |   Permalink   |   Post a Comment

For you regular readers, this will be either a bore or make no sense or you won't give a rats ass, so you might as well skip it. However, if software design and creation methodology is something that peaks your interest, tune in:

I was reading about The Joal Test: 12 Steps to Better Code today and I ran across this tidbit, where Joel tries to figure out why programmers are pretty lazy spec writers:

I'm not sure why this is, but it's probably because most programmers hate writing documents. As a result, when teams consisting solely of programmers attack a problem, they prefer to express their solution in code, rather than in documents. They would much rather dive in and write code than produce a spec first.

And I have to disagree with him; strongly. I am clearly labelled a developer (aka programmer) at my current place of employment and therefore I am in a position to offer up an opinion on this:

I dislike doing that which I am not rewarded for.

As a programmer, I am expected to write code, develope new features, and fix idiosyncracies in the software (I hesitate to call these issues bugs because, truly, very few are). I am not expected to, nor appreciated for, writing specifications. Even simple feature documentation goes mostly unread. I am not playing the blame game here, either, but when I speak of being "rewarded" I am speaking as much about job satisfaction as I am about co-worker appreciation. There is little, if any, satisfaction in creating tools (reqs, specs, docs, etc) that no one will ever use (and, consequently, no one knows you created).

Certainly, there is a unique set of variables in play at the company I work for. Each software house has it's own way of doing things. Some implement piles of security, others have stringent guidelines on what new code can enter a source tree, still others create mounds upon mounds of documentation for each line of code that is modified or added. The bottom line is that everything does not work for everybody. I highly doubt there is a single software group in existence that incorporates all of the management and housekeeping processes published and that's because they simply can't. Some of these processes even contradict eachother.

The key here is to find what works for you. Blindly implementing 12 points on a list or converting to the latest developement paradigm will not give you the best productivity or quality. Stop, think, listen. DO identify the weak points in your processes and address them. DON'T change something that already works for you.

As a great example, let's look at source control. If you operate well without source control then there is probably not a need for it. I've worked for small software companies (less than 10 developers), some of which used Microsoft's SourceSafe, some of which used the free CVS, and this last one that I currently work for uses NO SOURCE CONTROL. This might sound scary but the truth of the matter is: it works. Of the companies I have worked for it is the most efficient. The lack of source control actually works for me since it's least intrusive to my coding and debugging, and the way us coders interact with eachother, we rarely if ever step on eachother's code. The problem at the other shops I've worked for was constant source control database crashes, incorrect versioning, confusion as to what versions contained what bug fixes, and a lot of reading update comments to make sense of things.

This isn't an agruement against source control. I think it's a very useful and powerful tool. It's far superior to manually maintaining multiple versions of software. But it doesn't mean it works best for everybody. I'm sure some people would disagree, and they are welcome to.

I think the thing to remember is that there is no hard and fast rules in this business.

A few things I definitely did agree on from Joel's 12 steps (although certainly not the only things):

Debugging GUI code with a single monitor system is painful if not impossible. If you're writing GUI code, two monitors will make things much easier.

If your compilation process takes more than a few seconds, getting the latest and greatest computer is going to save you time. If compiling takes even 15 seconds, programmers will get bored while the compiler runs and switch over to reading The Onion, which will suck them in and kill hours of productivity.