The key points of "Working Effectively with Legacy Code"

If the choice is thought to be between:

* delivering value directly to the customer to justify a company's existence

* or adding tests to things that already work (shore up) in an effort to make more correct changes in the future

Will anyone be surprised how often it's the former that management will go for?

I've found the appetite for this type of testability/observability improvement work increases proportionally with the number of support calls being made from customers complaining about the current feature set being unstable and buggy. This work is less palatable when customers really are just looking for that next new feature you promised instead and everything else is a-ok. The exception being things like orbital navigation systems etc..

https://martinfowler.com/bliki/StranglerFigApplication.html

This can be a superpower.

I once had to replace a PostgreSQL-interfacing layer of a large+complex+important system, and most of the original tests had been lost.

It's the kind of change that could be an existential risk for a company that needs the system to be available and correct.

So I built a comprehensive test suite for the existing PostgreSQL-interfacing layer, tested it, made drop-in compatible API using the new way to talk with PostgreSQL, tested that, and... the entire huge system simply worked with the replacement, without a lot of headache/defects/dataloss/ulcers.

> Before you change code, you should have tests in place. But to put tests in place, you have to change code.

Keep reading. You don't always have to do it in the heroic way the article described in this section. Modularity and backward-compatible interfaces, FTW, when you can. The "Sprout" and "Wrap" techniques that the article describes later.

Also, one complementary general technique that the article didn't get into is that sometimes you can run two implementations in parallel, and check them against each other. There are various ways you can do this, involving which really implementation really takes effect, and what you do if they don't agree. (Related: voting configurations in critical systems.)

> Characterization tests

The test suite not only let me validate the implementation, but the exercise of developing the test suite also helped me understand exactly what I should be implementing in the first place.

Sometimes I had to look at the implementation, to tentatively figure out the semantics, then testing validated that also.

> Use scratch refactoring to get familiar with the code

In reasonable cultures and with reasonable management, or if you don't tell anyone. Otherwise, it's the same kind of risk as the old "throwaway prototype" problem: someone with authority says "looks good; I told the customer/CEO we just need to make these few more changes, and ship it". Or, in popular Agile/Scrum processes, "I thought you already completed the refactor last sprint; why are you doing it again".

It is strange, actually, how much value we place on any information that sits between two pieces of cardboard.