Live data from Hacker News

Using the 5S Principle in Coding

santhoshsundar.medium.com

1–10 of 55 posts

Re: Using the 5S Principle in Coding

#4
Great article! As someone who has inherited poorly documented and maintained codebases (and that has worked in the chemical engineering world), this article hits home on so many points. This should be normalized as best practice or at the very least regular time allotments should be given to make codebases less inscrutable.

Re: Using the 5S Principle in Coding

#5

5S is more about organizing your workspace, but this article is about organizing your work product. And it doesn’t say anything that isn’t standard dev practice, it just organizes the items under a strained 5S umbrella. Imho

Toyota envy. Not the first or the last time someone will abuse 5S to fit some grand shower thought.

Re: Using the 5S Principle in Coding

#6
This is the sort of thing that makes me love (or hate) a codebase. I just have to point out that this sort of thing is extremely easy to do with typed languages, and can be (but not inherently) a total nightmare with untyped languages. Types matter, not just for correctness, but also cleanliness, order, and ease of maintenance.

Re: Using the 5S Principle in Coding

#7
post #4

Great article! As someone who has inherited poorly documented and maintained codebases (and that has worked in the chemical engineering world), this article hits home on so many points. This should be normalized as best practice or at the very least regular time allotments should be given to make codebases less inscrutable.

> This should be normalized as best practice

I didn't see anything listed that isn't already considered a best practice (at least the headings, the specifics could be debated). Now, whether it's a normal practice or not is another matter, but when you have a huge number of novices joining every year and companies happily laying off senior people who could mentor them you get exactly what we have today.

Re: Using the 5S Principle in Coding

#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 coding, but the "Set in Order" section grinds my gears a little bit. I have worked on many projects of various sizes, and I think my fellow web devs tend to lean too hard into an overly nested directory structure. In manufacturing terms, imagine if you needed to open a cabinet that contains a toolbox with a plastic organizer in one of the drawers that contains a box that you had to open to get access to some rivets. It doesn't take much for that level of organization to kneecap efficiency. I would much rather have a single directory with 20 files than try to chase down a component file that's eight directories deep. Give me a big list of long descriptive file names, not short names that rely on the directory name to give context.

Re: Using the 5S Principle in Coding

#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 mass manufactured automobile industry you spend more time and effort building the product than designing it. In software you spend much more time designing (specs, coding, testing, all that stuff) the product than deploying it. The lessons of lean manufacturing may not apply to design.

Re: Using the 5S Principle in Coding

#10

5S is more about organizing your workspace, but this article is about organizing your work product. And it doesn’t say anything that isn’t standard dev practice, it just organizes the items under a strained 5S umbrella. Imho

Different people need a different analogy to absorb the same information.

Because of this, the more people writing these practices down from a different viewpoint, the more likely another person is influenced and improves their craft.

Post reply on HN