Happy life with Legacy Systems
I want to give you a little introduction to my latest InfoQ article on Technical Debt, which I wrote together with my former colleague Eberhard Wolff. We work with new, small and cool systems, but also with large and old systems (= these systems were really valuable over many many years!). Large means 50 to 500 men years resulting in several millions lines of code (LoC) using hundreds of database tables. Old means, that some of these systems have been started in the last century and still use technologies like Visual Basic 6, EJB 2.x, Struts 1.x, PL/SQL or XDoclet, and are connected to COBOL-based systems, just to name a few things which were cool 10-35 years ago, but are now seen as cruelties if you have to add features to such a system.
These systems have also seen many developers come and go, developing good stuff and, especially under time pressure, bad stuff. All these systems have a reasonable amount of Technical Debt (which is unavoidable). While working on these systems, we found that the usual “Technical Debt is a disease” complaining strategy is neither helpful nor correct. Some architects deal very well with this problem, resulting in 10 year old systems, which are still in a really good shape. Other architects didn’t deal well with it, so the development of business-critical systems really slowed down, sometimes whole development organizations come to a stand-still. The problem is then, that you cannot throw away a 2 mio LoC business-critical system and develop it anew. That’s too expensive and too risky. You have to pay the interest of Technical Debt in terms of slow delivery of features. This shows, that not only developers suffer under Technical Debt, but also the business side, who waits for features a way too long. In fast paced environments, that can almost kill businesses!
In our InfoQ article we give you a nice overview what Technical Debt is really about. We found a surprisingly long list of of stakeholders – a software developer is only one of many. After explaining various ways how to identify Technical Debt, we head to the most important part: how to effectively deal with it. We give practical advice by debating the pros and cons of various successful strategies. Finally, we show when it could be useful to just pay the interest, to do debt conversion or to pay back the debt. We think, if you deal with large and successful (=old) systems, you should have a look at the article and leave us and the community your thoughts for further discussion.
