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

31–40 of 88 posts

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

#31

Post by UltraSane »

layer8 wrote: post #20
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.

The problem with complex legacy codebases is that you don’t know about the myriads of edge cases the existing code is covering, and that will only be discovered in production on customer premises wreaking havoc two months after you shipped the seemingly regression-free refactor.

If you save a log of input on the production system you can feed it to old and new versions to find any changed in behavior.

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

#32

Post by brutuscat »

For me now days is like this: - try to locate the relevant files - now build a prompt, explain the use case or the refactor purpose. Explain the relevant files and mention them and describe the interaction and how you understand that work together. Also explain how you think it needs to be refactored. Give the model the instruction to analyze the code and propose different solution for a complete refactor. Tell it to not implement it, just plan.

Then you’ll get several paths of action.

Chose one and tell the model to write into a file you’ll keep around while the implantation is on going so you won’t pollute the context and can start over each chunk of work in a clean prompt. Name the file refactor--plan.md tell it to write the plan step by step and dump a todo list having into account dependencies for tracking progress.

Review the plans, make fixes if needed. You need to have some sort of table reassembling a todo so it can track and make progress along.

Open a new prompt tell it analyze the plan file, to go to the todo list section and proceed with the next task. Verify it done, and update the plan.

Repeat until done.

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

#34

Post by kaffekaka »

bee_rider wrote: post #18
hidelooktropic wrote: post #9

So you do things one step at a time and timebox as you go? This method probably doesn't need its own name. In fact I think that's just what timeboxing is.

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.

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

#35

Post by jeremyscanvic »

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 other than 42.

At this point you decide to hard code the behavior you want for the value 42 specifically. It's nasty and it only makes the code base more complex, but at least you're not breaking anything.

Anyone has experience of this mindset of embracing the mess?

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

#36

Post by 0xbadcafebee »

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 believe this is called Microsoft Driven Development

(seriously though, this book has answers for you: Working Effectively with Legacy Code, by Michael Feathers)

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

#37

Post by bob1029 »

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. I've never been in a real business scenario where I wasn't able to negotiate a brief experimental window during live business hours for at least one client.

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

#38

Post by zem »

bregma wrote: post #30
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…

Mikado is the name of an opera (by Gilbert and Sullivan) in which someone is deemed to have been executed without actually having been executed. Sounds like an ideal test strategy to me: yes, all the tests were executed, just not actually run.

when I saw the title I was expecting a reference to the opera. was wondering if they were somehow going to work in the exchange "Besides, I don't see how a man can cut off his own head." "A man might try." in reference to gradually removing bits of the old code.

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

#39

Post by ljm »

layer8 wrote: post #20
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.

The problem with complex legacy codebases is that you don’t know about the myriads of edge cases the existing code is covering, and that will only be discovered in production on customer premises wreaking havoc two months after you shipped the seemingly regression-free refactor.

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.

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

#40

Post by fc417fc802 »

0xbadcafebee wrote: post #36
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 believe this is called Microsoft Driven Development (seriously though, this book has answers for you: Working Effectively with Legacy Code, by Michael Feathers )

You misspelled Oracle.
Post reply on HN