Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using the 5S Principle in Coding

santhoshsundar.medium.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Using the 5S Principle in Coding

#31

Post by jiggawatts »

Ma8ee wrote: post #28
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.

A significant percentage of the time you’re researching software — determining if something is even possible.

This is the even more crucial difference and the reason for all the time estimation arguments.

If a manager can’t estimate a car production run schedule they’re a bad manager.

No manager can schedule — to the day — when fusion powered cars will be ready for shipping.

Yet, this is expected from people trying something entirely new in software.

“Integrate these two things that no human has put together before. Now that you’ve heard this single sentence, tell me: will it be ready Tuesday or Wednesday… a year from now?”

Re: Using the 5S Principle in Coding

#32

Post by hahamrfunnyguy »

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.

Re: Using the 5S Principle in Coding

#33

Post by w10-1 »

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.

Re: Using the 5S Principle in Coding

#34

Post by candiddevmike »

datameta wrote: post #11
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…

Personally I found when onboarding to a repo, whether memory firmware or hardware bringup toolkit, that flatter directories lead to a much slower grasp of the architecture. I prefer leaning toward descriptive directories.

Do you like programming in Java?

Re: Using the 5S Principle in Coding

#35

Post by quartesixte »

Ma8ee wrote: post #28
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.

This is why Agile/Standups make people go crazy! The daily standup makes sense when all the topics discussed will close out within hours, blockers sometimes stand literally upstream on the assembly line, and no one can really talk to each other outside of the standup because they’re too busy running manufacturing work centers that need 100% of their constant attention.

Imagine if compiling/deploying involved teams on the daily hand writing assembly/machine code from code base?

Re: Using the 5S Principle in Coding

#36

Post by wheelinsupial »

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…

Lean manufacturing and the Toyota Production System are absolutely about manufacturing. It's rooted in industrial engineering and operations research. It is about addressing root causes and truly solving issues. What we see in the lean books is a bunch of solutions to problems Toyota was facing at the time and how they solved them.

Even the person who coined "lean manufacturing" says, "Don't try to bring lean manufacturing upstream to product development. The application of Lean in product development and manufacturing are different. Some aspects may look similar, but they are not! Be weary of an expert with experience in lean manufacturing that claims to know product development."[1]

There are a couple of books that have tried to capture the design process from Toyota. [1] is the Wikipedia page for [2]. [3] is an alternative take. Unfortunately I haven't read these books, so can't provide anything beyond the table of contents.

[1] https://en.wikipedia.org/wiki/Lean_product_development

[2] the table of contents needs to be downloaded from https://www.lean.org/store/book/lean-product-and-process-dev...

[2] https://www.routledge.com/The-Toyota-Product-Development-Sys...

Re: Using the 5S Principle in Coding

#37

Post by keyle »

bhk wrote: post #23

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

It seems like a common junior developer mistake. Hide the poopoo in 12 layers of indirection.

That and doing I/O and async stuff in getters :vomit-face:

Re: Using the 5S Principle in Coding

#38

Post by osigurdson »

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.

Re: Using the 5S Principle in Coding

#39

Post by casper14 »

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.

Brilliant

Re: Using the 5S Principle in Coding

#40

Post by analog31 »

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…

In my experience, whenever a site installs lean processes, somebody gets the bright idea that if it works in manufacturing, then surely it can work in R&D. Every senior (hardware) engineer has a story of this happening at a past workplace.

The compromise is to tidy the workplace as well as possible, call it "5S", fill the dumpster with stuff that's really junk, and let each engineer stash their Undecidable Things under their desk.

As for software, maybe the best thing is to just not let hardware concepts such as "designing" and "manufacturing" creep in. Especially when those things imply a social hierarchy.

Post reply on HN