How to Improve a Legacy Codebase • Hacker News Board

Re: How to Improve a Legacy Codebase

#191

Post by busterarm » Tue, May 30, 2017, 8:39 PM UTC

collinmanderson wrote: post #185

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.

And if you write the test suite first, you're in a much better position to do this successfully.

Re: How to Improve a Legacy Codebase

#192

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

We can talk about specifics, I linked one very particular job here (the one that I was fortunate enough to be allowed to write about, which is normally not the case) and I've invited you to give your own stories.

As you can see elsewhere in this thread I'm more than willing to change my tune and/or update the post if there is relevant information.

But your initial tone of voice + your categorical denial that these things are valuable makes it a bit harder to find common ground.

If you are scaling small poorly written systems then that already gives one very important data point that is divergent with the situation I've written about. The systems you start with are small, the systems I start with are usually large to very large and are running a mid to large enterprise and are - if you're lucky - a decade old or even much older. Either that or they are recent - and totally botched - rewrites.

If you are happy in your groove then more power to you but chances are that sooner or later you too will be handed a pile of manure without a shovel to go with it and maybe then you'll find some useful tips in that blogpost.

And the bit about the bookkeeping applies to your situation just as much as it does to larger and older systems.

Re: How to Improve a Legacy Codebase

#193

Post by jacquesm » Tue, May 30, 2017, 8:47 PM UTC

Mz wrote: post #189

sz4kerto wrote: post #186

Earlier quoted context omitted.

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.

Michele, I know you don't like me and I know you feel the need to insert your $0.02 wherever you feel you can stick the knife in. What drives you to do this I have absolutely no clue, but I'm sure you have your reasons. Enjoy.

Re: How to Improve a Legacy Codebase

#194

Post by alkonaut » Tue, May 30, 2017, 8:50 PM UTC

artursapek wrote: post #9

Are there businesses building automation and tooling for working with legacy codebases? It seems like a really good "niche" for a startup. The target market grows faster every year :)

Tools like NDEpend (for .NET) help me a bit with modularizing.

I doubt we'll ever see automation beyond what we do today in this space.

Re: How to Improve a Legacy Codebase

#195

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

jacquesm wrote: post #193

Mz wrote: post #189

Earlier quoted context omitted.

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.

Michele, I know you don't like me and I know you feel the need to insert your $0.02 wherever you feel you can stick the knife in. What drives you to do this I have absolutely no clue, but I'm sure you have your reasons. Enjoy.

I don't dislike you, I just dislike the degree to which you have zero respect for me. I think you are full well aware of the reasons I do the things I do.

I don't look to stick anyone with a knife. It is shocking how comfortable people are with casually watching my suffering and doing nothing about it while acting like any push back I give against the systemic issues that help keep me trapped in dire poverty somehow makes me evil incarnate.

Re: How to Improve a Legacy Codebase

#196

Post by jacquesm » Tue, May 30, 2017, 8:56 PM UTC

Mz wrote: post #195

jacquesm wrote: post #193

Earlier quoted context omitted.

Michele, I know you don't like me and I know you feel the need to insert your $0.02 wherever you feel you can stick the knife in. What drives you to do this I have absolutely no clue, but I'm sure you have your reasons. Enjoy.

I don't dislike you, I just dislike the degree to which you have zero respect for me. I think you are full well aware of the reasons I do the things I do. I don't look to stick anyone with a knife. It is shocking how comfortable people are with casually watching my suffering and doing nothing about it while acting like any push back I give against the systemic issues that help keep me trapped in dire poverty somehow…

I have zero respect for you because of how you treat others.

Promising them the moon to only yank the rug out from under them when it matters. You know full well what I'm talking about here and that's something that I will not forgive you for.

Your circumstances have nothing to do with any of this.

Re: How to Improve a Legacy Codebase

#197

Post by busterarm » Tue, May 30, 2017, 8:56 PM UTC

All of this seems to focus on the code, after glossing over the career management implications in the first paragraph.

I've done this sort of work quite a number of times and I've made mistakes and learned what works there.

It's actually the most difficult part to navigate successfully. If you already have management's trust (i.e., you have the political power in your organization to push a deadline or halt work), you're golden and all of the things mentioned in the OP are achievable. If not, you're going to have to make huge compromises. Front-load high-visibility deliverables and make sure they get done. Prove that it's possible.

Scenario 1) I came in as a sub-contractor to help spread the workload (from 2 to 3) building out a very early-stage application for dealing with medical records. I came in and saw the codebase was an absolute wretched mess. DB schema full of junk, wide tables, broken and leaking API routes. I spent the first two weeks just bulletproofing the whole application backend and whipping it into shape before adding new features for a little while and being fired shortly afterwards.

Lesson: Someone else was paying the bills and there wasn't enough visibility/show-off factor for the work I was doing so they couldn't justify continuing to pay me. It doesn't really matter that they couldn't add new features until I fixed things. It only matters that the client couldn't visibly see the work I did.

Scenario 2) I was hired on as a web developer to a company and it immediately came to my attention that a huge, business-critical ETL project was very behind schedule. The development component had a due date three weeks preceding my start date and they didn't have anyone working on it. I asked to take that on, worked like a dog on it and knocked it out of the park. The first three months of my work there immediately saved the company about a half-million dollars. Overall we launched on time and I became point person in the organization for anything related to its data.

Lesson: Come in and kick ass right away and you'll earn a ton of trust in your organization to do the right things the right way.

Re: How to Improve a Legacy Codebase

#198

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

jacquesm wrote: post #196

Mz wrote: post #195

Earlier quoted context omitted.

I don't dislike you, I just dislike the degree to which you have zero respect for me. I think you are full well aware of the reasons I do the things I do. I don't look to stick anyone with a knife. It is shocking how comfortable people are with casually watching my suffering and doing nothing about it while acting like any push back I give against the systemic issues that help keep me trapped in dire poverty somehow…

I have zero respect for you because of how you treat others. Promising them the moon to only yank the rug out from under them when it matters. You know full well what I'm talking about here and that's something that I will not forgive you for. Your circumstances have nothing to do with any of this.

Promising them the moon to only yank the rug out from under them when it matters. You know full well what I'm talking about here and that's something that I will not forgive you for.

If I am guessing correctly as to what you are talking about, you have that backwards. That person abandoned me. I did not abandon them.

Re: How to Improve a Legacy Codebase

#199

Post by MaulingMonkey » Tue, May 30, 2017, 9:12 PM UTC

thehardsphere wrote: post #107

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.

My preferred definition here, is that a big bang rewrite is a monolithic rewrite so big it goes bang (fails), pushing things from "pretty much guaranteed to fail", to "is by definition a failure".

You might end up rewriting the entire codebase through an incremental approach ala the Ship of Theseus through a series of smaller rewrites, but that's something very different and distinct from a "big bang rewrite" to me.

Re: How to Improve a Legacy Codebase

#200

Post by kentt » Tue, May 30, 2017, 9:14 PM UTC

jacquesm wrote: post #111

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…

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.