The Codist

Like people, software has a lifespan -- eventually everything reaches a point where nothing works anymore and the end comes. Unlike people however companies often push software far beyond its natural life and keep trying to update it despite the ever increasing cost to do so.

This curve represents the lifespan of most applications. Early on there is not much code written and thus every feature is fairly expensive since it requires you to code everything new (though it can be much cheaper if you start with other people's code). As the application is shipped or reaches maturity, adding new functionality is fairly easy; the original programmers might still be around, the code is well understood and hopefully cleanly written and documented. As time goes by and people leave, documentation and code knowledge goes stale, and the code begins to get brittle the ease of creating new code becomes much more difficult. Eventually the code is so crappy every change is hard to test, every bug fix or new feature adds more instability and new bugs appear every day. At that point development slows to a crawl or features are cancelled by the bushel. Cost per feature becomes very high.

Now cost in this picture may not simply be the cost of development, it can just as easily be programmer burnout and turnover, customer frustration at poor quality and lack of progress, and even reduced income.

Note that I am talking about essentially adding features not simply bug fixes or basic maintenance. Some software rarely needs new features but in most cases due to competition, market pressure or simply the need to create new income you have to add to the application's feature set. The problem comes when the cost of adding (or the inability to deliver) new functionality reaches a point where it really isn't feasible despite the demands of management or the market.

Me and my team worked on Deltapoint's Deltagraph for 5 years from 89-94 during which we deliver 5 major releases for this market leading product. After all the changes including a port to Windows by the publisher, the C code was no longer very good and we wanted to redo the application in C++. At the time Deltapoint was making something like 5 million per year in sales so we thought it should have been affordable. The decided it wasn't worth the investment and we went our separate ways. Eventually they sold off the product and went into a different direction.

Now 22 years after the initial development the product is owned by Red Rock Sofware. During that time no rewrite was ever done, and I am sure the code is beyond ugly at that point. In fact the UI still has the same crappy icons I stuck in temporarily back in 1989! I can imagine the curses of all the engineers forced to work on this today. I don't blame them if they have a dartboard with my name on it. The number of new features added to the codebase since 1994 is very small compared to those we added in those 5 years; much of the application seems identical to my last checkin back then.

The SABRE reservation system was a marvel back in the 1960's. By 2000 the code was so decrepit SABRE had to hire people from Russia, as it was hard to find anyone in the US who still wrote in the IBM macro assembler it was written in. I heard stories where people would collect unused bits from various data structures to create new data items since they couldn't easily expand the records (might be just a story but it seemed possible). It took them something like 12 years to finally replace it but today the system is a modern SQL database based system.

It is very difficult to convince management that their software is becoming impossible to update. People like to think that all it takes is more or better or smarter programmers or something to change an old codebase. I liken it to trying to run a dead horse in the Kentucky Derby -- but no matter how much you want it the thing won't run.

People often fail to understand that rewriting an application may allow newer/better/faster technology; use open source or even purchased frameworks and libraries; and maybe simply have the opportunity to do things write the second time. Yes, I heard the saying "it's better to keep the old bugs you know rather than create new ones you don't" but that supposes your current team is more incompetent that the original. If that is the case then what are the odds they can successfully update the old brittle application?

Software can be successfully reincarnated as something new; it just takes an investment and desire to move your software back to the original start of the curve and then capture the easy middle. If you refuse you may have to pay the price and live with the consequences of being unable to be keep up with the market, piss off your customers and deal with the turnover of frustrated programmers.

Of course in a perfect world every application is written so well that it lives successfully forever. Sadly most of the software in the world is neither perfect nor will it live happily ever after. More commonly I would expect there are a lot of dead horses out there being kicked until the have some semblance of life.