Using the 5S Principle in Coding

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.

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.

Toyota practice had such impact because it empowered people to speak up.

It's not clear this article is empowering in that sense.

Instead of tracking/pleasing your boss, quality principles were stated and your job was to implement those principles, halting work as needed. This leads to problems being dealt with in time and in context, instead of being ignored or concealed. (Remind you of PG's distinction between being persistent vs. obstinate?) The difference lay not really in the major premise (the principles) but in how and when the minor premise of fault-correction was applied.

To me in software that's all about scheduling: scheduling infrastructure work and cross-training early, doing post-mortem's immediately, building design consensus iteratively with discussion and prototyping, etc. Scheduling and objectivity: not who's saying it, but what's being said. Both should empower IC's by giving them actual time and actual say.

In particular, clean code is often not the best, but can empower those otherwise bereft of natural authority. Sometimes duplication is better than dependencies, a little pile is better than a lot of structure, a complex PR is easier to review all at once, etc.

Empowering people makes selecting and orienting them quite important - but that's a separate issue.

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

I worked for a manufacturing company that rolled out 5S. It seemed to make a lot of sense on the shop floor, but the executives had us doing the same thing the same way in engineering.

All the math, software, and mechanical folks had to "5S their work area". Our manager gave us rolls of tape and a label printer so we could mark off where everything on our desk was supposed to be put away. The instructions we were handed showed marking off staplers and tape dispensers for desk jobs. It really was absurd!

They furloughed everyone in the company a few weeks later and I decided it really wasn't the place for me.

This _feels_ good to a single dev working on a project, where the rules are intuitive, no explanation is needed, and deadlines are fluid.

But I have to imagine this creates a lot of friction within a team, all trying to adhere to rules under the guise of efficiency, at great opportunity cost. And what's the ultimate impact to the customer? Do they care how elegant the codebase is?

It's worth noting what The Toyota Way is. It's a way to ensure high production quality. It is also slow. This is why Toyota effectively abandoned The Toyota Way in the mid 2000s, and why they were raked through the coals over recall issues in 2013. Growth.

If deadlines are involved, I struggle to see the argument for making view files beautifully atomic vs. say, making an improvement that adds customers / reduces churn.

I think this has one of the cases where trying to minimalistic in examples actually defeats the purpose, e.g., in the "Sort/Seiri" React examples, the state variable in the component and all the imports that are retained are actually unused (a state variable in a component with no mutation code is just a constant with extra work, useState is only used for that variable, and the React import -- assuming this is the current major version of React for the last two years -- also isn't used [in older versions, it was needed for JSX to be used as a side effect even if the import wasn't otherwise used, and its a reflex legacy pattern that a lot of people probably haven't broken even with current react].)

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.

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

The documentation example is a clear example of absurdity. This is just a multiplication that might as well be inlined in all places where it is needed and then the 'standard' is applied and it turns into a 21 line hellscape that points out the obvious.

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

Consistant error handling should be number 1. Followed by tests.

Optimization is in >80% of all Software unnecessary, it is a nice to have feature.

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.

There is something about branded practice names that just instantly invokes a gag reflex. Too many times, the branding is for a reason: some programmer wants to elevate themselves into thought leadership, sell books (mostly filler of course), speaking engagements m, etc., while never really adding anything to the industry.

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.

"We heard there wasn't enough buzzwords in the software dev world, so we decided to import some buzzwords from other industries..."

Anyone runs a zero inbox policy of email organization?

`/organisms/`

What?