Five worlds and the industry
Joel didn't attempt to guess at what percentage of developers are actively engaged in each "world". I wonder if anyone has any actual data on this.
My gut feeling is that very few (certainly less than 10%) of working developers are writing shrinkwrap software. I'd strongly suspect that more than 60% of developers are working on "Internal" software (that which was written for one customer, never meant to run anywhere else, either by in-house or contract developers).
The current craze here in Silicon Valley is for "appliances" (primarily storage), so there's an upsurge of "embedded" software being written, albeit often on Linux on PC-class hardware with flashable firmware, rather than an OTP 32K pager.
The economics of the various worlds are very different. For the internal world, there's no distribution or packaging costs, but also no direct revenue to offset the enormous maintenance costs. Projects get re-written from the ground up often to give the developers something to do, and to keep their skills "current" (move from C to C++ to Java, from terminals to "client/server" to the web, etc). This is rarely justifiable on real business grounds, but it happens regularly, anyway, usually with empty promises of better productivity for the end users.
Tuesday, May 7, 2002
"Projects get re-written from the ground up often..." 90% of my developement experience (or about 10 year) has been spent doing internal development and I've *never* seen a project re-written for any of your reasons. The only time I've seen rewrites/reimplementations is when the program/system is so creaking old that it's about to fall apart and has become totally unmaintainable (or they've lost some source code, but that's a different story).
Tuesday, May 7, 2002
I think you've just proved my point. Code doesn't rot, corrode, or age. The idea that code has become "unmaintainable" is the usual excuse given an unnecessary massive rewrite. Very rarely, this is actually true, although more often than not, it's a reason to rewrite the whole thing in some shiny new language or new architecture, or whatever.
What's really needed it most of these cases is a refactoring job, where the more spaghetti-like aspects of the codebase are fixed. Still a big job, but it's not a clean-sheet rewrite.
The typical scenario is one where the old developers have left, and the new developers would rather rewrite than do all of the code archeology required to actually understand what it is they're trying to re-invent. 9 times out of 10, if the project ever gets finished at all, it's no better than the original in ways that matter (end user productivity).
I have come across one case where so much was bad about the original system (bad architecture, bad implementation, bad cost structure, lots of long unfixed bugs) that scrapping it probably would have been the better way, but this is one single case out of dozens of projects I've been involved with over the years. And even in that case, a major refactoring could have fixed the bulk of the problems. About 40% of the code would have been re-used.
Tuesday, May 7, 2002
Actually, my main point is that I've *rarely* seen internal software reimplemented - for any reason (much less for the 'lets use the shiny new tool' reason).
Unmaintainable is a Point-Of-Sale system written entirely by contractors with non-technical internal management. They were allowed to run wild - they were allowed to write their own screen library/file handler/network layer because they claimed that everything on the market was unsuitable (and, of course, billed big bucks doing so). If it would have been decent code, it would have been OK but they did things like using the 'extra' memory on CGA video cards for storage since they only used text mode. This was obviously done quite a while ago, but the system still exists and is in use because large chucks were thrown out and re-written from scratch.
Wednesday, May 8, 2002
The big rewrite of an old system that I've seen occured because the old system became unmaintainable.
Not because the code was bad, but because the platform became unsupported. e.g. A few hundred lines of COBOL code running on a VAX.
Thursday, May 9, 2002
Fog Creek Home