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

281–290 of 300 posts

Re: How to Improve a Legacy Codebase

#281

Post by Roboprog »

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.

If you have it, it's nice to have a build/CI server that has a UI showing all the projects in a dept/work-group and where they come from in source control.

Re: How to Improve a Legacy Codebase

#282

Post by Roboprog »

joobus wrote: post #274
chiph wrote: post #271

Earlier quoted context omitted.

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

Exactly. Because...

It started out on...

That Novell drive

... but then...

That Win95 share

... Samba

... Wiki

... Sharepoint

... nah, let's start using Confluence now

etc.

Re: How to Improve a Legacy Codebase

#283

Post by Roboprog »

nulagrithom wrote: post #251
Roboprog wrote: post #248

Earlier quoted context omitted.

Don't forget that JS is often in a UI, doing asynchronous event/IO handling, so testing timing is important, not just spelling. (great, that's exactly the property names that object would have had, if it existed yet) That, and it's often reading in data (JSON or XML) from another system, and it is what it is, so see if it quacks or not. From the people that brought you SOAP, it's (drum roll) TYPE SCRIPT! It's not rea…

So because Microsoft made SOAP and also made TypeScript then TypeScript must be bad? That's nonsense. Also, I'm not a frontend guy, and the comment I was replying to was talking about node.js, but having to put a setTimeout or something in your tests just seems wrong.

On the one hand, argumentum ad hominem is a logical fallacy.

On the other hand, expecting not to be bit after the last dozen times seems kinda stupid. I'm not a fan of MS.

Re: How to Improve a Legacy Codebase

#284

Post by Roboprog »

nulagrithom wrote: post #251
Roboprog wrote: post #248

Earlier quoted context omitted.

Don't forget that JS is often in a UI, doing asynchronous event/IO handling, so testing timing is important, not just spelling. (great, that's exactly the property names that object would have had, if it existed yet) That, and it's often reading in data (JSON or XML) from another system, and it is what it is, so see if it quacks or not. From the people that brought you SOAP, it's (drum roll) TYPE SCRIPT! It's not rea…

So because Microsoft made SOAP and also made TypeScript then TypeScript must be bad? That's nonsense. Also, I'm not a frontend guy, and the comment I was replying to was talking about node.js, but having to put a setTimeout or something in your tests just seems wrong.

re: timeout. Yeah, waiting for one (or many!) other async operation(s) to complete in response to an event is a nuisance, but that's how it works, in particular if you don't want a UI to freeze up.

Full stack is hard, at least if somebody wants you to swap in and out of levels several times a week. But that's another rant about ruining projects...

Re: How to Improve a Legacy Codebase

#285

Post by specialist »

erikpukinskis wrote: post #152
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…

> re: Write Your Tests, I've never been successful with this ... I wouldn't bother to write unit tests etc for code that is likely to be culled, replaced. I think you misread the author. He says "Before you make any changes at all write as many end-to-end and integration tests as you can." (emphasis mine) > My go-to strategy has been blackbox (comparison) testing. Capture as much input & output as I can. Then use aut…

Belated reply, sorry. Been chewing.

Methinks I've prioritized writing of tests, of any kind, based on perceived (or acknowledged) risks.

Hmmm, not really like event logs. More of a data processing view of the world. Input, processing, output. When/if possible, decouple the data (protocol and payloads) from the transport.

First example, my team inherited some PostScript processing software. So to start we greedily found all the test reference files we could, captured the output, called those the test suite. Capturing input and output requires lots of manual inspection upfront.

Second sorta example, whenever I inherit an HTTP based something (WSDL, SOAP, REST), I capture validated requests and generated responses.

Re: How to Improve a Legacy Codebase

#286

Post by crdoconnor »

sobani wrote: post #258
beachy wrote: post #220

Earlier quoted context omitted.

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

As @DougWebb said, immediate cost saved is the easiest way to sell CI, especially if the savings are large. He didn't say it was the only way. Nor that you can't add more arguments if cost savings alone isn't convincing enough.

CI's cost savings will not be immediate, large or easy to measure. That's why creating this "sales process" to make them happen is such a toxic mistake.

I worked somewhere once that forced me to spend political capital to make these kinds of things happen and it was a terrible waste.

Nobody notices the disasters that don't happen and when somebody is 2x faster and develops code with fewer bugs, that tends to reflect well upon them even if they were building upon your work.

Re: How to Improve a Legacy Codebase

#287

Post by HelloNurse »

noway421 wrote: post #232
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…

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.

No, the time/effort to make a build with a working CI system is zero, plus any activities that remain manual by design (e.g. installations that require physical access to the server). The uncertainty is only about the feasibility and cost of implementing CI: this is one of the rare cases in which the benefits of software can be measured objectively, easily and in advance.

Re: How to Improve a Legacy Codebase

#288

Post by HelloNurse »

iamNumber4 wrote: post #86

Sometimes you get an entire septic tank full of... Code base that is non-existent, as the previous attempts were done with MS BI (SSIS) tools (for all things SSIS is not for) and/or SQL Stored procedures, with no consistency on coding style, documentation, over 200 hundred databases (sometimes 3 per process that only exist to house a handful of stored procedures), and a complete developer turn over rate of about ever…

Can you convince management that development in this situation is horrible and expensive and that there are better architectures?

Re: How to Improve a Legacy Codebase

#289

Post by MaulingMonkey »

crdoconnor wrote: post #260
ethbro wrote: post #190

Earlier quoted context omitted.

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

>If you're explaining it in terms of internals and implementation details, then you're always going to get this response. You're also going to get this response if you explain in terms of a business case. The business case for literally every refactoring/tooling story is this, btw: This story will cut down the number of bugs and speed up development. By how much will they speed up development? I don't know. How many…

> This story will cut down the number of bugs and speed up development. By how much will they speed up development? I don't know. How many bugs and of what severity? Some bugs and at multiple levels of severity and you're not going to notice it when it happens because nobody notices bugs that don't happen. By when? I don't know, but you won't see any impact straight away.

Point to historical data where possible. SWAG where appropriate.

"We've probably spent over 100 hours fixing bugs in this janky ass system for every 10 hours of real honest-to-god implementation of features work. That outage on Friday? Missing our last milestone by a week? All avoidable. We've been flying blind because we have no instrumentation, and changes are painful. Proper tooling would've shown us exactly what was wrong, easily halving our fix time, even if nothing else about this system changed. A week's worth of investment would've already paid itself off."

Frankly, I'm way better at estimating this kind of impact than how long it'll take to implement feature X.

Re: How to Improve a Legacy Codebase

#290

Post by MaulingMonkey »

noway421 wrote: post #280
DougWebb wrote: post #247

Earlier quoted context omitted.

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.

I can conjure a scientific wild ass guess on the spot.

"I wasted around 10 hours last week thanks to inadvertently pulling broken builds because we don't have a CI server. I spent 4 hours manually deploying things because we don't have a CI server."

"When can I move the new CI server I already setup on my workstation - because fuck wasting half my week to that nonsense, and I had nothing better to do while the devs who broke the build fixed it - to a proper server where everyone can benefit?"

Extrapolating, that's what - 4 months per year of potential savings?

Sure, 14 hours might not be enough time to automate your entire build process, but it should be enough to automate some of it, get some low hanging fruit and start seeing immediate gains. Incrementally improve it for more gains when you're waiting for devs to fix the build for stuff the CI server didn't catch.

Post reply on HN