How to Improve a Legacy Codebase • Hacker News Board

Re: How to Improve a Legacy Codebase

#271

Post by chiph » Wed, May 31, 2017, 1:19 PM UTC

Roboprog wrote: post #239

chiph wrote: post #52

Earlier quoted context omitted.

At the very least, write a doc that explains how to build the product, including where to find the parts in source control, what the dependencies are, what servers it'll get installed on, and so on. The goal being to increase your shop's "Bus Factor" https://en.wikipedia.org/wiki/Bus_factor

Something to be cognizant of when creating this "keystone" doc - not losing it on some "share" that nobody can find anymore. Thus, the use of README in the root directory of a project.

Since it would contain the location of the root directory, putting there would be circular. Hopefully the organization has a central location for their documentation that is somewhat organized (via SharePoint, or even a network share with folders). Reducing the number of things that a new hire would need to "just know" to a minimum should be a goal.

Re: How to Improve a Legacy Codebase

#272

Post by randomf1fan » Wed, May 31, 2017, 1:35 PM UTC

usmeteora wrote: post #266

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…

In my personal experience, the codebase is not the problem, but the people and the culture who made the codebase. We sent people to the moon with the computing power of a calculator, and with enough good people and effort, and version control, you can rewrite any legacy codebase to meet rigorous standards and meet the performance needs of the users. Out of all the things humanity is trying and has accomplished, this…

Your comment reflects what I heard last week from a friend. He's a PE (Professional Engineer) working with a large power utility company, and his company uses software that, in his words, "really sucks".

He was telling me this because he got a job offer from a startup, where they wanted him to be the subject matter expert for an application they were developing for power utilities.

It's a good offer, and he's tempted, but he's not sure if he can fit into the software/startup culture. In addition, he felt that the developers were looking to use him like a reference book - he got the impression that the founders saw software as the answer to everything, and that they didn't see power engineering as a particularly hard domain. There was (in his words) a distinct whiff of "developers are the cool guys".

This turned him off somewhat. So he's not sure if he'll take the offer, and I'd say he's leaning no.

Just an anecdote to illustrate the clash of cultures.

Re: How to Improve a Legacy Codebase

#273

Post by crdoconnor » Wed, May 31, 2017, 2:32 PM UTC

DougWebb wrote: post #268

crdoconnor wrote: post #262

Earlier quoted context omitted.

"Ah, I see the problem. You have no interest in understanding why your business makes the decisions it makes" No, the problem is that you believe that micromanagement is effective. "The reason you've failed to make a convincing case, I believe, is because you're talking in your language instead of theirs." No, the reason is because the ROI is vague and not easily costable and the time until expected return is usually…

At some point, dysfunctional management can't be overcome. I'm not really talking about that extreme case; I'm talking about the more common case where engineers don't understand management priorities because they're not aware of the business' non-technical concerns that are part of the prioritization decisions. If you want to spend a day on a CI server, it'll cost the company a day of your time (say, $1k) and will s…

>I'm talking about the more common case where engineers don't understand management priorities because they're not aware of the business' non-technical concerns that are part of the prioritization decisions.

Ok, so assuming:

* All user stories are prioritized by management.

* Management determines the exact % of time spent on refactoring stories.

* Refactoring stories are prioritized by devs and slotted alongside user stories (according to the % above).

What kind of hypothetical non-technical concerns that are part of managment's prioritization decisions would become a problem?

Because, as far as I can see, in such a case, it wouldn't matter if the devs are not aware of the non-technical concerns because those concerns would still be reflected by the prioritization.

Re: How to Improve a Legacy Codebase

#274

Post by joobus » Wed, May 31, 2017, 3:07 PM UTC

chiph wrote: post #271

Roboprog wrote: post #239

Earlier quoted context omitted.

Something to be cognizant of when creating this "keystone" doc - not losing it on some "share" that nobody can find anymore. Thus, the use of README in the root directory of a project.

Since it would contain the location of the root directory, putting there would be circular. Hopefully the organization has a central location for their documentation that is somewhat organized (via SharePoint, or even a network share with folders). Reducing the number of things that a new hire would need to "just know" to a minimum should be a goal.

> Hopefully the organization has a central location for their documentation that is somewhat organized...

My office uses a combination of Redmine, Slack, email, gitlab, network drives, google docs, dropbox, some pdfs floating around, and a readme in the root of each repo...

Re: How to Improve a Legacy Codebase

#275

Post by DougWebb » Wed, May 31, 2017, 3:09 PM UTC

crdoconnor wrote: post #273

DougWebb wrote: post #268

Earlier quoted context omitted.

At some point, dysfunctional management can't be overcome. I'm not really talking about that extreme case; I'm talking about the more common case where engineers don't understand management priorities because they're not aware of the business' non-technical concerns that are part of the prioritization decisions. If you want to spend a day on a CI server, it'll cost the company a day of your time (say, $1k) and will s…

>I'm talking about the more common case where engineers don't understand management priorities because they're not aware of the business' non-technical concerns that are part of the prioritization decisions. Ok, so assuming: * All user stories are prioritized by management. * Management determines the exact % of time spent on refactoring stories. * Refactoring stories are prioritized by devs and slotted alongside use…

If all three of your assumptions are true, then you're correct. The trick is getting the second two assumptions to be true. Management and devs have to agree on a % time split, and management has to agree with intermingled priorities instead of "dev % goes at the end".

Negotiating those agreements is where having a common ground on business concerns helps. And yes, it sure does help when the managers can also see things from the dev's point of view too. In my experience, it's easier for devs to understand business concerns than the other way around, so that's the way I lean.

Re: How to Improve a Legacy Codebase

#276

Post by raphar » Wed, May 31, 2017, 3:15 PM UTC

thijsvandien wrote: post #233

raphar wrote: post #166

Earlier quoted context omitted.

> write your tests. From my point of view, this is always key. The moment you can have testable components, it's the moment you can begin to decompose the old system in parts. Once you begin with decomposition, Its easier first to pick on low hanging fruits to show that you are advancing and then transitioning to the dificult parts. pd: I've been all my carreer maintaining & refactoring others code. I've never had an…

Interesting read for those who don't understand our fancy for legacy code: http://typicalprogrammer.com/the-joys-of-maintenance-program...

The article is a description of my career! Thanks for sharing.

Re: How to Improve a Legacy Codebase

#277

Post by xivusr » Wed, May 31, 2017, 3:40 PM UTC

markatkinson wrote: post #89

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 gasped when I saw this article at the top of HN due to the relevance of it right now in my life. I am currently working on a real monolithic jambalaya that suffers from a lack of documentation, architecture, extreme abstraction, rampant tight coupling and no previous source control. Your point on performing architecture discovery and documentation is spot on. It has really helped me to strip away the mess and under…

This article is painfully relevant for me. I just reviewed a code base with zero tests, documentation, no inheritance- rampant duplication.

It's a simple event tracking system and yet there are 75 models, and over 80 controllers. This was outsourced to a team which coincidentally appears to have close to that many devs working there. The good news is that according to the client "it pretty much works". I know better than to suggest a Big Bang - though it seems so appealing.

Documentation and code freeze are my next steps and implementing end to end testing.

Re: How to Improve a Legacy Codebase

#278

Post by stephenwilcock » Wed, May 31, 2017, 9:16 PM UTC

It is great to see more people sharing their strategies for managing legacy codebases. However, I thought it might be worth commenting on the suggestion about incrementing database counters:

> "add a single function to increment these counters based on the name of the event"

While the sentiment is a good one, I would warn against introducing counters in the database like this and incrementing them on every execution of a function. If transactions volumes are high, then depending on the locking strategy in your database, this could lead to blocking and locking. Operations that could previously execute in parallel independently now have to compete for a write lock on this shared counter, which could slow down throughput. In the worst case, if there are scenarios where two counters can be incremented inside different transactions, but in different sequences (not inconceivable in a legacy code), then you could introduce deadlocks.

Adding database writes to a legacy codebase is not without risk.

If volumes are low you might get away with it for a long time, but a better strategy would probably just to log the events to a file and aggregate them when you need them.

Re: How to Improve a Legacy Codebase

#279

Post by Flenser » Thu, Jun 01, 2017, 3:10 AM UTC

slavik81 wrote: post #256

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…

Setting up a CI server is not a user story. It doesn't deliver any value to the customer on its own, and thus is not really something that should be in the customer backlog. It should be rolled into the first story done on the project, as it's a part of setting up the development environment. Similarly, you probably didn't have a story for creating the git repository, nor one for installing your text editor. You work…

I've worked with people where every task was a user story. E.g.:

Title: Reveiw code for feature X

Description: As a OUR-APP product manager I want to understand how feature X is implemented.

Acceptance Criteria: AC1: Feature X is documented in the wiki in context Y. AC2: ...

Re: How to Improve a Legacy Codebase

#280

Post by noway421 » Thu, Jun 01, 2017, 3:23 AM UTC

DougWebb wrote: post #247

noway421 wrote: post #232

Earlier quoted context omitted.

Depending on how convoluted the case is, you don't know what the end result would save in costs. "we'll be saving __ hours/days of effort per build/year" is a complete unknown.

If the expected value of a task is a complete unknown, then there is NO business justification for doing the task. As an engineer with the responsibilty (or desire) to get business buy-in for a task, you must learn to quantify its value in terms that are meaningful to the business. It doesn't have to be cost, that just happens to be easiest because it can be opinion-free. You can also express value in terms of busine…

That's the thing, the research and cost assesment itself would take days of work. So not many would care, and one might argue why /should/ you care to begin with. That's how it ends up being stalled at the idea stage.