The Underlying Key to Working Effectively with Legacy Code is...  READING LEGACY CODE effectively.

Only then can you proceed with the key premise of the book… turning legacy code into code that is completely tested at the lowest unit levels. 

I have 5 millions lines of legacy code… and I’m okay with that

Reading legacy code and documenting what you learn as you read it.

Yep - the building blocks for working effectively with legacy code are reading legacy code, thinking about legacy code, and writing down what you learn. 

 

For yourself. For future you. For others.  

 

Once that is in hand, for any part of the legacy code, you proceed on with test writing, refactoring/restructuring/rearchitecting as needed. 

 

Here’s the cool part… even if you don’t write tests… understanding your legacy code before you touch it… IS REALLY USEFUL! 

How we read and understand our 5 millions lines of legacy C++ code…

We wrote a tool… it’s called Understand.

 

As I read the book I realized I’d spent the last 2+ decades working on the key skill the book required.  In a bit of dog food eating karma, we use Understand to maintain Understand. Day in and out, our engineers can’t imagine using anything else. And because we maintain (i.e. read and try to understand our legacy code with it)…  it’s pretty darn good at it. 

 

You can try Understand for free. And you should. Runs on Windows, Mac, and Linux.

How’s it different from my current IDE?

Understand  is aimed at reading, browsing, and understanding legacy code.  Most IDEs are about generating code, code colorization, and some have debugger intergration. 

 

Understand, at first glance, looks like other IDEs. Code colorization. File browsing. Auto-completion.  But… under the hood (and via the power of click synching and information pushing)…  

Understand  optimizes reading and thinking about legacy  code, knowing exactly what is connected to code you are reading.  It’s for grinding down connection chains, learning, and then backing up to where you started to start on the next line. 

 

We use it for VIRTUAL DEBUGGING where you step through code thinking about it, then backing up and thinking more down other paths.  

 

That’s how you understand legacy code. It’s how you fix bugs. It’s the start of all refactoring. It’s… the knowledge building process of doing safe maintenance of code.    This is all based on our unique and hard to do Hyper-Xref technology. 

Document as you learn

As you learn about your legacy code, you can use Annotations (like Word or Google doc post it notes) to document what you learned. 

 

Along the way, as you explore, document Architecture from the bottom up as it is actually built  (versus as intended) - and share that with all, and get what they discovered too.  Turning no architecture into shared, understood, and useful legacy code architecture.

 

This is just the tip of the iceberg about what Understand does to help you think about our code… just download it and try it.

We don’t just sell it… we USE it….

Every day, all day, our engineers understand our legacy code with Understand.  They don’t have to, we do not require it, but they do.  Oh, sure they might have their favorite debugger interface (for live debugging VSCode or maybe Xcode), or to pop back into EMACS and kick it old-style… but they all, happily, have Understand running for when they have to knuckle down and understand what they are trying to change. 

Next step… trying it is free, and it’s not expensive

You can download it here.

 

Or if you want to talk to somebody first, no sweat, we LOVE talking about legacy code:  Stephane Raynaud is a legacy code god. And you can talk to him about your legacy code problems. 

Oh yeah… cost…

About $80 to $90 per month, or as I like to explain it… About what you cost for an hour of legacy code reading.  And your understanding of that legacy code just got a LOT BETTER. 

 

And that’s not even factoring in the cost of an actual bug that leaks into something important - like the airliner I flew in JUST TODAY that landed hard, stopped mid-runway, and the pilot announced “Computer bug, we can’t steer the aircraft, we are gonna get towed”. Bugs are expensive!

Just Say Yes…

Need more ammo? See my other article… “Just Say Yes” about how most money in software development is spent maintaining legacy code, and that getting software engineers maintaining your legacy code the tools, perks, and support they need is good for your business, reasonable, necessary, and the right thing to do.

Thanks for reading.

I’m the President of this venture now, pretty busy, but if you want to reach me to chat about legacy code, or what we can do for your organization’s legacy code troubles… email me Ken+blog@scitools.com.