How to Improve a Legacy Codebase • Hacker News Board

Re: How to Improve a Legacy Codebase

#251

Post by nulagrithom » Wed, May 31, 2017, 4:53 AM UTC

Roboprog wrote: post #248

nulagrithom wrote: post #85

Earlier quoted context omitted.

Try TypeScript. Though I wouldn't think that test coverage needs "perfect" to catch a bad variable name, but maybe that's why there's so much obsessive tooling when it comes to coverage in the JavaScript world.

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: How to Improve a Legacy Codebase

#252

Post by sanderjd » Wed, May 31, 2017, 5:11 AM UTC

DougWebb wrote: post #249

sanderjd wrote: post #234

Earlier quoted context omitted.

You're making good points, but there is a lot of truth to your parent's sense that making a business case for every little thing is deeply inefficient. The hard part is striking a good balance between one extreme of arrogant engineers who never think about the business case for the things they are working on and the other extreme of having technical decisions micromanaged by non-technical managers.

Yes, it can be deeply inefficient, but so is not getting approval to do necessary work. You have to start making progress somewhere, even if it's not as fast as you'd like it to be. If you're sucessful with this, you gain credibility and over time your recommendation will be sufficient to get approval for smaller tasks, and the business case will only need to be made for bigger tasks. If you're not sucessful with thi…

> If you're sucessful with this, you gain credibility and over time your recommendation will be sufficient to get approval for smaller tasks, and the business case will only need to be made for bigger tasks.

Maybe! Alternatively: if you give a mouse a cookie, it will want a glass of milk. It might be worthwhile to establish early on that the technical leadership needs to be trusted to make their own decisions about trivial things.

Re: How to Improve a Legacy Codebase

#253

Post by alkonaut » Wed, May 31, 2017, 5:36 AM UTC

artursapek wrote: post #237

alkonaut wrote: post #194

Earlier quoted context omitted.

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.

> I doubt we'll ever see automation beyond what we do today in this space. Really? That's pretty pessimistic, considering what DeepMind is doing.

Yeah I'm very very pessimistic in that area. Effectively I think cleaning up bad/tangled OO code to be such a difficult problem that the level of AI required is beyond not just what we can achieve but beyond what we can imagine. For example I believe it's much harder than coding entirely new applications from text descriptions of its features. That would limit the usefulness of an AI that can untangle existing code...

Re: How to Improve a Legacy Codebase

#254

Post by gedrap » Wed, May 31, 2017, 6:21 AM UTC

jacquesm wrote: post #168

maxxxxx wrote: post #156

Earlier quoted context omitted.

"hundreds of microservices" I can't imagine a scenario where you need hundreds although I don't doubt that people will create such a system.

Do not underestimate architecture astronauts, ever.

I was reading "Building Microservices" by Sam Newman, he mentioned that some of his clients moved from monolith to 300+ microservices without going into details, so yeah, that made me wonder about it as well. (it was a decent book otherwise).

Re: How to Improve a Legacy Codebase

#255

Post by jacquesm » Wed, May 31, 2017, 7:05 AM UTC

alexwebb2 wrote: post #240

jacquesm wrote: post #226

Earlier quoted context omitted.

No, it just means that I have crew for jobs like these that knows their stuff. 500K lines is 'small' by our standards and if we are not moving within two weeks that translates into one very unhappy customer. That's something a typical team of 5 to 10 people has produced in a few years. Note that I wrote 'incremental' and 'starting'. That doesn't mean the job is finished at that point in time. But we should have a ver…

> 50 manyears worth of original work that has become unmaintainable for some reason or other (mass walk-out, technical debt out of control or something to that effect) That's the scale I'm talking about, so at least we're on the same page there. It sounds to me like your specialty routinely puts you in situations where the client has reached the end of the line and is in Hail Mary Mode, where they're amenable to havi…

I'd be more than happy to believe you if the comments in this thread weren't for the most part confirming my experience. On the other hand I'm more than willing to believe that there are plenty of places where none of this applies (though, I haven't seen them) and where with some slight variation you could get a lot of mileage out of these methods.

Because if the only extra constraint would be 'you can't halt development' then that's easy enough: simply iterate on smaller pieces and slip in the occasional roadmap item to grease the wheels. But that does assume that development had not yet ground to a halt in the first place.

The biggest difference between your experience and my experience I think is that our little band of friends is external, so we get to negotiate up front about what the constraints are and if we put two scenarios on the table, one of which is ~70% cheaper because we temporarily halt development completely then that is the most likely option for the customer to take.

Re: How to Improve a Legacy Codebase

#256

Post by slavik81 » Wed, May 31, 2017, 7:23 AM 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…

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 with your customer to decide what end-user bugfixes and features to prioritize, but it's your job to make technical decisions. That's why they hired you. Don't push those decisions back onto them.

Re: How to Improve a Legacy Codebase

#257

Post by HolyHaddock » Wed, May 31, 2017, 8:08 AM UTC

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…

> And frankly, if you can't point to bugs or performance issues, it's likely you don't need to be refactoring in the first place!

I feel this is a lack of clarity around the word refactoring. Improving the code in a way that fixes bugs is "bug fixing", in a way that makes it do its job faster is "optimisation" and in a way that improves the design is "refactoring".

Of course one can do several of them at the same time. And add features, at least in the small.

Refactoring can be a valuable activity for bits of a code base where the cost of change could be usefully reduced. It's useful to have a word that can be used to describe that activity that isn't commonly conflated with bug-fixing or optimisation.

Re: How to Improve a Legacy Codebase

#258

Post by sobani » Wed, May 31, 2017, 8:11 AM UTC

beachy wrote: post #220

crdoconnor wrote: post #217

Earlier quoted context omitted.

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

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.

Re: How to Improve a Legacy Codebase

#259

Post by jacquesm » Wed, May 31, 2017, 8:53 AM UTC

typednothing wrote: post #208

ebiester wrote: post #74

Earlier quoted context omitted.

The one caveat is that there are times when the business realizes that their old workflows and features aren't what they now need. The rewrite becomes a new project competing with the old rather than a functional rewrite. This is also fraught with peril. However, it is a different set of problems. In an ideal world, you have engineers who can make reasoned decisions. However, if the company culture allowed one applic…

At some point they'll junk the in-house program and buy something off the shelf.

Assuming something off the shelf is available, yes. In fact, if something off the shelf is available we'll be happy to make that recommendation, too many companies that aren't software houses suddenly feel that they need to write everything from the ground up. And even companies that are software houses suffer from NIH more often than not. (Though, I have to say that in my experience in the last couple of years or so this is improving, it used to be that every company had their own in-house developed framework but now we see more and more standardization.)

Re: How to Improve a Legacy Codebase

#260

Post by crdoconnor » Wed, May 31, 2017, 8:57 AM UTC

ethbro wrote: post #190

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…

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

The benefits are vague and abstract. The time until expected payoff is long. Vague, long term business cases don't get prioritized unless the prioritizer understands the gory details, which, as we both know, they won't.

The features and bugfixes - user stories - are not vague. They get prioritized.

>I'm not naive. We've all worked with stakeholders that make stupid choices

I am not complaining about stakeholders in general. I've worked with smart stakeholders and dumb stakeholders. I've never worked with a stakeholder that could appropriately compare the relative importance of my "refactor module B" story and "feature X which the business needs". All I've worked with are stakeholders who trusted me to do that part myself (which paid off for them) and stakeholders who insisted on doing it for the team because that's what SCRUM dictated (which ended badly for them).

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

No, the first (and indeed, only) step is not delivering.