Pro tip: Legacy code can be code you yourself wrote 6 months ago.
I really like the techniques described here. I haven't gotten around to going through Michael Feathers's book, but the list of steps described is what I try and do anyways when working with legacy code.
It is amazing how fast bitrot can take hold of a codebase that isn't being continually maintained. The author's reference to broken window theory, that once you have a chunk of code that is pretty gnarly, the next person who comes along and has to add something to it just slaps it in there, it is already a mess, so why try and clean it up? There is a hard tradeoff with pragmatism that we have to make, especially if you are working at a startup where not getting to market could be the death of your company. But I think that knowing and understanding these techniques can give you confidence that you will be able to go back later and clean up your own legacy code.
People who say legacy code is code without test I think repeat that because somebody said that and it just sounds catchy.
Transition to "legacy" happens when somebody stops caring about updating it as if it was to work forever. It might be when the team decides to rewrite it it might be immediately after initial development push or at a different time. The same thing happens with your car. One day you just stop commitment to keeping it alive and it becomes "legacy" car. One that will start failing and one you will now be looking to replace.
When people stop seriously updating the codebase they might be thinking "maybe all that effort is not really necessary, we just need to keep it alive for couple more years". Yep, we are now officially in legacy territory.
Legacy has a bunch of symptoms. Technical debt start accumulating with no real commitment to ever be paid. The team typically looses knowledge of the app when original developers leave, causing "better not touch unless absolutely necessary because I have no idea what I am going to break" syndrome. Management might be thinking the same way and restrict funding or just simply stop caring enough, further exacerbating the problem.
Anyway, nothing to do with tests. Lack of tests might be one of syndrome (why write test if I don't care and nobody will use it anyway?) But there are legacy apps with good test coverage (typically another can of worms) and there also projects in rather good shape without tests (ever heard of Linux kernel?)
I think the biggest symptom of a legacy code is exactly "better not touch unless absolutely necessary because I have no idea what I am going to break".
i.e. on a greenfield project if your expectations and application behavior disagree, the application is wrong. On a legacy code base if your expectations and the application behavior disagree, your expectations are probably wrong.
When someone asks the question "why does the application do this?" there is no one to answer the question, but everyone assumes it's probably pretty important.
> But there are legacy apps with good test coverage (typically another can of worms)
100% this. Unit tests are usually so sensitive to changes they'll break as often for a buggy fix and a bugless one. Last app I worked on I broke 12 unit tests without introducing a single bug. Sometimes on a truly legacy app a unit test can break and you have no idea if you should change the unit test or your code.
My biggest gripe with legacy systems is that the interfaces lie and when you try to fix them and you run the test suite everything passes, but there was actually intention behind one of the lying interfaces that you didn't know about and it wasn't part of the test suite because the person that was responsible for that reliance didn't think to test a specific case of the application, which happens, but the combination of the two problems leads to something where a corrective change is done, then issues come up in production. The interface said something like "can edit" but really what it meant was "can edit for a very strange edge case" and somewhere else in the codebase relied upon the interface.
It's hard to talk about, since it's all in abstract terms, but I see it over and over agin. People have incomplete understandings of the problem because the codebase is so fragmented and poorly documented / tested so the changes they make don't really reflect what would have been the true intention if they'd really understood the current and future system.
- your IT dept is under pressure to do a lot with very little
- your tech debt grows and grows until it becomes actually apparent to the business that even small changes are taking tremendous effort
- your IT team is not just stuck with legacy code but also with legacy skills
- someone has the sense to measure your IT throughput
- "expert" IT consultants are called in
- experts call for a total overhaul using some fancy terminology
- some $$$ later we have a n% transformation, some unhappy permanent employees who think they could have done this themselves, reluctantly acquired knowledge, skeptical internal users
- you now learnt the hard way to listen to your IT team more when they say that they need support with learning new skills and time to fix tech debt
It's an interesting narrative, but I can't think of any examples, since business is more about sales than "software iteration" - whatever that means.
Most of the successful startups that I can think of are still running basically the version 1.0 a founder wrote.
Can you provide some examples?
Also, you're mixing up the concepts/terms of software development (writing products) and IT. Software product companies don't call software engineering/development "IT" - IT is the guy who buys computers and restarts the wifi AP as needed.
To be fair this can go the other way too. There are some big boondoggles caused by upper management listening to IT when they said they needed to make huge investments in refactoring and architecture. The business ends up with a new product that does the same thing, at the cost of millions of dollars that will never be recouped.
In my experience, upper management with enough years in the business do not feign as much authority in understanding how IT works. On the contrary IT people who have been with the business long enough seem to think they understand the business pretty well. They don't. And half knowledge is dangerous is indeed a wise saying.
So even though those system architects buzzing with their confidence due to years of being part of the business often provide helpful insight, i would always always run crucial decisions that effect the business functionally, by business people only.
Great punchline. In the real world, no such thing was learnt. The new management that hired the consultants claim victory, and nobody remembers what got them into the mess in the first place.
We had a member in our team who was quite sharp, understanding of user relevant functionality/aspects, who could code semi-complex stuff all on his/her own (of course without consulting anyone else) and whose every line was the moment it was typed legacy. As everyone was a bit dumbfounded by the self-confidency, and also because the whole team was busy doing greenfield groundwork, glad to have someone who takes care of him/herself, producing code that appeared to work, we let him/her do without interfering much. When there was interference, the reviewer was left with the impression that she/he just didn't understand the marvels of the code she/he just reviewed.
Afterwards, legitimations included "unit tests are non-clean, they require too much mocking/stubbing", this is an "edge-edge-edge case" and so on (architectural and design deficiencies are routinely defended by statements like this, and in this case, spot on).
Since she/he was dubbed a star developer for a while (which is quite astounding, since we have quite a high bar for hiring), she/he could get away with that. From a certain perspective she/he was successful: we launched our project in time, with few bugs, with quite an amazing feature set. Most of the credits go to the not-so-visible, but diligent other team members, but from a management perspective it was quite a success.
After rewriting ~30% of her/his code, with the prospect of ~70% remaining, the person is not working on the project anymore. But she/he is complaining all the time about how much legacy code he/she has to maintain in the new role, and how serious her/his (from her/his perspective non-voluntary removal from the project despite his/her indispensability) abilities must be missing from the project team.
Extreme case, I know. But it's just the most extreme one I saw in my dev career :)
Never trust an engineer who says they don't need to write tests. It's somewhat of a dream for many engineers to be heads down working alone on deep technical problems but while coding may be solo endeavor, _code maintenance_ is a team sport. It's never good to let someone go it alone for too long.
Side note: It's much simpler to say "they/them" when referring to someone rather than "he/she", "s:he", and "his/her".
Sorry, not a native speaker and reading too much strange english books, which could spoil my writing. Could you point me to one or two specific errors I made in order to help me improve?
If you're referring to s:he and so on, that is our german way of obfuscating the gender of the subject :) I don't like it (at all, since most of the time it just dismisses achievements of women).
What I just said it's that's what most people do. I clarified that this is in spite of "they" typically referring to multiple people. It's helpful for non and new English speakers if you explain these colloquialisms.
I really like the techniques described here. I haven't gotten around to going through Michael Feathers's book, but the list of steps described is what I try and do anyways when working with legacy code.
It is amazing how fast bitrot can take hold of a codebase that isn't being continually maintained. The author's reference to broken window theory, that once you have a chunk of code that is pretty gnarly, the next person who comes along and has to add something to it just slaps it in there, it is already a mess, so why try and clean it up? There is a hard tradeoff with pragmatism that we have to make, especially if you are working at a startup where not getting to market could be the death of your company. But I think that knowing and understanding these techniques can give you confidence that you will be able to go back later and clean up your own legacy code.