The cost of dead code

Once in a while I see this situation on the street. Thrash alinged around a garbage bin, somebody did an attempt to trow away his thrash but was too lazy to finish the job. 'Close but no cigar', so somebody else has got to finish the job, which in essence costs energy (and money).
In my job as a Software Architect I come across this behavior also a lot of times. Once in a while I've got to dust off an old application and investigate what the possibilities are for modernization or revitalization. Modernization ot revitalization comes down to, what can we do the extend the lifetime of an application for a couple of years more, and also be able to add agility, stability and new or changed business requirements to the application. It also helps identifying the roadmap for the future of the application. To make the roadmap for modernization there is a list of things to investigate, size of the application, the context in the application, complexity of the code, (future) business needs but also the amount of ´dead code´ in the application.
What is dead code? At one point in the history of the application functionality was removed or changed, but the actual code itself is still available in the application. For instance, a procedure which is not called anywhere in the application, a page which is removed from the menu, old functionality which is commented out, database objects that are not used anymore but still contain data etc etc. What you see here is scared or lazy behavior, scared as in 'I'm not sure if I removed or changed the right code', lazy as in 'I don't want to spend too much time'. The result is that the application is becoming like a jungle, you get lost in the dead wood. Making a change is getting more and more costly as a result of the increasing dead code. So let's change our behavior in the maintance phase, if functionality is not needed anymore just throw it away, like you would do with thrash in a garbage bin. When a proper versioning system is set up, you always can find the history back.

Ever had the feeling that you are an Information Archaeologist?

How many times do you have to find out what the functionality of a systems is and what the data means? A lot of times you come to the conclusion that the documentation is not sufficient or (most of the times) not available, and that the people who've build the system are long gone. The only thing that remains is "The Code is the Documentation". Well then you end up in what used to be so neatly called 'reverse engineering'. Actually what we are doing then is the modern form of Archeology. Scraping layer by layer of code, data and applications in order to understand the true meaning of the application landscape. The Software Archeology excercise is mostly done when we being asked to rebuild an old application into a new landscape. Most of the times we put developers to work who are trained in new technologies, but have got no clue whatsoever about the old technology in which the application is build. The result is that these teams are recreating over and over again the 'Stone of Rosette', or the key to translating the functionality from the code. We tend to forget that the system is not only build based upon functionality but also about what the technology enables and what the strenths and weaknesses are. So for instance the reason why procedural languages are used in heavy batch applications (performance....) only comes to live when the application is rebuild into an Object Oriented application, resulting in bad performance. So the AS-IS situation of a landscape, and all the reasoning behind it, is almost as (or even more) important then 'the Future state to be'. The roadmap towards the Future state to be is the task of a (Software) Architect who knows not only knows the 'New technologies' but has a strong background in the 'Old stuff' and all the reasoning behind it. Only then can we move towards a Stability Based Architecture (SBA).

Aim for Stability Based Architecture (SBA)

Software Architecture is the art of translating Business needs into a suitable and working technical solution.
The same as in architecting and creating houses our sponsor expects that the product will be stable and last for quiete a time. Looking back in time we see that at the time of Cobol, applications were able to last more then 20 years (and even now exist, even after the retirement of their creators). But with the speed of new developments and the coming of hype driven development the application lifespan (or time that it gets outdated), is getting less and less. Java, among others, has got a bad reputation in this area, for instance Struts lasted some 2 to 3 years, after which you were the laugh of the year when you decided to choose Struts in your solution. SOA is another example, finally it paid of working with it, when somebody decided that SOA is dead and we have to run after the latest hype, Cloud computing. The half-time of a Software Architecture is getting shorter and shorter, and it happens too often that at the time of go-live we almost have to think about upgrading, because the version is almost outdated.
I'd like to propose a new architecture type, Stability Based Architecture (SBA), in which we aim for stable (core of the) application and add an expected life-time of the application. The core of the application should be stable and last for a long time, just like rock under pressure, it folds but doesn't break. Only then can we justify the costs of implementation.