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

141–150 of 300 posts

Re: How to Improve a Legacy Codebase

#141

Post by jacquesm »

sz4kerto wrote: post #133
jacquesm wrote: post #124

Earlier quoted context omitted.

That's ok, we'll be more than happy to charge his boss $something terrible K/month per person to bail them out at some point :)

Nah, that's condescending, really. We might have different experience because of the codebases we've worked with; but I don't think there's a need for this kind of sarcasm.

Well, I've been in this line of business for 30+ years, if you think there is some aspect of it that you structurally encounter that I don't then I'm all ears.

Keep in mind that almost everybody that we end up cleaning up after has the exact attitude that you display and the only reason they feel that way is because they leave before the bill is due.

I don't mind, it keeps me employed.

Re: How to Improve a Legacy Codebase

#142

Post by d--b »

I agree with most of this, though I think it doesn't dive into the main problem:

Freezing a whole system is practically impossible. What you usually get is a "piecewise" freeze. As in: you get to have a small portion of the system to not change for a given period.

The real challenge is: how can you split your project in pieces of functionalities that are reasonably sized and replaceable independently from each other.

There is definitely no silver bullet for how to do this.

Re: How to Improve a Legacy Codebase

#143

Post by [deleted] »

misja111 wrote: post #97
korzun wrote: post #68

> Before you make any changes at all write as many end-to-end and integration tests as you can. I don't agree with this. People can't write proper coverage for a code base that they 'fully understand'. You will most likely end up writing tests for very obvious things or low hanging fruits; the unknowns will still seep through at one point or another. Forget about refactoring code just to comply with your tests and br…

I agree with you, I don't know why you were downvoted. In my experience the first and biggest problem when taking over legacy codebases is the lack of knowledge of what features the code is supposed to support. Just starting out with writing integration test has a risk that you end up with even more meaningless code to maintain. Actually, contrary to the advise of the writer, I like to start out with fixing some bugs…

[deleted]

Re: How to Improve a Legacy Codebase

#144

Post by kevan »

>Use proxies to your advantage

At my last gig we used this exact strategy to replace a large ecommerce site piece by piece. Being able to slowly replace small pieces and AB test every change was great. We were able to sort out all of the "started as a bug, is now a feature" issues with low risk to overall sales.

Re: How to Improve a Legacy Codebase

#145

Post by crdoconnor »

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 spend on refactoring (what that entails should be the development team's prerogative).

* Explain to the PM (or their boss) that they can change it at any time.

* Explain that it's ok to have it at 100% for a short while but if they keep it up for too long (e.g. weeks) they are asking for a precipitous decline in quality.

* Track all the changes and maintain a running average.

I think a lot of people suspect that management would just put it at 100% and leave it but I suspect that wouldn't happen. Most manager's "cover their ass" instincts will kick in given how simple, objective and difficult to bullshit the metric is once it's explicit.

Re: How to Improve a Legacy Codebase

#146

Post by jacquesm »

sz4kerto wrote: post #135
jacquesm wrote: post #108

Earlier quoted context omitted.

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…

> That's exactly why this list is set up the way it is: you will get results fast and they will be good results. What do you mean by 'fast'? If you can get meaningful improvements in a few months' time, then you're just working with smaller code base than what I thought of. If you're talking about stopping for a year, then .. well, that's the problem I'm talking about. > If you want to play the 'I'm doing a sloppy jo…

> What do you mean by 'fast'?

Much faster than by going the rewrite route (assuming that is even possible, which I am convinced for anything but the most trivial problems it isn't). Preferably to first deploy within a few days and incremental changeover to the new situation starting within two weeks or so of the starting gun being fired.

> If you can get meaningful improvements in a few months' time, then you're just working with smaller code base than what I thought of.

No.

> If you're talking about stopping for a year, then .. well, that's the problem I'm talking about.

Who said so?

All I said is that you should only do one thing at a time. Do not attempt to achieve two results with one release.

> No, I just wanted to share my opinion that I disagree with the overly generalized suggestions you're making.

You are very welcome to your own opinion about my 'overly generalized suggestions' it's just that they are a lot more than suggestions, they are things that I (and others, see this thread for evidence) have used countless times and that simply work.

All you do is a bunch of naysaying without offering up anything concrete as an alternative that would work better or evidence that anything posted would not work in practice. It does and it pays my bills.

Re: How to Improve a Legacy Codebase

#147

Post by jofer »

scott00 wrote: post #138
jofer wrote: post #78

I agree with everything said, but I think they assumed a well-maintained and highly functionality legacy codebase. In my experience, there are a few steps before any of those. --- 1. Find out which functionality is still used and which functionality is critical Management will always say "all of it". The problem is that what they're aware of is usually the tip of the iceberg in terms of what functionality is supporte…

I don't completely understand your warning to stick with the existing version control environment. Just because you switch development to git doesn't mean you delete the old CVS archive. Isn't consulting the old archive sufficient whenever you're doing a significant historical investigation?

There are a couple of reasons I'd argue it's best to avoid switching version control environments early on.

1. Integration with whatever build/issue tracking systems are present is worth preserving until you have the time to recreate it properly.

Duplicating what's already there under the new environment is always more problematic than it looks like at first glance. This is especially true when you're dealing with any in-house components (which usually manage to show up somewhere).

2. A clean break where you leave the old VCS behind and archived is tempting, but it's rarely ideal in the long-term.

The old archive is likely to wind up being deleted/lost/bitrotted/etc after a year or two. Invariably, you wind up in a spot a few years down the line where it would be useful to have the full commit history, and the old VCS winds up being inaccessible. Ideally, you'd want to preserve as much history as possible when migrating. However, trying to correctly preserve commit history (and associated issue tracker info, etc) is always a time-sink, in my experience. It's easy for simple projects, and a real pain for complex projects with a weird, long history. Choose the time that you attempt it wisely.

---

Again, I'm not saying don't move, I'm just saying that it almost always winds up taking a lot of time and effort. I'd argue you're better off spending that time and effort on other portions of the project early on.

Also, things like git-svn can be real lifesavers in some of these cases, though they do add an extra layer of complexity. If you do want to use a different VCS, I'd take the git-svn/etc approach until you're sure there are are no extra integration problems.

All that said, yeah, if there's no history and no integration with other systems/tools, go straight for something modern!

Re: How to Improve a Legacy Codebase

#148

Post by jacquesm »

SideburnsOfDoom wrote: post #136
jacquesm wrote: post #80

Earlier quoted context omitted.

Not available on all platforms. Think: mainframes, platforms no longer with the times, non-unix and so on. If you have access to a tool like that by all means use it, the specific implementation is not relevant, the article merely tries to show a simplest way to implement this very useful functionality that will work without limitation on just about anything that I can think of.

> Not available on all platforms. Think: mainframes, platforms no longer with the times, non-unix and so on. YMMV, though I would steer people towards an off-the-shelf solution over rolling your own. Does "non-unix" mean Windows? My experience there has been that you can find a statsd client for your language of choice, and a way to plug whatever logging tool you have into kibana.

Quite often there is an embedded component in the mix somewhere, or even a machine that is not networked in any present day sense of the word.

The whole reason these jobs exist is because modern tooling and the luxury that comes with them is unavailable. But I've yet to find a platform where that counter trick did not work, even on embedded platforms you can usually get away with a couple of incs and a way to read out the counters.

If the timing isn't too close to failure.

One interesting case involved a complex real life multi-player game with wearable computers. In the end we got it to work but only by making all the software run twice as fast as it did before so we could use the odd cycles for the stats collection without the rest of the system noticing. That was a big of a hack. And the best bit: after making it work we then used all the freed up time to send extra packets to give the system some redundancy and this greatly improved reliability.

That system was running 8051 micro controllers and the guy that wrote the original said that 'this couldn't be done'. Fun times :)

The server side portion of that particular project got completely re-written as well roughly along the lines presented in the article, that wasn't a huge project (500K lines or so) but I was very happy that it wasn't my first large technical debt mitigation project or I would have likely stranded.

Re: How to Improve a Legacy Codebase

#149

Post by jacquesm »

kod wrote: post #131
jacquesm wrote: post #80

Earlier quoted context omitted.

Not available on all platforms. Think: mainframes, platforms no longer with the times, non-unix and so on. If you have access to a tool like that by all means use it, the specific implementation is not relevant, the article merely tries to show a simplest way to implement this very useful functionality that will work without limitation on just about anything that I can think of.

Serious question - what platforms are you working on that you can't send a udp packet that looks like "somecounter:1|c"

Hehe. If you can't imagine that then you have a sheltered and probably very happy life. I don't care if it speaks ethernet, arcnet, twinax, X.25 or nothing at all, we'll find a way. By the time you can start sending UDP packets you are already on very solid footing.

Be happy if your dev environment does not include an emulated version of the real hardware that mysteriously does not seem to be 100% representative of the real thing.

Re: How to Improve a Legacy Codebase

#150

Post by jacquesm »

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…

That's a good one, I will definitely steal that. Thank you!
Post reply on HN