One of the more interesting aspects of Macintosh programming is that you find yourself sweating the details. You find yourself spending a day or two sorting out NSViewAnimation in order to get your inspector window to open and close subsections gracefully. You find yourself worrying if “Lucidia Grande” is properly selected as the default font for a number of controls. You find yourself wandering how to create an anti-aliased box around a group of items in a tree view.

This fits very well into my theory as to the different levels of software development, and why I don’t think I want to work for a dot.com anymore.

At the bottom level are the business analyst programmers. Their job is to take data and write a program to generate a report–and in many ways this is the easiest sort of programming, since you are probably the only person who will ever run your program. The goal is not code elegance, but the report–and if you have to hack your code together in a mix of Visual Basic and SQL and a little Microsoft Excel bit fiddling, it doesn’t matter, since the product is the report.

Next comes back-end “enterprise” software development. Most of Yahoo!’s Panama system consisted of this sort of development. The audience for your software will either be analysts or internal people (such as Yahoo’s advertising editors and sales people); if a feature isn’t elegant or doesn’t quite work right, you just send out a memo warning people not to use the feature until the next version is rolled out. What makes this sort of development a pain in the neck are the number of Architecture Astronaut wannabes floating around who over-engineer aspects of the system because, well, because it doesn’t matter. (One component I worked on was broken into eight separate EJBs with elements using Hibernate–and the fellow who was nominally in charge of this code justified the design because of the “heavy load” the system would take. Nevermind it made the system impossible to debug or add features to–or the fact that at maximum load it may take perhaps 10 transactions a second, which, with a simpler design, could be handled by a modest box running MySQL…)

Next on the totem pole comes application developers who are releasing boxed software. The audience for this piece of software are end-users–and there could be thousands or millions of them: customers who just plunked down $49 or $199 or $499 or whatever, and they bloody well expect every bit to just work.

And at the top of this totem pole comes embedded developers, whose software could be used by thousands or millions of people and which must be flawless: the end-user doesn’t think he’s buying software, he’s buying a car or a television set or a video camera, and it’s not like you can send him “version 2.0” of his BMW 3-series car to fix a bug in the ignition timing software.

What constrains each level of software development is the audience: as the audience for the software increases, the need to get it right the first time goes up, and the ability to fix bugs “on the fly” goes down. And because the need to get it right the first time goes up, the need to properly manage the project also goes up: you cannot fix managerial mistakes (because you didn’t reign in your 20-year-old architect astronaut wannabe) by just pulling an all-nighter and rolling out a new version of the software. When you’re writing application software or embedded software, you cannot just roll out a new version tomorrow to fix the broken version you rolled out today.

That’s why I don’t want to work for a dot.com anymore. Because most dot.com software development is essentially enterprise development–and because the demand to “just get it right the first time” isn’t really there, you get a lot of mismanaged projects and a lot of screwed up politics which needlessly waste a shitload of time that could be better spent elsewhere.

I’d rather sweat the details today than deal with a “production server push” at 2 in the morning to fix some detail no-one bothered to sort out because, well, it just didn’t matter…