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

211–220 of 300 posts

Re: How to Improve a Legacy Codebase

#211

Post by naasking »

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…

> 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.

Because that's too technical. You have to frame the problems in terms that impact them or their employees in terms of user stories/case studies.

Notice the OP said that users have long login times due to various issues and he can solve them by doing X, and not "TCP/IP timeouts and improper caching policies are causing back pressure leading to stalls in the login pipeline..."

Re: How to Improve a Legacy Codebase

#212

Post by rattray »

jacquesm wrote: post #169
rattray wrote: post #157

> Yes, but all this will take too much time! I'm actually quite curious; how long does this process typically take you? What are the most relevant factors on which it scales? Messiness of existing code? Number of modules/LOC? Existing test coverage?

Good questions. How long it takes depends on the mandate given by management. Sometimes it's 30 days to get from zero to something stable and incrementally improvable at which point we hand back to the company with maybe a transition period where we still manage the project. Sometimes it is just a feasibility study in which case it can be even shorter. But if it is boots-in-the-mud (which is where the real money is)…

Very interesting, thanks!

Re: How to Improve a Legacy Codebase

#213

Post by bluGill »

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…

Freeze is a business decision, NOT a technical decision. How much risk is acceptable to them is the question. If they want low risk than they need to freeze early, if they can stand risk then they can freeze latter. If they want the best of both worlds then they need to invest in automation (build and test) up until the point where the costs of automation exceed the value of lower risk with a late freeze date.

Remember you need to work in their terms. Risk is something they understand. The risk is they ship as soon as the last feature is done, without discovering that the last feature broke everything else. From there they move back, the last feature is done, so we do a 30 second sanity test - increase that to 30 minutes, 1 week, 1 month... They should have charts (if not create them) showing how long after a bug is introduced is it discovered on average, use those charts to help guide the decision. If the freeze time frame is too long then they allocate budget to fix it, or otherwise plan around this.

There are a lot of options, but they are not technical.

Re: How to Improve a Legacy Codebase

#214

Post by rattray »

jacquesm wrote: post #163
rattray wrote: post #158

Earlier quoted context omitted.

> The problem is that you're now a lot wiser about that codebase than you were at the beginning That may not be true in this case, if the rewriter is also the original author and has remained active in the codebase over the years.

Yes, but that's an entirely different situation than the one I'm targeting in the article. But yes, in that case you have better chances. Even so, there is the Netscape story as evidence to the contrary.

And I'm sure Netscape is far from alone in that category ;-)

But (disclaimer) as someone who as advocated for big-bang-rewrite's before, I'm still under the impression that there are situations where they can be net-better.

Factors may include:

- there is no database involved, just code. Even more helpful if the existing code is "pure".

- a single developer can hold the functionality in their head.

- there are few bugs-as-features, tricky edge cases that must be backwards-compatibility, etc.

- as stated above, it's the primary author.

- much of the existing functionality is poor, and the path for building, launching, and shifting to a "replacement product" is relatively clear.

Advocating to never rewrite can be harmful, and make things harder for people for whom that actually would be the best approach.

Re: How to Improve a Legacy Codebase

#215

Post by crdoconnor »

naasking wrote: post #211
crdoconnor wrote: post #179

Earlier quoted context omitted.

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…

> 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. Because that's too technical. You have to frame the problems in terms that impact them or their employees in terms of use…

Note that I said "I've tried explaining WHY", not "I've tried explaining what a TCP/IP stack is".

The explaining "why" in and of itself isn't particularly hard - refactoring and development tooling will speed up development in the future and reduce bugs. It's getting it prioritized that's hard - and that's because the business case of 'potentially reducing the likelihood of bugs in the future' and 'a story 3 months from now might take 3 days instead of 2' isn't a particularly compelling one - not because it's not important - but because it's not visceral and concrete enough.

In practice I've seen what this does. The process of introducing transaction costs (having to 'sell' the case of refactoring code is exactly that) simply stops it from happening.

If, as a business, you want to introduce this transaction code into your development process you will end up paying more dearly for it in the long run as you deal with the effects of compounding technical debt.

Re: How to Improve a Legacy Codebase

#216

Post by BurningFrog »

_virtu wrote: post #2

How does one get better if they only ever work in code bases that are steaming piles of manure? So far I've worked at two places and the code bases have been in this state to an extreme. I feel like I've been in this mode since the very beginning of my career and am worried that my skill growth has been negatively impacted by this. I work on my own side projects, read lots of other people's code on github and am alwa…

I've learned an enormous amount from fixing terrible bugs in terrible code.

One tip is that when you've finally found the actual line(s) with the bug, always try to understand why the programmer made that mistake.

This has taught me much about what constructs are error prone.

Re: How to Improve a Legacy Codebase

#217

Post by crdoconnor »

DougWebb wrote: post #206
crdoconnor wrote: post #179

Earlier quoted context omitted.

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 al…

Who the fuck writes a fully costed business case on whether or not to spend a day setting up a CI server?

I'm trying to get some fucking work done, not convince investors I need a series A.

Re: How to Improve a Legacy Codebase

#218

Post by specialist »

vickychijwani wrote: post #201
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…

Build numbers, internal accounting process, engineering.

Semver, outsiders view, marketing.

Two different things, conflating them causes heartache. Keep them separate.

Re: How to Improve a Legacy Codebase

#219

Post by dllthomas »

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…

If a change is hard to make, first make the changes that will make it easy. Recurse.

Re: How to Improve a Legacy Codebase

#220

Post by beachy »

crdoconnor wrote: post #217
DougWebb wrote: post #206

Earlier quoted context omitted.

"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 al…

Who the fuck writes a fully costed business case on whether or not to spend a day setting up a CI server? I'm trying to get some fucking work done, not convince investors I need a series A.

Yes. This sort of cost-benefit analysis also ignores some intangibles such as:

"When we're interviewing people and they find out just how backwards our CI system is, the smart ones will laugh at us and work somewhere else and we'll be left with just the dumb ones."

Post reply on HN