How to Improve a Legacy Codebase • Hacker News Board

Re: How to Improve a Legacy Codebase

#201

Post by vickychijwani » Tue, May 30, 2017, 9:15 PM UTC

specialist wrote: post #33

Sound advice. re: Write Your Tests I've never been successful with this. Sure, write (backfill) as many tests as you can. But the legacy stuff I've adopted / resurrected have been complete unknowns. My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use automation to diff output. I wouldn't bother to write unit tests etc for code that is likely to be culled, replac…

> Semver is marketing, not engineering.

I agree with many of your points, but that casual dig at semver is unwarranted and reveals a misunderstanding of the motivation behind it [1]. Semver defines a contract between library authors and their clients, and is not meant for deployed applications of the kind being discussed here. Indeed, the semver spec [2] begins by stating:

> 1. Software using Semantic Versioning MUST declare a public API.

It has become fashionable to criticize semver at every turn. We as a community should be more mindful about off-the-cuff criticism in general, as this is exactly what perpetuates misconceptions over time.

[1]: https://news.ycombinator.com/item?id=13378637

[2]: http://semver.org/

Re: How to Improve a Legacy Codebase

#202

Post by debuggest » Tue, May 30, 2017, 9:22 PM UTC

erikpukinskis wrote: post #152

specialist wrote: post #33

Sound advice. re: Write Your Tests I've never been successful with this. Sure, write (backfill) as many tests as you can. But the legacy stuff I've adopted / resurrected have been complete unknowns. My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use automation to diff output. I wouldn't bother to write unit tests etc for code that is likely to be culled, replac…

> re: Write Your Tests, I've never been successful with this ... I wouldn't bother to write unit tests etc for code that is likely to be culled, replaced. I think you misread the author. He says "Before you make any changes at all write as many end-to-end and integration tests as you can." (emphasis mine) > My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use aut…

Pinning tests can be helpful for scary legacy code! http://rick.engineer/Pinning-tests/

Re: How to Improve a Legacy Codebase

#203

Post by jacquesm » Tue, May 30, 2017, 9:22 PM UTC

kentt wrote: post #200

jacquesm wrote: post #111

Earlier quoted context omitted.

10k loc is very very minor league. You can do anything you want on a base that size, it won't matter. 100's of thousands to millions of loc is a lot more problematic, many moving parts and weird interplay is to be expected.

I understand that it likely "won't matter". My point was to ask if it was worth talking about outliers to the Never Rewrite law. eg it's assumed when talking about refactoring over rewriting that a large portion of features is working. There should be some percentage where it's worth rewriting over refactoring. Or perhaps a size where it's small enough to easily rewrite.

Yes, that's definitely a discussion worth having.

To me you can rewrite anything that:

(1) you fully understand (and you'd better be right about that)

(2) you have total control over already

(3) is small enough for (1) and (2) to be possible

(this is where I think a lot of people over-estimate their capabilities)

(4) where you have the ability to absorb a catastrophic mistake

(which usually isn't the pay-grade of the programmers)

and finally

(5) where you have a 'plan-B' in case the rewrite against all odds fails anyway

None of these are absolutes, if there is no business riding on the result then you can of course do anything you want. The history of IT is littered with spectacular failures of teams that figured they could do much better by tossing out the old and setting a date for the deploy of the shiny new system. Whatever you do make sure that your work won't add to that pile.

The older, the larger, poorer documented, worse tested the system is the bigger the chance that it is not fully understood.

Re: How to Improve a Legacy Codebase

#204

Post by alkonaut » Tue, May 30, 2017, 9:29 PM UTC

jacquesm wrote: post #34

OutsmartDan wrote: post #31

Big bang rewrites are needed in order to move forward faster. A huge issue with sticking to an old codebase for such a long time is that it gets older and older. You get new talent that doesn't want to manage it and leave, so you're stuck with the same old people that implemented the codebase in the first place. Sure they're smart, knowledgable people in the year 2000, but think of how fast technology changes. Change…

A big bang rewrite will nine out of ten times slow you down, it will not accelerate things, and the most likely outcome is that not only will it be slower, it might fail entirely. It's a complete fallacy to think that you're going to do much better than the previous crew if you are not prepared to absorb the lessons they left behind in that old crusty code. So you'll have to learn them all over again. > Change, adapt…

It's not a given that legacy code means "no people still around, no docs and no tests". I'm on a rewrite project and I'm 10 years in, and the whole crew from the last project (also around 15 years) is till in this project too. That helps.

The causes of the big bang rewrite are usually not just "this code smells let's rewrite it" but rather that the old product reached some technical dead end. Perhaps it can't scale. Perhaps it's a desktop product written in an UI framework that doesn't support high DPI screens and suddenly all the customers have high DPI screens. Obviously in that situation you'd aim to just replace a layer of the application (a persistence layer, an UI layer) but as we all know that's not how it works. The cost of a rewrite shouldn't be underestimated - as you said there is no reason to believe that if it took 50 man years for the last team then the new team will take 50 too. But that is in itself not a reason to not do it.

Re: How to Improve a Legacy Codebase

#205

Post by alkonaut » Tue, May 30, 2017, 9:32 PM UTC

jacquesm wrote: post #129

pc86 wrote: post #128

I've been a part of several successful big-bang rewrites, and several unsuccessful ones, and saying that if you're smart they're not on the table is just flat out wrong. The key is an engaged business unit, clear requirements, and time on the schedule. Obviously if one or more of these things sounds ridiculous then the odds of success are greatly diminished. It is much easier if you can launch on the new platform a c…

I've yet to see a large system with lots of subsystems rewritten in one go, but I'm more than open to being convinced that it can be done so if you could please do a write-up of how such a project was managed. The ones I have seen - and this is actually one of the major reasons the clean-up crew gets called in the first place - is big bang rewrite projects gone astray. One huge problem with rewrites of old code is th…

The biggest problem with "the new system" is that it's rarely a rewrite of the second system. Obviously someone liked the old system otherwise it wouldn't be rewritten. But the business case for the new system isn't just lower maintenance cost, higher performance, a modern look etc. It's always going to be all those new features. That's what sinks the new project.

Re: How to Improve a Legacy Codebase

#206

Post by DougWebb » Tue, May 30, 2017, 9:46 PM UTC

crdoconnor wrote: post #179

ethbro wrote: post #99

Earlier quoted context omitted.

From personal experience, a good way of approaching the sell to business stakeholders is getting them involved in the bug triage and tracking process. You need to make the invisible (refactoring and code quality) visible (tracking) so they can see what the current state is and map the future. The biggest reason business stakeholders push back against this is that developers tend to communicate this in terms of "You d…

I've tried this "getting them involved" approach and it failed miserably for me. I've tried explaining why module A had to be decoupled from module B to stakeholders. I've tried explaining why we need to set up a CI server. I've tried explaining why technology B needs to isolated and eliminated. In almost all cases they nod and feign interest and understanding and their eyes glaze over. And why should they be interes…

"Currently, every time we want to build a release of the software in order to test it before deployment, __ developers need to stop working on features and maintenance while we go through the build process, which takes __ hours/days. There are a lot of manual steps involved, and we found that we make an average of __ errors in the process each time, which takes an additional __ hours/days to resolve. We go through all of this __ times a year.

We've determined that we can automate the entire process by setting up a Continuous Integration (CI) server. There's some work involved in setting it up; we estimate it will take __ days/weeks to get it running. But once it's running, (we'll always have a build running __ minutes after each code change)|(we can click on a button in the CI's GUI and we'll have a build running __ minutes later), and we'll be saving __ hours/days of effort per build/year."

Plug in your numbers. If the time to deploy the CI server exceeds the savings, the business would be justified in telling you not to do it. (You'd have to make a case based on quality and reproducibility, which is tougher.) If the cost is less than the savings, the business should see this as a no-brainer, and the only restraint would be scheduling a time to get it done. (Not having it might cost more, but it might not cost as much as failing to get other necessary work done.)

Re: How to Improve a Legacy Codebase

#207

Post by jacquesm » Tue, May 30, 2017, 9:48 PM UTC

alkonaut wrote: post #204

jacquesm wrote: post #34

Earlier quoted context omitted.

A big bang rewrite will nine out of ten times slow you down, it will not accelerate things, and the most likely outcome is that not only will it be slower, it might fail entirely. It's a complete fallacy to think that you're going to do much better than the previous crew if you are not prepared to absorb the lessons they left behind in that old crusty code. So you'll have to learn them all over again. > Change, adapt…

It's not a given that legacy code means "no people still around, no docs and no tests". I'm on a rewrite project and I'm 10 years in, and the whole crew from the last project (also around 15 years) is till in this project too. That helps. The causes of the big bang rewrite are usually not just "this code smells let's rewrite it" but rather that the old product reached some technical dead end. Perhaps it can't scale.…

Fair enough. So the real lesson then is 'it depends', as with everything else. But the kind of jobs where the cleanup crews get called in are on the verge of hopeless and it is not rare that we do these on a 'no-cure, no pay' basis.

Great to see you be part of such a long lived team, that's a rarity these days. That's got to be a fantastic company to work for. Usually even relatively modest turnover (say 15% per year) is enough to effectively replace all the original players within a couple of years, most software projects long outlive their creators presence at the companies they were founded in. Add in some acquisitions or spin-outs and it gets to the point where nobody even knows who wrote the software to begin with.

Re: How to Improve a Legacy Codebase

#208

Post by typednothing » Tue, May 30, 2017, 9:51 PM UTC

ebiester wrote: post #74

jacquesm wrote: post #48

Earlier quoted context omitted.

The rewrite only works - in my experience, YMMV - if the team is already 100% familiar with the codebase as it is and the task is a relatively simple one and there is a nice set of tests and docs to go with the whole package. Outside that boundary you're set up for failure.

The one caveat is that there are times when the business realizes that their old workflows and features aren't what they now need. The rewrite becomes a new project competing with the old rather than a functional rewrite. This is also fraught with peril. However, it is a different set of problems. In an ideal world, you have engineers who can make reasoned decisions. However, if the company culture allowed one applic…

At some point they'll junk the in-house program and buy something off the shelf.

Re: How to Improve a Legacy Codebase

#209

Post by DougWebb » Tue, May 30, 2017, 9:52 PM UTC

crdoconnor wrote: post #145

apeace wrote: post #67

> Do not fall into the trap of improving both the maintainability of the code or the platform it runs on at the same time as adding new features or fixing bugs. I don't disagree at all, but I think the more valuable advice would be to explain how this can be done at a typical company. In my experience, "feature freeze" is unacceptable to the business stakeholders, even if it only has to last for a few weeks. And for…

>I don't disagree at all, but I think the more valuable advice would be to explain how this can be done at a typical company. I resolved to try this if I ever ran into the same problem again after a whole bunch of arguments at a previous few companies: * Set up a (paper) slider with 0-100% on it and put it somewhere prominent on the wall. Set it at 70%. That's the % of time you spend on features vs. the % of time you…

I'd call it "Maintaining existing code" rather than "Refactoring".

To a non-technical manager, the former sounds like pretty much what it is, and won't raise many questions. (If they do question it, ask them if they maintain their car while it's still running ok, or just wait until it breaks down before they do anything to care for it.)

Refactoring, on the other hand, sounds like a buzz word, and if they look it up they'll get "rewriting code that's already working so that it continues working the same way". They probably won't get the nuances about why that's a useful thing to do, so it'll sound like busywork and they won't be happy with letting your team do it. They also won't be able to justify it to their management if they're questioned about it, which is critical for getting buy-in from your managers.

Re: How to Improve a Legacy Codebase

#210

Post by _virtu » Tue, May 30, 2017, 10:05 PM UTC

chiph wrote: post #52

cafard wrote: post #21

Earlier quoted context omitted.

Frankly, I never quite understood the importance of clear documentation until I found one such code base smoldering on my porch.

At the very least, write a doc that explains how to build the product, including where to find the parts in source control, what the dependencies are, what servers it'll get installed on, and so on. The goal being to increase your shop's "Bus Factor" https://en.wikipedia.org/wiki/Bus_factor

I love the notion of bus factor. Whenever a bunch of devs go out drinking I think this every time we cross the street. :)