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

11–20 of 55 posts

Re: Using the 5S Principle in Coding

#11

Post by datameta »

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.

Re: Using the 5S Principle in Coding

#12

Post by dragonwriter »

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

Re: Using the 5S Principle in Coding

#13

Post by codelikeawolf »

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.

Different strokes for different folks. I think it's important to find a good balance. I've seen Go and C projects that don't use enough directories, so navigating the code can be a little untenable. In the example given in the article, I would scrap all the subdirectories in `/features/UserManagement`. I think the file names are sufficient to indicate what purpose they serve and putting them in subdirectories by type doesn't really offer any value.

Re: Using the 5S Principle in Coding

#14

Post by pphysch »

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…

> "Shove Stupid Shit Someplace Secret"

This sums up the broad concept of Compliance and security in general. The people who pretend to care about compliance (i.e. management) don't have the technical know-how to grok the implementations by those who pretend to implement said compliant systems. There isn't remotely enough QA/red-teaming (expensive to do in a bias-free manner), most of the time all you need to do is scribble in the box and everyone is going to squint and pretend it's checked.

Re: Using the 5S Principle in Coding

#15

Post by buttercraft »

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.

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.

Re: Using the 5S Principle in Coding

#16

Post by osigurdson »

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 problem with relying on a tree is most brains don't organize information like that. This is why code search is much more valuable. Naturally, having one canonical tree representation is obviously a good idea but the value is really in introducing a constraint that acts as a forcing function (if done right) to simplify the code base (it can also be theater - spaghetti code masquerading as as well structured code base).

Re: Using the 5S Principle in Coding

#17

Post by oldpersonintx »

rolandog wrote: 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.

[dead]

Re: Using the 5S Principle in Coding

#18

Post by cjfd »

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.

Re: Using the 5S Principle in Coding

#19

Post by mnahkies »

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.

I like the angular style guides take on this:

> Flat

> Style 04-04

> Do keep a flat folder structure as long as possible. >

> Consider creating sub-folders when a folder reaches seven or more files.

It goes more into the why on the actual guide https://angular.io/guide/styleguide

Re: Using the 5S Principle in Coding

#20

Post by BurningFrog »

buttercraft wrote: post #15
datameta wrote: post #11

Earlier quoted context omitted.

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.

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.
Post reply on HN