August 12, 2005
Follow me on Twitter

Is Software Development Getting Better?

Is Software Development Getting Better?

Here at Eastgate headquarters, much of this week has been devoted to paying down some long-term technical debt we've accumulated, in the form of a monster class that handles the interface between text windows and the underlying text engine. Over time, this class accumulated a ton of responsibilities. It displays links in several ways, on several different occasions. It pumps text and images between Storyspace and Tinderbox and the text engine. It keeps track of special link highlighting. It adjusts links as you edit the text around them.

It's much too big, and it needs to be ported to Windows where many underlying structures are different. It's hard to test, so it's difficult to refactor.

It's been a big project, but it's gone surprisingly well so far. No disasters, no rollbacks, and no spectacular failures. There's never been a point where the whole system is lying on the floor in pieces and we're just hoping we can fit everything back again. And that's a surprise.

Why hasn't this project, which I've been dreading for a year, been excruciating? One reason is simply that we're all getting better as this. Moore's Law has been speeding up our hardware at a predictable pace for decades, but progress in software development has been harder to predict. Many promising tools have broken in our hands, and others seem mired in ambiguity and buzzword compliance.

This improvement is one reason I worry less than some about preservation issues in electronic literature. Once we decide we want to keep a literary work, the cost of reimplimenting it on new platforms declines with each preservation step. Systems that used to be the sole province of the very top Ph.D.'s will be implemented by script kiddies in a decade or two. (The PAD people think they can reimplement HyperCard on four platforms in two developer-years, or 1/3 the cost of Façade; they don't explain why they think they can do it, but it's an interesting data point that they think so.)

I've been reading a book about Working with Legacy Code that defines "legacy code" as anything developed without test-driven development -- in practice, everything more than a year or two old. I'm a software trends skeptic, but the agility/refactoring wave does look like the real deal. (I thought structured programming was a bad idea, back in the day, so discount opinions appropriately).