Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

understandlegacycode.com

Post reply on HN
Print view View original

41–50 of 88 posts

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

#41

Post by w10-1 »

Ah, no: incremental approaches only work in already well-formed code.

Poor code requires not coding but analysis and decisions, partitioning code and clients. So:

1. Stop writing code

2. Buy or write tools to analyze the code (modularity) and use-case (clients)

3. Make 3+ rough plans:

(a) leave it alone and manage quality;

(b) identify severable parts to fix and how (same clients);

(3) incrementally migrate (important) clients to something new

The key lesson is that incremental improvements are sinking money (and worse, time) into something that might need to go, without any real context for whether it's worth it.

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

#42

Post by ipsento606 »

charles_f wrote: post #8

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.

I've been working on react and react native applications professionally for over ten years, and I have never worked on a project with any kind of meaningful test coverage

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

#43

Post by sublinear »

jeremyscanvic wrote: post #35

Is it possible in practice to control the side effects of making changes in a huge legacy code base? Maybe the software crashes when you write 42 in some field and you're able to tell it's due to a missing division-by-zero check deep down in the code base. Your gut tells you you should add the check but who knows if something relies on this bug somehow, plus you've never heard of anyone having issues with values othe…

I've never seen code truly get that bad, but I can already think of several problems with that approach.

Do you really know all of the expected behavior you're hardcoding in? What happens if your hardcoded behavior is just incorrect enough that it breaks something somewhere else? How can you be sure that your test for that specific value is even correct?

I think the better approach is to let things break naturally and open a bug with your findings. You'd be surprised how often someone else knows exactly what's going on and can fix it correctly. Your hacks are not just pouring gasoline onto the fire, but opening a well directly underneath that will keep it burning for a long time.

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

#44

Post by niccl »

jeremyscanvic wrote: post #35

Is it possible in practice to control the side effects of making changes in a huge legacy code base? Maybe the software crashes when you write 42 in some field and you're able to tell it's due to a missing division-by-zero check deep down in the code base. Your gut tells you you should add the check but who knows if something relies on this bug somehow, plus you've never heard of anyone having issues with values othe…

All. The. Time. And I hate it. Imagine giving a customer a rebate based on buggy code. You fix a bug, the customer comes back and wants to check that the rebate was correct that last time. Now you have to somehow hard-code the rebate they did get so that your (slightly less buggy) code gives the same result. But hard-coding has the risk of introducing other errors on its own. Oh yes, and you've never enough time to do things properly because Customers (or maybe Management). A tangled mess of soul destroying lifeblood-sucking code and pressures ensues.

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

#45

Post by stronglikedan »

ipsento606 wrote: post #42
charles_f wrote: post #8

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.

I've been working on react and react native applications professionally for over ten years, and I have never worked on a project with any kind of meaningful test coverage

over 20 years, many stacks, and same

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

#46

Post by quesera »

kaffekaka wrote: post #34
bee_rider wrote: post #18

Earlier quoted context omitted.

FWIW Mikado seems to be the name of that game where you pick up one stick at a time from a pile, while trying to not disturb the pile. (I forget the exact rules). So it isn’t as if somebody is trying to name this method after themselves or something, it is just an attempt at an evocative made up term. Timeboxing is also, right? I mean, timeboxing is not recognized by my spell checker (I’d agree that it is more intuit…

Plockepinn in Swedish, approximately "pickastick". Edit: thought I read it was of Scandinavian origin, hence my comment. But Wikipedia said european origin. Well well.

In the US, it was a game called "pick up sticks", and it was tedious and sometimes impossible.

So, this method is well-named at least! :)

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

#47

Post by locknitpicker »

ipsento606 wrote: post #42
charles_f wrote: post #8

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.

I've been working on react and react native applications professionally for over ten years, and I have never worked on a project with any kind of meaningful test coverage

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

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

#48

Post by eastbound »

bob1029 wrote: post #37

My favorite tool for trying scary complicated things in an unknown space is the feature flag. This works even if you have zero tests and no documentation. The only thing you need is the live production system and a way to toggle the flag at runtime. If you can ship your hypothesis along with an effectively unaltered version of prod, the ability to test things without breaking other things becomes much more feasible.…

You’ve just resolved a problem I had. I had this problem on a search engine, but I made it as a “v2”. And I told customers to switch to v2. And you know the v2 problem: Discrepancies that customers like. So both versions have fans, but we really need to pull the plug on v1. You’ve just solved it: I should have indexed even records with v1, odd records with v2. Then only I would know which engine was used.

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

#49

Post by csours »

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 expectation; however, without a mature understanding of failure, that expectation may just be misery.

With a mature understanding of failure, the possibility of a forced rollback should help you "let go" of those changes. It's like starting a day of painting or drawing with one that you force yourself to throw away; or a writing session with a silly page.

----

If someone thinks that they are giving you good advice, but it sounds terrible, then maybe they are expecting you to do some more work to realize the value of that advice.

If you are giving someone advice and they push back, maybe you are implying some extra work or expectations that you have not actually said out loud.

Advice is plagued by the tacit knowledge problem.

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

#50

Post by ipsento606 »

locknitpicker wrote: post #47
ipsento606 wrote: post #42

Earlier quoted context omitted.

I've been working on react and react native applications professionally for over ten years, and I have never worked on a project with any kind of meaningful test coverage

> 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.
Post reply on HN