6 ms·
Using the 5S Principle in Coding
- barbariangrunge 2y ago5S 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
- leansensei 2y agoToyota envy. Not the first or the last time someone will abuse 5S to fit some grand shower thought.
- scott_w 2y agoDifferent 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.
- deeviant 2y ago"We heard there wasn't enough buzzwords in the software dev world, so we decided to import some buzzwords from other industries..."
- rolandog 2y agoGreat 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.
- Jtsummers 2y ago> 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.
- oldpersonintx 2y ago[dead]
- darksaints 2y agoThis 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.
- codelikeawolf 2y agoWhen 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.
- datameta 2y agoPersonally 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.
- codelikeawolf 2y agoDifferent 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.
- buttercraft 2y agoThe 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.
- smithbits 2y agoIt'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.
- Ma8ee 2y agoYes! 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.
- jiggawatts 2y agoA 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?”
- quartesixte 2y agoThis 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?
- dragonwriter 2y agoI 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].)
- cjfd 2y agoThe 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.
- agumonkey 2y agoThis 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.
- bhk 2y agoUgh. Instead of 10 files in one directory, scatter them across 13 subdirectories. An anti-pattern in my book.
- keyle 2y agoIt 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:
- kazinator 2y agoSeiketsu (清潔) 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 ...
- hahamrfunnyguy 2y agoI 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.
- w10-1 2y agoToyota 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.
- osigurdson 2y agoThere 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.
- mvkel 2y agoThis _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.
- richrichie 2y agoAnyone runs a zero inbox policy of email organization?
- 01HNNWZ0MV43FF 2y ago`/organisms/` What?
- ajaymenon0 2y agohttps://atomicdesign.bradfrost.com/images/content/atomic-design-process.png https://atomicdesign.bradfrost.com/images/content/atomic-des...
- 01HNNWZ0MV43FF 2y agoHm. Hard to add middle layers to that unless you have e.g. tissues, organs. I propose going back to line numbers. Start with 1000, 2000, 3000. Sub-divide as needed.
- cglace 2y agoYeah, I've encountered people who insisted on using this structure. I was not too fond of it.
- ajaymenon0 2y agoHonestly it's just a nomenclature or convention to define hierarchies. I've had certain projects where it was useful to get teams aligned on how to view a particular project. That being said, sometimes it's also heralded as something super life changing, which it isn't.
- progx 2y agoConsistant error handling should be number 1. Followed by tests. Optimization is in >80% of all Software unnecessary, it is a nice to have feature.