I've had a great time closing out my work day the past two evenings reading The Mythical Man-Month by Frederick Brooks. I'm barely into the book at all (usually just take 5-10 minutes to relax after programming burn-out), but so far the lessons related are awfully good ones.

I'd originally shied away from reading this book because it was someone talking about writing the IBM System/360's software. But things obviously haven't changed much in 25-30 years. The talk is, so far, at a high enough level that visions of my current projects jump into my mind when, almost certainly, the author is thinking about his work in the 1970's.

Anyhow, one thing that Brooks points out right from the start is the difference between a "Program" and a "Programming Product". In brief, he says that the garage programmer is making "programs" and software shops are putting out "programming products". The latter is, by definition, something that is easily extented by anyone and is written in a "generalized fashion". It is also well tested with a variety of test cases. He guesses that this takes about three times as long to create as a simple program. I think that's a little short, but anyhow...

It's interesting to look back over the projects with which I've been involved over the last several years and notice which are programs and which are true programming products. (Brooks has another two types of end results for programming, but I'm going to stick to two for the time being.)

Most of what goes on where I work is the creation of simple programs. People get a task, in the past a "one-programmer-per-programming-task" sorta deal, and they went off and made it. When that programmer left, you were left with a sort of "cyborg without the cy". Nobody could quickly and easily take over the program because it hadn't been written in a general fashion for anyone to extend. There were few "objects" that could be picked up and extended; instead you had to get intimately invovled with the legacy code to add significant functionality (or to figure out the cause of a bug).

He's also gone on to show how adding more workers to a project simply doesn't work in a programming task, because of something quite similar. If you add someone to the mix before you're done with a programming product, you have to explain what it is that you're writing to this new person. That, with a myriad of other factors, makes new help on a project extend, rather than reduce, the time needed to finish a project. Voila, "mythical man-month".

So spam out, it's a good book.

Hang on, ah yes. If you've tried #develop and compared it to Microsoft's Visual Studio.NET, you'll see a pretty good example of a program versus a programming systems product (what comes after a programming product for Brooks). #develop has some great features (and I honestly haven't looked at its code; it could be very good), but usability isn't anywhere as close to being as good as VS.NET.

I like the concept of an open source IDE for C# (and when I start C# programming in earnest, I'm going to give #develop another good shot), but let's face it, some scary dude holding up a shirt just can't compete with Microsoft's VS.NET team when it comes to testing all the in's and out's of an IDE. Some things in #develop might make perfect sense to the people most closely associated to the project, but it's not as well-done overall as the behemoth VS.NET coming outta Washington state.

Labels: