Using the 5S Principle in Coding • Hacker News Board

Re: Using the 5S Principle in Coding

#21

Post by wadadadad » Wed, Jul 10, 2024, 6:45 PM UTC

BurningFrog wrote: post #20

buttercraft wrote: post #15

Earlier quoted context omitted.

The problem is when you guess ahead of time what directory structure you need and get it slightly but not obviously wrong. Start flat, and when that becomes a problem, you'll know why it's a problem and how to restructure it.

In general, problems are much easier to solve when you have them, than when you try to guess what they will be.

I've been considering the topic of solving problems too early for quite some time now, and you very effectively communicated this point; thank you for that clear insight.

Relatedly and at the same time, I sometimes have a hard time figuring out when the right time to 'solve' the problem is. Speaking generally, if left unchecked for too long, it seems like more effort to go through and find instances of the problem and create a valid solution and then apply the solution, then if I am able to spot the reoccurring problem after only a few instances. This is particularly worse when I go back and solve the problem in a few areas, but there are more areas that I've missed (and now I have some spots with the solution, some without, and everything is messy). I suppose I need to spend more time after creating a solution to see if it's applicable apply anywhere else (but then that's more time refactoring than actually working on the problem at hand).

Re: Using the 5S Principle in Coding

#22

Post by agumonkey » Wed, Jul 10, 2024, 7:15 PM UTC

This is for small projects or intermediate level, what people do for larger systems ? how do you organize shared api constraints / models / tests, branching model, versioning scheme, data migrations in case of a large refactor, infrastructure change. Every aspects can lead to fragmentation, friction / grind and bitrot.

Re: Using the 5S Principle in Coding

#23

Post by bhk » Wed, Jul 10, 2024, 7:28 PM UTC

Ugh. Instead of 10 files in one directory, scatter them across 13 subdirectories. An anti-pattern in my book.

Re: Using the 5S Principle in Coding

#24

Post by datameta » Wed, Jul 10, 2024, 7:40 PM UTC

BurningFrog wrote: post #20

buttercraft wrote: post #15

Earlier quoted context omitted.

The problem is when you guess ahead of time what directory structure you need and get it slightly but not obviously wrong. Start flat, and when that becomes a problem, you'll know why it's a problem and how to restructure it.

In general, problems are much easier to solve when you have them, than when you try to guess what they will be.

Very aptly put.

Re: Using the 5S Principle in Coding

#25

Post by datameta » Wed, Jul 10, 2024, 7:43 PM UTC

wadadadad wrote: post #21

BurningFrog wrote: post #20

Earlier quoted context omitted.

In general, problems are much easier to solve when you have them, than when you try to guess what they will be.

I've been considering the topic of solving problems too early for quite some time now, and you very effectively communicated this point; thank you for that clear insight. Relatedly and at the same time, I sometimes have a hard time figuring out when the right time to 'solve' the problem is. Speaking generally, if left unchecked for too long, it seems like more effort to go through and find instances of the problem an…

Is one effective method perhaps to carve out a consistent, say, 5% of the day to focus on this cross-polination of implemented solutions?

Re: Using the 5S Principle in Coding

#26

Post by wadadadad » Wed, Jul 10, 2024, 8:50 PM UTC

datameta wrote: post #25

wadadadad wrote: post #21

Earlier quoted context omitted.

I've been considering the topic of solving problems too early for quite some time now, and you very effectively communicated this point; thank you for that clear insight. Relatedly and at the same time, I sometimes have a hard time figuring out when the right time to 'solve' the problem is. Speaking generally, if left unchecked for too long, it seems like more effort to go through and find instances of the problem an…

Is one effective method perhaps to carve out a consistent, say, 5% of the day to focus on this cross-polination of implemented solutions?

This could work (perhaps on a more weekly level for me). I would have to note the solutions and problems as I come across them and put them into a backlog, otherwise I'll definitely forget about them (until I run into them again, haha).

This does go back to topic focus though. Regarding programming specifically, I generally will have a topic (such as a feature enhancement). If I implement a new solution to a problem, it's not clear-cut to me if I should go and implement that solution everywhere relevant during the current topic, or if I should wait until a more tech-debt rework to clean things up a bit. My inclination is to focus on rework only during those tech-debt reducing stints. I really should figure out a clear and well-defined process for this.

Re: Using the 5S Principle in Coding

#27

Post by jiggawatts » Wed, Jul 10, 2024, 9:38 PM UTC

codelikeawolf wrote: post #8

When I used to work in manufacturing, my company was super into Lean. I even ended up getting an ASQ Six Sigma Green Belt certification. My favorite thing to say to people when they asked what 5S stood for was "Shove Stupid Shit Someplace Secret". In my experience, that wasn't an entirely inaccurate interpretation. Joking aside, I think this article does a decent job of translating Lean manufacturing principles to co…

The folder thing is something I’ve noticed too. The problem with folders is that in most interfaces you can’t see their content until they’re opened. In some really bad interfaces you can only see one open folder at a time.

Flat lists let you see the entire thing at once. As long as there is some sort of natural sort order, it’s still a “neat” way to organise things.

E.g.:

    SomeApp-PRD-Web
    SomeApp-PRD-DB
    OtherApp-PRD-Web
    OtherApp-PRD-DB
    OtherApp-PRD-API

Is roughly how I organise cloud resources. You can instantly see that there are two apps, and that both are web+db but the second one also has an API.

If you had folders you’d just see this:

    SomeApp
    OtherApp

That just tells you that there are two apps, and nothing else. You have to navigate several times to get to the detail you could see at a glance with the flat structure.

Similar concepts apply to code at every level. I avoid overly abstract functions that do their job through seven levels of trivial abstractions for the same reason. A one-page “flat” function can be more readable and maintainable.

Re: Using the 5S Principle in Coding

#28

Post by Ma8ee » Wed, Jul 10, 2024, 9:53 PM UTC

smithbits wrote: post #9

It's worth keeping in mind that lean manufacturing and all the interesting things that Toyota did that get written up are about building cars. In software the equivalent process is compiling and deploying code. Writing software is equivalent to designing, prototyping and testing a car. So while there are many interesting lessons to learn they are about the deployment and running of code, not about writing it. In the…

Yes! I still meet too many people who think what we are manufacturing software, while what we are doing is designing it. The manufacturing, that is, the building and deployment is already highly automated and very cheap.

Re: Using the 5S Principle in Coding

#29

Post by BurningFrog » Wed, Jul 10, 2024, 10:01 PM UTC

wadadadad wrote: post #21

BurningFrog wrote: post #20

Earlier quoted context omitted.

In general, problems are much easier to solve when you have them, than when you try to guess what they will be.

I've been considering the topic of solving problems too early for quite some time now, and you very effectively communicated this point; thank you for that clear insight. Relatedly and at the same time, I sometimes have a hard time figuring out when the right time to 'solve' the problem is. Speaking generally, if left unchecked for too long, it seems like more effort to go through and find instances of the problem an…

Those are genuinely hard problems you describe, so don't feel bad about struggling with them.

Personally I am very focused on refactoring. When in doubt, if I can improve the code, I will! I don't know that that's "right", but it's how I live.

Re: Using the 5S Principle in Coding

#30

Post by kazinator » Wed, Jul 10, 2024, 10:22 PM UTC

Seiketsu (清潔) doesn't mean standardize; it means "clean, hygienic, sanitary". You hear it in the negative: fuseiketsu means filthy.

The first four S's are all in the same semantic neighborhood: they all have to do with neatness, cleanliness and order. Basically they collapse into one. The last S, shitsuke, is just discipline.

"Be clean/neat/tidy, and have discipline".

Yay ...