When I first heard Ken Schwaber’s talk I thought wow, exactly, he’s right, we don’t have a chance, the end of the world is nigh.
When you have some central piece of software that many other projects rely upon, that central track is often pressed into delivering features earlier than is good for the software. As a result, you get software that
- is fragile
- has no good test harness
- has few developers left
- is hard to use and build
Ken Schwaber calls this “Design Dead” Software. Implying: throw away, don’t reuse any more, open source or sell.
…but couldn’t you say the same about any piece of code? Some simple facts: Overstaffing a project is not an economic idea. The power to change things in unforeseen ways implies the power to break things – the difference being made by the developer’s understanding of the consequences. The ability to understand code depends not just on the code, but on the newcomer’s background knowledge. What remains “magic” depends on your willingness to understand, which to a large degree is a social and personal thing. Something that is easy to use the way it was designed, or the way it is implicitly used by its fans, may be very hard to use in a different way or for a different purpose. A test harness appears especially bad if you don’t understand what it tests, or if it does not test the cases you consider relevant.
Which, to me, means that a “central” piece of software essentially poses a knowledge management problem. Personell turnover is inevitable in the long run (be it because of boredom or because of high pressure at the “center”), so there will be new people with fresh views coming in contact with the code – which, if not organized very carefully, causes the kind of friction described above. Also, stability is of high concern at the center, so it may be difficult to take new or current architectural ideas into account (there are limits to what refactoring can do). Which, again, might make it less attractive to work on (someone else’s baby). Old software is most probably “Hype Dead Software”.
Providing and maintaining a framework, platform, infrastructure appeals to software people because abstraction is their daily bread. But don’t fool yourself: it requires a long-term commitment, and in the end may be more about duty and reliability than about fun. And it’s an open question whether the problem you have abstracted and solved will actually be relevant, and will be considered relevant and valuable, long-term.