Big Data/Analytics Zone is brought to you in partnership with:

Mr. Lott has been involved in over 70 software development projects in a career that spans 30 years. He has worked in the capacity of internet strategist, software architect, project leader, DBA, programmer. Since 1993 he has been focused on data warehousing and the associated e-business architectures that make the right data available to the right people to support their business decision-making. Steven is a DZone MVB and is not an employee of DZone and has posted 138 posts at DZone. You can read more from them at their website. View Full User Profile

Legacy Code Preservation

04.22.2013
| 3308 views |
  • submit to reddit

Rule One: Writing Software is Capturing Knowledge.
Consequence: Converting Software is Preserving Knowledge.

When software is revised for a new framework or operating system or database or when an algorithm is converted to a new language, then we're "converting" (or "migrating") software. We're preserving code, and preserving the knowledge encoded.

For the next few months, I'm going to post some examples of preserving legacy code and how this ties to the knowledge capture issue.

Once we've looked at some examples of business software, we can turn to something a little less concrete: HamCalc.

These examples are presented in historical order. Each example raises questions and outlines elements of a strategy for legacy code preservation.

  • What's the Story? Late 1970's. What user story was encoded in the software?
  • Are There Quirks? Late 1970's. Is the encoded knowledge really a useful feature? Or is it a bug? What if we can't be sure?
  • What's the Cost? Early 1980's. What if the legacy code is complex and expensive? How can we be sure it doesn't encode some valuable knowledge?
  • Paving the Cowpaths. Throughout the 80's. When converting from flat-file to database, how can we distinguish between encoded user stories and encoded technical details? Isn't all code equally valuable? There are several examples; I've combined them into one.
  • Data Warehouse and Legacy Operations. This is a digression on how data warehouse implementation tends to preserve a great deal of legacy functionality. Some of that legacy functionality exists in stored procedures, a programming nightmare.
  • The Bugs are the Features. Can you do software preservation when user doesn't seem to understand their own use cases?
  • Why Preserve An Abomination? How do we preserve shabby code? How can we separating the user stories from the quirks and bugs? There are several instances, I've used one as an example.
  • How Do We Manage This? The legacy code base was so old that no one could summarize it. It had devolved to a morass of details. With no intellectual handles, how can we talk about the process of converting and what needs to be preserved?
  • Why Preserve the DSL? describes a modern instance of "Test-Driven Reverse Engineering" where the unit test cases were created from the user stories and the legacy code use merely as supporting details. An entirely new application was written which preserved very little of the legacy code, but met all the user's requirements.
These nine examples include some duplicates. It's really more like a dozen individual case studies. Some are simple duplicates; the name of the customer is changed, but little else.

Published at DZone with permission of Steven Lott, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Hikari Shidou replied on Mon, 2013/04/22 - 6:52pm

 Interesting, I wanna read this series!


It hates me how managers and customers wanna decrease costs and schedules during software development, and then they will never want to remake it! If the software will live so long, it sure is worthy invest in quality during its development!

The sole idea of "preserving" legacy software is a sign of trying to not spend on it. A software that doesn't work anymore, its useful life is gone, it should die, but they never wanna invest in quality... How much do they spend in user bad productivity, many times in desease caused by bad software...

In last decade they used to say that COBOL was more reliable than newer languages. Today I totally disagree with that. Java has evolved (and got full of deprecated junk...), and languages like it free developer from handling memory and other stuff that are fail prone. Newer languages like RUST will enhance resources management even more. And hardware is so powerful today that a custer is cheaper and more powerful than old mainframes.


Better than trying to keep old software alive, we should work on remaking them. Get those old developers that created it while they are still alive and full of knowledge, to some great requirement gathering on experient users, use greatest best practices on Software Engineering. The result will be taking out every good knowledge from the software and its stakeholders, ppl who have used it for decades and understand very well its SWOT attributes and can point exactally how to enhance it! And then, develop a great software, with never-seen quality, cheap to use and maintain, aimed to live for way long decades!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.