Found in 28 comments
by W0lf
I've gathered all the book titles in this thread and created Amazon affiliate links (if you don't mind. Otherwise you still have all the titles together :-) )

A Pattern Language, Alexander and Ishikawa and Silverstein

Advanced Programming in the Unix Environment , Stevens

Algorithmics: the Spirit of Computing, Harel

Applied Crytography, Wiley

Clean Code, Martin

Clean Coder, Martin

Code Complete, McConnel

Code: The Hidden Language of Computer Hardware and Software, Petzold

Coders at Work, Seibel

Compilers: Principles, Techniques, & Tools, Aho

Computer Systems: A Programmer's Perspective, O'Hallaron and Bryant

Data Flow Analysis: Theory and Practice, Khedker

Dependency Injection in .NET, Seemann

Domain Driven Design, Evans

Fundamentals of Wireless Communication, Tse and Viswanath

Genetic Programming: An Intrduction, Banzhaf

Head First Design Patterns, O'Reilly

Implementing Domain-Driven Design, Vernon

Intrduction to Algorithms, CLRS

Introduction to General Systems Thinking, Weinberg

Joy of Clojure, Fogus and Houser

Let over Lambda, Hoyte

Operating Systems: Design and Implementation, Tanenbaum

Parsing Techniques, Grune and Jacobs

Peopleware: Productive Projects and Teams, DeMarco and Lister

Programming Pearls, Bentley

Software Process Design: Out of the Tar Pit, McGraw-Hill

Software Runaways, Glass

Sorting and Searching, Knuth

Structure and Interpretation of Computer Programs, Abelson and Sussman

The Art of Unit Testing, Manning

The Art of Unix Programming, ESR

The Design of Design: Essays from a Computer Scientist, Brooks

The Effective Engineer, Lau

The Elements of Style, Strunk and White

The Healthy Programmer, Kutner

The Linux Programming Interface, Kerrisk

The Mythical Man-Month, Brooks

The Practice of Programming, Kernighan and Pike

The Pragmatic Programmer, Hunt and Thomas

The Psychology of Computer Programming, Weinberg

Transaction Processing: Concepts and Techniques, Gray and Reuter

Types and Programming Languages, Pierce

Understanding MySQL Internals, Pachev

Working Effectively with Legacy Code, Feathers

Zen of graphics programming, Abrash

Original thread
by taude
This is a good high-level overview of the process. I highly recommend that engineers working in the weeds, read "Working Effectively with Legacy Code" [1], as it has a ton of patterns in it that you can implement, and more detailed strategies on how to do some of the code changes hinted at in this article.


Original thread
by yowlingcat
So as to be constructive, I'm going to reference a classic: Working Effectively With Legacy code [0]. Here's a nice clip from an SO answer [1] paraphrasing it:

"To me, the most important concept brought in by Feathers is seams. A seam is a place in the code where you can change the behaviour of your program without modifying the code itself. Building seams into your code enables separating the piece of code under test, but it also enables you to sense the behaviour of the code under test even when it is difficult or impossible to do directly (e.g. because the call makes changes in another object or subsystem, whose state is not possible to query directly from within the test method).

This knowledge allows you to notice the seeds of testability in the nastiest heap of code, and find the minimal, least disruptive, safest changes to get there. In other words, to avoid making "obvious" refactorings which have a risk of breaking the code without you noticing - because you don't yet have the unit tests to detect that.".

As you get more experience under your belt, you'll begin to see these situations again and again of code becoming large, difficult to reason about or test, and similarly having low direct business benefit for refactoring. But crucially, learning how to refactor as you go is a huge part of working effectively with legacy code and by virtue of that, maturing into a senior engineer -- to strain a leaky analogy, you don't accrue tech debt all at once, so why would it make sense to pay it off all at once? The only reason that would occur is if you didn't have a strong culture of periodically paying off tech debt as you went along.

I'm not going to insinuate that it was necessarily wrong that you decided to solve the problem as you did, and the desire to be proactive about it is certainly not something to be criticized. But it wasn't necessarily right, either. Your leadership should have prevented something like this from occurring, because in all likelihood, you wasted those extra hours and naively thought that extra hours equal extra productivity. They don't. You ought to aim for maximal results for minimal hours of work, so that you can spend as much time as you can delivering results. And, unless you're getting paid by the hour instead of salaried, you're actually getting less pay. So to recap: you're getting less pay, you're giving the company subpar results (by definition, because you're using more hours to achieve what a competent engineer could do with only 40 hour workweeks so you're 44% as efficient), and everyone's losing a little bit. Thankfully, you still managed to get the job done, and because you were able to gain authorship and ownership over the new part of the codebase, you were able to politically argue for better compensation. Good for you, you should always bargain for what you deserve. But, just because you got a more positive outcome doesn't mean you went about it the most efficient way.

The best engineers (and I would argue workers in general) are efficient. They approach every engineering problems they can with solutions so simple and effective that they seem boring, only reaching for the impressive stuff when it's really needed, and with chagrin. If you can combine that with self-advocacy, you'll really be cooking with gas as far as your career is concerned. And, it'll get you a lot further than this silly childish delusion that more hours equals more results, or more pay. Solid work, solid negotiation skills, solid marketing skills and solid communication skills earn you better pay. The rest is fluff.

[0] [1]

Original thread
by greenyoda
There are even books about dealing with legacy code. I've found this one to be useful:

Working Effectively with Legacy Code, by Michael Feathers

Original thread
by jestar_jokin
Check out the book "Working Effectively with Legacy Code", by Michael Feathers[0].

I believe the basic approach is to write tests to capture the current behaviour at the system boundaries - for a web application, this might take the form of automated end-to-end tests (Selenium WebDriver) - then, progressively refactor and unit test components and code paths. By the end of the process, you'll end up with a comprehensive regression suite, giving developers the confidence to make changes with impunity - whether that's refactoring to eliminate more technical debt and speed up development, or adding features to fulfill business needs.

This way, you can take a gradual, iterative approach to cleaning up the system, which should boost morale (a little bit of progress made every iteration), and minimises risk (you're not replacing an entire system at once).

I've used this approach to rewrite a Node.js API that was tightly coupled to MongoDB, and migrated it to PostgreSQL.


Original thread
by bigethan
This article is a great.

Similarly Working Effective with Legacy Code by Michael Feathers ( is a great programming book. I appreciate it because It's really nothing but patterns for dealing with bad code (mostly Java, but most of it translates to other languages). Very little why (which I already know), lots of "how to fix X", aka, great signal to noise ratio.

Original thread
by lutorm
I like this book, it has a lot of tips for situations like these:

Original thread
by HerpDerpLerp
I am not sure the above idea is mentioned by Michael Feathers in his amaze book "Working Effectively with Legacy Code" but it is a great idea, and combined with the things that Michael does cover will do you a lot of good!

Original thread
by shoo
> > My own preference for the answer is Uncle Bob's description, which is this: technical debt is any production code that does not have (good) tests.

> That's certainly an example of technical debt.

Agreed, it is not the only example, but perhaps it is a good one, as that is a particularly important form of debt that makes the code harder to safely change. I.e. it is a form of technical debt that makes it more expensive to pay off other kinds of technical debt.

Curiously, Michael Feathers has a similar definition of legacy code [1]:

> To me, legacy code is simply code without tests.


Original thread
by valbaca
I just finished Pragmatic Thinking and Learning: Refactor Your Wetware (

Next I'm picking up Working Effectively with Legacy Code ( It's been in my reading list for years and I can finally get to it!

Original thread
by wyclif
Working Effectively With Legacy Code by Michael Feathers

Debugging with GDB: The GNU Source-Level Debugger by Stallman, Pesch, and Shebs

The Art of Debugging with GDB, DDD, and Eclipse by Matloff & Salzman

Original thread
by igorgue
Also, read this book:

It helps a lot and teaches you how to use grep and other tools (a lot more others that I no longer remember) to search and find your way through legacy code.

Original thread
by greenyoda
See if you can talk to the people in your company who hired the contractor. They might at least be able to give you a high-level description of what the software is supposed to do and how it's supposed to work. They might even have specs that they prepared for the contractor or other design documentation.

If the contractor's software has no tests or is poorly written, it's going to be hard to add features to it or refactor it. You might want to read Working Effectively with Legacy Code[1] by Michael Feathers, which describes how you can get a handle on large bodies of legacy software.


Original thread
by shoo
This reminds me of a post by Michael Feathers, titled "The carrying cost of code" [1]. Feathers wrote the book about legacy code [2]. I think he makes approximately the same point:

> If you are making cars or widgets, you make them one by one. They proceed through the manufacturing process and you can gain very real efficiencies by paying attention to how the pieces go through the process. Lean Software Development has chosen to see tasks as pieces. We carry them through a process and end up with completed products on the other side.

> It's a nice view of the world, but it is a bit of a lie. In software development, we are essentially working on the same car or widget continuously, often for years. We are in the same soup, the same codebase. We can't expect a model based on independence of pieces in manufacturing to be accurate when we are working continuously on a single thing (a codebase) that shows wear over time and needs constant attention.

[1] - [2] -

Original thread
by loumf
This is the standard recommended book:

I write new tests in any area I'm going to be working in.

Original thread
by greenyoda
One book that might give you some useful advice is "Working Effectively with Legacy Code" by Michael Feathers:

Original thread
by hvs
Great article that is still relevant today (sadly, I remember reading it when it first came out). If you really, really feel the need to rewrite from scratch, I recommend instead picking up a copy of "Working Effectively with Legacy Code" by Michael Feathers [1]. It will give you ways to improve those terrible code bases while not throwing out the existing code. Plus you'll still get that "new car smell" of working on your code.


Original thread
by wcoenen
If you do decide to add tests to an existing code base, I found "Working Effectively with Legacy Code"[1] to be a good guide. Check out the table of contents.


Original thread
by mattmcknight
"Working Effectively with Legacy Code" is by Michael Feathers.
Original thread
by koide
Appropriately, it's a book:

Some automatic tools could help (although I doubt thay'll work on DBase III): Static analysis to see what's there, version control to start at the top and log your way through and be able to rollback to a previous working version.

But it's at the very least weeks of pain.

Original thread
by Confusion
As the link by lttlrck also advocates: throwing shit out can easily be a mistake. More usually, + can get you further, faster. Stuff keeps working while you incrementally improve it.
Original thread
by agentultra

Working with legacy systems is a black art that I didn't learn about until I took a job supporting and extending one such system. The book I link to above was critical in helping me to understand the approach taken by the team I was working with. It takes a keen, detail-focused mind to do this kind of work.

The approach we took was to create a legacy interface layer. We did this by first wrapping the legacy code within a FFI. We built a test-suite that exercised the legacy application through this interface. Then we built an API on top of the interface and built integration tests that checked all the code paths into the legacy system. Once we had that we were able to build new features on to the system and replace each code path one by one.

Unsurprisingly we actually discovered bugs in the old system this way and were able to correct them. It didn't take long for the stakeholders to stop worrying and trust the team. However there was a lot of debate and argument along the way.

The problem isn't technical. You can simultaneously maintain and extend legacy applications and avoid all of the risks stakeholders are worried about. One could actually improve these systems by doing so. The real problem is political and convincing these stakeholders that you can minimize the risk is a difficult task. It was the hardest part of working on that team -- even when we were demonstrating our results!

The hardest part about working with legacy systems are the huge bureaucracies that sit on top of them.

Original thread
by calpaterson
Essentially, my understand of best practice is to write high level functional tests for the features that appear to work and then use them to ensure there are no regressions as a result of your changes. Someone people even define legacy code as "code without tests".

Original thread
by toumhi
This is what Michael Feathers calls 'seams' in his book, Working With Legacy Code. Often, you have to do exploratory testing, that is, you don't really know the requirements but you make tests that the current code passes. Then you can refactor it. That way, current code behavior won't be changed.

Very good read, if you need to deal with legacy code and you don't know where to start.

Original thread
by gte910h
This is actually the type of system (especially if it's very rough code quality wise in many places) I think regression tests are very useful (tests to make sure the system doesn't change function).

A book called "Working effectively with legacy code" by Feathers is great for instrumenting and regression testing old code bases then changing them without breaking them.

Non-aff link

Original thread
by xiongchiamiov
I have the book "Working Effectively with Legacy Code"[0], and it's pretty much just "Put things under test, then change them.". Still a useful read, though, if you find yourself working in that sort of thing often (I do).


Original thread

Found a good book? Subscribe to the weekly newsletter.