Live data from Hacker News

Use the Mikado Method to do safe changes in a complex codebase

understandlegacycode.com

81–88 of 88 posts

Re: Use the Mikado Method to do safe changes in a complex codebase

#81

Write tests. Most likely those 300k lines of code contain a TESST folder with 4 unit tests written by an intern who retired to become a bonsai farmer in the 1990s, and none of them pass anymore. Things become much less stressful if you have something basic telling you you're still good.

A difficult prerequisite for that might be untangling a very unatomic codebase into testable chunks. And to determine a feasible "level of abstraction" to write tests for. Testing a full pipeline of a numerical library might be as impractical as testing super tiny functions, because both won't allow you to really work on the codebase.

Re: Use the Mikado Method to do safe changes in a complex codebase

#82
One of my latest linguistic pet peeves is usage of the overly simple and nondescript word "do" when other verbs would describe more succinctly what is happening.

You don't "do" changes. This sounds lazy at best, unintelligent at worst, and fails to communicate what's happening. "Make changes" would be better diction and more appropriate vernacular. You could even "enact changes upon" or "affect changes to."

Alternatively, drop the extra verb altogether: "Use the Mikado Method to change complex codebases safely"

> After a couple of minutes, just stop and think. What’s missing? What would make it easier to do that change, like the previous one?

"Perform." Not "do." You would be _performing_ a change.

But hey at least I'm pretty sure an LLM didn't write this article =)

Re: Use the Mikado Method to do safe changes in a complex codebase

#84
post #49

This sounds like torture (as written). Of course, working in a legacy codebase is also torture. Software development is a hyper-rational endeavor, so we don't often talk about feelings. This article also does not talk much about feelings. Reading between the lines, it looks like reverting the code is supposed to affect how you feel about the work. Knowing that failure is an explicit option can help to set an expectat…

I'm reminded of a talk I enjoyed about "extreme rewriting" [1] — how rewriting the same code many times (in certain contexts) can help uncover powerful underlying abstractions.

It makes intuitive sense to me that this would be true in complex domains (e.g. legacy code) where you really need to find the right solution, even if it takes a bit longer. Our first ideas are rarely our best ideas, and it's easy to get too attached to your first solution and try to tweak it into shape when it would be better just to start fresh.

[1]: https://www.hytradboi.com/2025/03580e19-4646-4fba-91c3-17eab...

Re: Use the Mikado Method to do safe changes in a complex codebase

#85
post #39

Earlier quoted context omitted.

It helps if tests are well written such that they help you with refactoring, rather than just being the implementation (or a tightly coupled equivalent) but with assertions in it. Rare to see though. I don't think being able to write code automatically means you can write decent tests. Skill needs to be developed.

And the challenge with writing tests well is that it might be difficult or impossible without the refactor...

I disagree. There is no code that can't be tested. There is certainly no code that has to be changed so it can be tested.

The only reason you would decide code is untestable without touching it is because it doesn't seem worth the effort, so you test the thing that calls that code instead and mock it out.

At the highest level it is all inputs and outputs after all. Your spaghetti app can still be tested end-to-end, which will cost you the most but will work.

We're talking about SaaS and web apps and shit here of course, because we're on HN where downtime on Cloudflare equals a day off work. In other industries you'd be running full blown simulations and proofs and maybe even inventing new mechanisms of testing so you can get a hard project off the ground. Maybe even fabricating materials.

Re: Use the Mikado Method to do safe changes in a complex codebase

#86

Earlier quoted context omitted.

> I have never worked on a project with any kind of meaningful test coverage That says more about you and the care you put into quality assurance than anything else, really.

Presumably you mean me, and every current and former team-member I've ever had? If so, you're talking about hundreds of engineers.

> Presumably you mean me, and every current and former team-member I've ever had?

Yes, I mean you.

You don't need hundreds of engineers to have a test suite with meaningful coverage. You need yourself and willingness to do the job.

Just adding happy path tests can get you significant coverage. Why did you failed to do this?

Blaming others for the problems you created and help create is not helpful. You can post PRs, can't you?

Re: Use the Mikado Method to do safe changes in a complex codebase

#87

Earlier quoted context omitted.

> I have never worked on a project with any kind of meaningful test coverage That says more about you and the care you put into quality assurance than anything else, really.

Have you ever worked at a place where you were put on an existing codebase, and that code has no tests? Have you ever worked at a place where, when you try to fix that, management tells you that they don't have the time to do so, they have to crank out new features? Is ipsento606 working at such a place? I don't know, and neither do you. Why do you jump to the conclusion that it's their personal failing?

> Have you ever worked at a place where you were put on an existing codebase, and that code has no tests?

Yes.

Then I added tests. Now the codebase has tests.

Funny how that works.

> Have you ever worked at a place where, when you try to fix that, management tells you that they don't have the time to do so, they have to crank out new features?

Yes.

I then added tests that covered my features. Now the project has tests.

Funny how that works.

Re: Use the Mikado Method to do safe changes in a complex codebase

#88
post #85

Earlier quoted context omitted.

And the challenge with writing tests well is that it might be difficult or impossible without the refactor...

I disagree. There is no code that can't be tested. There is certainly no code that has to be changed so it can be tested. The only reason you would decide code is untestable without touching it is because it doesn't seem worth the effort, so you test the thing that calls that code instead and mock it out. At the highest level it is all inputs and outputs after all. Your spaghetti app can still be tested end-to-end, w…

> ...the challenge with writing tests well...

Sure, you can test more or less anything given sufficient time and force, but a massive fragile harness wrapped around the system under test is not what I mean by 'testing well'.

Also there are other things in software besides web; unit testing code that is entangled with desktop UI can be difficult or impossible without changing the original code. Try testing a WPF app that talks directly to the Dispatcher when there is no UI thread, for example.

Post reply on HN