Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Improve a Legacy Codebase

jacquesmattheij.com

Post reply on HN
Print view View original

101–110 of 300 posts

Re: How to Improve a Legacy Codebase

#101

Post by ef4 »

lol768 wrote: post #91

Any advice on what steps to take when the legacy codebase is incredibly difficult to test? I completely agree with the sentiment that scoping the existing functionality and writing a comprehensive test suite is important - but how should you proceed when the codebase is structured in such a way that it's almost impossible to test specific units in isolation, or when the system is hardcoded throughout to e.g. connect…

An after-the-fact test suite is a different beast than one written concurrently with the app. It's not worth trying to force one to be the other.

Work from the outside in, keeping most of the system as a black box. Start with testing the highest-level behaviors that the business/users care about.

Re: How to Improve a Legacy Codebase

#102

Post by jacquesm »

ethbro wrote: post #99
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…

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…

> PS: I love the simple counter-based bookkeeping perspective from the linked post. (And think someone else suggested something similar in a previous performance / debugging front page article)

If you're short on budget and need to sell the whole package to management just do that one, it will make all that invisible stuff visible in more detail than they likely have the stomach for and you'll be granted budget in no time because there is nothing that spells lost business better than a fair sized gap between customers entering on the left and only a trickle coming out on the right.

In effect this is funnel visualization for the internals of an application in all the gory detail.

Re: How to Improve a Legacy Codebase

#103

Post by nawitus »

kentt wrote: post #95

> Do not ever even attempt a big-bang rewrite I'd love to hear a more balanced view on this. I think this idea is preached as the gospel when dealing with legacy systems. I absolutely understand that the big rewrite has many disadvantages. Surely there is a code base that has features such that a rewrite is better. I'm going to go against the common wisdom and wisdom I've practiced until now, and rewrite a program I…

I also disagreed with that part in the article. Big-bang rewrites can be just fine - but usually there are reasons it's not possible.

Re: How to Improve a Legacy Codebase

#104

Post by Yhippa »

kentt wrote: post #95

> Do not ever even attempt a big-bang rewrite I'd love to hear a more balanced view on this. I think this idea is preached as the gospel when dealing with legacy systems. I absolutely understand that the big rewrite has many disadvantages. Surely there is a code base that has features such that a rewrite is better. I'm going to go against the common wisdom and wisdom I've practiced until now, and rewrite a program I…

Not a dissenting opinion but I'd love to see some case studies on rewrites. As a consultant this is a frequent request and will probably be big business in the future as people migrate off of expensive legacy mainframe or other applications from the 80's, 90's, and possibly 2000's.

Re: How to Improve a Legacy Codebase

#105

Post by sz4kerto »

The OP has so many reasonable, smart-sounding advice that doesn't work in the real world.

1) "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."

Thanks. However, in many situations this is simply not possible because the business is not there yet so you need to keep adding new features and fix bugs. And still, the code base has to be improved. Impossible? Almost, but we're paid for solving hard problems.

2) "Before you make any changes at all write as many end-to-end and integration tests as you can."

Sounds cool, except in many cases you have no idea how the code is supposed to work. Writing tests for new features and bugfixes is a good advice (but that goes against other points the OP makes).

3) "A big-bang rewrite is the kind of project that is pretty much guaranteed to fail.

No, it's not. Especially if you're rewriting parts of it at a time as separate modules

My problem with the OP is really that it tells you how to improve a legacy codebase given no business and time pressure.

Re: How to Improve a Legacy Codebase

#106

Post by cessor »

I'd add a prerequisite to the top of this list:

- Get a local build running first.

Often, a complete local build is not possible. There are tons of dependencies, such as databases, websites, services, etc. and every developer has a part of it on their machine. Releases are hard to do.

I once worked for a telco company in the UK where the deployment of the system looked like this: (Context: Java Portal Development) One dev would open a zip file and pack all the .class files he had generated into it, and email it to his colleague, who would then do the same. The last person in the chain would rename the file to .jar and then upload it to the server. Obviously, this process was error prone and deployments happened rarely.

I would argue that getting everything to build on a central system (some sort of CI) is usefull as well, but before changing, testing, db freezing, or anything else is possible, you should try to have everything you need on each developer's machine.

This might be obvious to some, but I have seen this ignored every once in a while. When you can't even build the system locally, freezing anything, testing anything, or changing anything will be a tedious and error prone process...

Re: How to Improve a Legacy Codebase

#107

Post by thehardsphere »

sz4kerto wrote: post #105

The OP has so many reasonable, smart-sounding advice that doesn't work in the real world. 1) "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." Thanks. However, in many situations this is simply not possible because the business is not there yet so you need to keep adding new features and fix bugs. And still,…

>3) "A big-bang rewrite is the kind of project that is pretty much guaranteed to fail.

>No, it's not. Especially if you're rewriting parts of it at a time as separate modules

I guess it depends on what he considers to be a "big bang rewrite." I don't think any of the incremental approach you mention counts as one.

Re: How to Improve a Legacy Codebase

#108

Post by jacquesm »

sz4kerto wrote: post #105

The OP has so many reasonable, smart-sounding advice that doesn't work in the real world. 1) "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." Thanks. However, in many situations this is simply not possible because the business is not there yet so you need to keep adding new features and fix bugs. And still,…

On the contrary, we do this work under extreme business and time pressure, sometimes existential pressure (as in: fail and the company fails).

That's exactly why this list is set up the way it is: you will get results fast and they will be good results.

If you want to play the 'I'm doing a sloppy job because I'm under pressure' card then consider this: the more pressure the less room there is for mistakes.

Here is a much more play-by-play account of one of these jobs where management gave me permission to do a write-up as part of the deal:

https://jacquesmattheij.com/saving-a-project-and-a-company

(For obvious reasons management usually does not give such permission, nobody wants to admit they let it get that far on their watch, I did my best to obscure which company this is about.)

Re: How to Improve a Legacy Codebase

#109

Post by ef4 »

kentt wrote: post #95

> Do not ever even attempt a big-bang rewrite I'd love to hear a more balanced view on this. I think this idea is preached as the gospel when dealing with legacy systems. I absolutely understand that the big rewrite has many disadvantages. Surely there is a code base that has features such that a rewrite is better. I'm going to go against the common wisdom and wisdom I've practiced until now, and rewrite a program I…

Your example is much smaller than what people are usually talking about in terms of big-bang rewrites. So maybe you will be successful.

Even so, you're better off doing a step-by-step rewrite, where the new stuff and the old stuff coexists in a single application. That way your users can continue getting incremental benefits over time even if the rewrite takes dramatically longer than you're optimistic estimate.

If you can't figure out how to manage the complexity of a piecemeal rewrite, consider that you may not actually understand the system well enough to avoid making version 2 just as bad as version 1.

Most people overestimate their ability to act differently than they've acted in the past. It's like the unjustified optimism of a New Year's resolution that this time you're actually going to exercise every day. To get a better result than last time, you need to impose some very clear rules on yourself that cause you to work differently.

Re: How to Improve a Legacy Codebase

#110

Post by jacquesm »

douche wrote: post #94
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…

> 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, replaced. I think that is precisely what the article advocates - although the definition of what end-to-end and integration tests are varies wildly from place to place. > First step to any project is to…

That's absolutely true, I totally wrote that under the assumption that you at least have some kind of build process and that it actually works. I will add another section to the post.
Post reply on HN