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

51–60 of 88 posts

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

#51

Post by jaggederest »

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 can go even further with something like the gem scientist at the application level, or tee-testing at the data store level. Compare A and A', record the result, and return A. Eventually, you reach 100% compatibility between the two (or only deviations that are desirable) and can remove A, leaving only A'

I also like recording and replaying production traffic, as well, so that you can do your tee-testing in an environment that doesn't affect latency for production, but that's not quite the same thing.

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

#52

Post by nitnelave »

Also known as "Make the change easy, then make the change"

Something to realize is that every codebase is legacy. My best new feature implementations are always several commits that do no-op refactorings, with no changes to tests even with good coverage (or adding tests before the refactoring for better coverage), then one short and sweet commit with just the behavior change.

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

#55

Post by hinkley »

nitnelave wrote: post #52

Also known as "Make the change easy, then make the change" Something to realize is that every codebase is legacy. My best new feature implementations are always several commits that do no-op refactorings, with no changes to tests even with good coverage (or adding tests before the refactoring for better coverage), then one short and sweet commit with just the behavior change.

That’s just mostly refactoring in general.

Mikado is more of a get out of jail card for getting trapped in a “top down refactor” which is an oxymoron.

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

#56

Post by collingreen »

nitnelave wrote: post #52

Also known as "Make the change easy, then make the change" Something to realize is that every codebase is legacy. My best new feature implementations are always several commits that do no-op refactorings, with no changes to tests even with good coverage (or adding tests before the refactoring for better coverage), then one short and sweet commit with just the behavior change.

I also do this and try to teach it to others. One thing I add is trying to go even further and making it so the new feature can essentially be a configuration change (because you built the system already in the first steps). It doesn't fit every situation so it's by no means a hard rule but "prefer declaration functionality over imperative".

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

#57

Post by hinkley »

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

Feature flags are like bloom filters. They make 98 out of 100 situations better and they make the other 2 worse. When performance is the issue that’s usually fine. When reliability is the issue, that’s not sufficient.

If you work on fifty feature toggles a year, one of them is going to go wrong. If your team is doing a few hundred, you’re gonna have oopsies.

Most of the problematic cases are where the code is set up so that the old path and the new one can’t bypass each other cleanly. They get tangled up and maybe the toggle gets implemented inverted where it’s difficult to remove the old path without breaking the new.

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

#58

Post by AnimalMuppet »

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.

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?

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

#59

Post by bee_rider »

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.

I suspect it was invented the first time a parent dropped a pile of sticks because their bored kids were distracting them. “Ok kids, new game, pick those sticks up as quietly and tediously as possible.”

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

#60

Post by nijave »

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

While very powerful, I think it's worth calling out some pitfuls. A few things we've ran into - long lived feature flags that are never cleaned up (which usually cause zombie or partially dead code) - rollout drift where different environments or customers have different flags set and it's difficult to know who actually has the feature - not flagging all connected functionality (i.e. one API is missing the flag that should have had it)

A good decom/cleanup strategy definitely helps

Post reply on HN