How to Improve a Legacy Codebase • Hacker News Board

Re: How to Improve a Legacy Codebase

#181

Post by OutsmartDan » Tue, May 30, 2017, 7:51 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…

Software is only as good as the people that write it. In an ideal world, you'll have a team that specializes in this sort of things, can understand the business needs, and get it done.

There are always risks with every action taken. You can't be scared to take a big risk for a bigger payout versus sucking it up and doing things the way they've been done for 15 years.

Re: How to Improve a Legacy Codebase

#182

Post by buzzybee » Tue, May 30, 2017, 7:55 PM UTC

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…

What tends to happen as you refactor bad code is that you gain some intuition about the way the code needs to flow. The longer you spend grinding away at the existing code, the more likely it is that rewriting it will work, because you'll have pent-up "architectural energy" waiting to be used, and good, already-debugged code from the previous version that can be copied in.

The most likely causation for crossing a threshold from refactor to rewrite, while steering clear of the "big bang rewrite", is that you have to ship a feature that triggers an end-run around some of the existing architecture. So you ship both new architecture and the new feature, and then it works so well that you can deprecate the old one almost immediately, eliminating entire modules that proved redundant.

Edit: And if you don't really know where to start when refactoring, start by inlining more of the code so that it runs straightline and has copy-pasted elements(you can use a comment to note this: "inlined from foo()"). This will surface the biggest redundancies at a minimum of effort.

Re: How to Improve a Legacy Codebase

#183

Post by OutsmartDan » Tue, May 30, 2017, 7:55 PM UTC

vincnetas wrote: post #39

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…

This might be true (big bang rewrite) for small web sites or non business critical utility software, but if your cash flow depends on the software, you do not want failing software to stop that cash flow.

Correct- rewrites should be done in tandem with maintaining legacy systems until the new system is finished.

There should be some sort of overlap before completely sunsetting the old system.

Re: How to Improve a Legacy Codebase

#184

Post by OutsmartDan » Tue, May 30, 2017, 7:57 PM UTC

eej71 wrote: post #96

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…

The issue to think about is - if you don't know enough to "upgrade/replace in place" - then you probably won't know enough to rewrite from scratch.

That's why you need product owners/managers to cover the business logic and design a system that incorporates it. There needs to be tiers of coordinations to make sure a system is built to spec. TDD plays a big part in rebuilding legacy codebases.

Re: How to Improve a Legacy Codebase

#185

Post by collinmanderson » Tue, May 30, 2017, 7:58 PM UTC

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'd say as long as you've read and understand nearly every line of code in the old system, you're good to rewrite it from scratch.

Re: How to Improve a Legacy Codebase

#186

Post by sz4kerto » Tue, May 30, 2017, 8:06 PM UTC

jacquesm wrote: post #141

sz4kerto wrote: post #133

Earlier quoted context omitted.

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.

Ad hominem and appeal to authority are not the best way to argue about technology, so let's leave this.

(It feels really odd that someone tells me that he's making a living after cleaning up after people like me while so far I've thought I am paid for scaling small, poorly written systems up to enterprise levels, but well. I'd have appreciated more if we could have talked about specifics instead of "this works because I know it works").

Re: How to Improve a Legacy Codebase

#187

Post by gnaritas » Tue, May 30, 2017, 8:07 PM UTC

stickfigure wrote: post #153

maxxxxx wrote: post #79

How do people handle this in dynamic languages like JavaScript? I have done a lot of incremental refactoring in C++ and C# and there the compiler usually helped to find problems. I am now working on a node.js app and I find it really hard to make any changes. Even typos when renaming a variable often go undetected unless you have perfect test coverage. This is not even a large code base and I find it already hard to…

I think you just captured the essence of why micro services are so popular. Dynamic languages just don't scale to large codebases, so there's enormous pressure to decompose software into chunks that can be digested more easily. Some amount of this is good, but it often forces the chunk boundaries to be smaller than the "natural" clumping of data and behavior in a distributed system. IMHO this is a much worse problem…

> Dynamic languages just don't scale to large codebases

You mean "popular" dynamic languages due to their lack of tooling. Dynamic languages like Smalltalk scale up just fine, but Smalltalk has automated refactoring tools. In other words it's a tool support problem, not a dynamic language problem.

Re: How to Improve a Legacy Codebase

#188

Post by protomyth » Tue, May 30, 2017, 8:10 PM UTC

cntlzw wrote: post #65

protomyth wrote: post #50

Earlier quoted context omitted.

It is amazing how much of our profession's knowledge ends up as a odd if statement buried deep in the code to some method or stored procedure dealing with an edge case that gets missed in the big bang rewrite. Its also amazing how much money the failure to preserve that knowledge can cost. I wonder if its time for professional software archeologists?

Writing software is still "creative" and less "engineering". There aren't many ways to build a bridge but many ways to express yourself in language. Natural language or computer language that is. Add this to "business requirements" and you get the big pile of manure we walk in every day. Like how does the knowledge of IEEE754 help me if the requirement is to sum up some value of the last three days, unless the last t…

Strangely, at all the big corp jobs I've been at, the good programmers have become domain experts as part of the job. How else could they have a real feel for what the business needed and if the code was correct?

Re: How to Improve a Legacy Codebase

#189

Post by Mz » Tue, May 30, 2017, 8:12 PM UTC

sz4kerto wrote: post #186

jacquesm wrote: post #141

Earlier quoted context omitted.

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.

Ad hominem and appeal to authority are not the best way to argue about technology, so let's leave this. (It feels really odd that someone tells me that he's making a living after cleaning up after people like me while so far I've thought I am paid for scaling small, poorly written systems up to enterprise levels, but well. I'd have appreciated more if we could have talked about specifics instead of "this works becaus…

Ad hominem and appeal to authority are not the best way to argue about technology, so let's leave this.

It seems to be de riguer when dealing with some of the top ranked people on HN, who all too often seem to have long ago forgotten the rules that they apparently think no longer apply to them because they have more karma than god.

My hat is off to you in how well you handled this.

Re: How to Improve a Legacy Codebase

#190

Post by ethbro » Tue, May 30, 2017, 8:20 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…

> In almost all cases they nod and feign interest and understanding and their eyes glaze over. And why should they be interested? The stories are almost always abstract and the ROI is even more abstract. It's all implementation details to them.

If you're explaining it in terms of internals and implementation details, then you're always going to get this response.

Your job as a business-facing developer is to translate the technical details (in as honest a way as is possible) into a business outcome.

I'm not naive. We've all worked with stakeholders that make stupid choices and can't seem to grasp a point dangled right in front of them.

But. Even more often than that I've seen (especially in-house) IT talk down to the business, push an agenda through the way they summarize an issue or need, and try to use technical merits to subvert corporate decision making.

Ultimately, you're in it together with business stakeholders. Either you trust each other, or you don't. And "the business can't be trusted to make decisions that have technical impacts" is the first step towards a decay of trust on both sides.