How 5S Applies to Software Development

Before getting into software engineering, I spent 11 years between the Air Force and the equipment rental industry. During that time, I underwent 5 “5S” or “Lean” transformation efforts. So that you can understand what I am referring to, 5S is a methodology designed for industrial environments, with the idea being to improve efficiency through organization and standardization. Some basic things that come from it are to ruthlessly get rid of things that you don’t need, move needed supplies to the point where they are needed, give everything a specific spot (and make sure it stays there, usually by painting lines around the spot or marking it in some other way so it is very noticeable when it is not there), clean obsessively, and standardize processes.

For an easy example, in the Air Force we had a large team doing equipment inspections. Every inspection included an oil change. For the oil change, you needed a filter wrench. The filter wrench was kept in the tool storage room at the back of the shop. An improvement that came from our implementation was buying a filter wrench for each workstation and permanently locating it there. Another is all of the floor jacks had a box painted on the floor, so that we could be sure that everyone knew where they were (instead of having to go looking for them).

By Tasma3197 — Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=19068362

This brings us to the main reason that this can be effective when followed. When you finish with the wrench, it takes more time to put it back in exactly the right spot than it would to just throw it in the drawer. Leaving the floor jack laying where you just used it in case you need it later is the easy way. Spending time every day cleaning and sweeping and setting things right seems like time not spent on effective work. But the truth is that this whole thing is designed to help you go faster! Yes, it takes an extra second to put the wrench back properly… but it takes five seconds to dig through an unorganized drawer looking for the right socket. Yes, putting the jack back prematurely could cost you a minute. But someone else spending five minuets looking for it wipes out that gain.

Software Engineering

The reason I bring this all up is that the exact same process can be used to improve software development workflow. Yes, our work is mostly creative and it seems like an industrial standardization process would be counterproductive. However, there are a lot of mechanical elements to the work we do, and those elements can be profitably smoothed out- and the time spent on that will not only make you feel better about things being neat and tidy, but actually improve your efficiency. Lets look at some ideas…

Sort

The first S is usually Sort. This means going through the whole workspace and segregating the things that you need from the ones that you don’t… and then getting rid of the things that you don’t. Cabinets full of extra spare parts, tools that you may need someday but never have, that kind of stuff was always the biggest pain point (people never want to give up their stashes!). In code, this is easily seen as code that is commented out, methods that aren’t used anymore, and documentation or scripts that just don’t apply to the latest version of the code.

Periodically taking some time and ruthlessly stripping this stuff out is a huge benefit to future work. I can think of multiple occasions where I was trying to understand how something works, just to be told when I finally gave up and went looking for an answer — “oh, we don’t use that anymore”. Programming is hard enough without having to load unused information into your mind. So set a policy of no commented out code, strip out methods that aren’t used anymore, and clean up your old documentation. Delete those Jenkins jobs that don’t work that you gave up on six months ago. Close those old pull requests and speculative branches. The best part about code is that with git you can usually get something back if it turns out you need it, it’s even easier than if you had thrown away those spare parts!

Set In Order

The second S stands for Set in Order (or something else. The S’s are actually Japanese words, they tried to translate them to S words in English to keep the whole “5S” theme going, I have seen multiple attempts though). This is where you look at the things you have left (that you didn’t throw away in the last phase) and figure out where they go, and put them there. In the industrial shop, you figure out where that wrench goes, and you put it in that spot (preferable with a shadow painted around it so you notice if it disappears).

In software, this is really a “refactoring” step. A big problem with some code bases is it is hard to figure out where something may be. If I am building a new feature that needs to frobit the woobaz, having a pretty good idea where the frobit(woobaz) method should live is essential. This prevents me from implementing my own version when there is already an existing one, and makes it easy to figure out how things work when I am trying to trace out the source code. This is worth at least a minor productivity boost, at the mere cost of occasional refactoring when you realize it would have made more sense for the bar function to live in the foo module.

Shine

The next step is “shine”, which in an industrial context refers to going through and cleaning the crap out of everything. You threw away the stuff you don’t need, and put the stuff you do need where it should go… now scrub the whole shebang. All the dirt should be removed, and the whole environment should look brand new to the point where people are proud to work in it (and hesitant to mess it up! the broken window theory is real…).

In software, this means to clean up your code. Run your linter, and clean up ALL of the formatting issues. Tabs vs spaces? Newlines at the end of files? Two blank lines between classes? All of this stuff should be completely fixed. This, of course, requires your team to agree on coding formatting standards. With Python (my favorite language, this blog is written poorly in it) you can use something like PEP-8. The key is to get it all done. A build with NO violations going to one is gonna bother people much more than one going from 500 to 501. When this is done you eliminate questions about code standards, and you get the whole code base looking one way instead of “should I copy this module or this other module that were written with obviously different styles?”.

Standardize

This is probably the most important step. In a shop, this is where you set the policy and make sure it is followed. In step two you decided where the wrench goes… in step four you paint the shadow of the wrench to make sure everyone knows where it goes… and do the same thing for everyone else’s workstation. Standardization is the key to productivity. If you go to another workstation, knowing where everything is, and where it should go when you’re done, is the absolute most important time saver possible.

In software, NIH is a killer- everyone re-implements things like convert_to_local_timezone using different libraries and signatures. Instead, make sure that you have one obvious (and preferably only one... zen of Python again) way of doing common tasks. If your code base always farms datetime conversions out to the utils package... make sure that ALL of the conversions are ruthlessly converted to the standard way! Don't Repeat Yourself!

Sustain

The last step is “Sustain” which means “keep things going.” This is to make sure that all the cleaning and organizing you did doesn’t go to waste. Simple processes are usually the answer here… at the end of every shift, someone has to sign off that all the tools have been returned to their proper location. The whole team has to do a walkaround for things out of place once a day. Do a FOD walk every morning.

In software, this is the environment of your CI system. Your tests get run on every pull request, and only passing code gets merged. You run your linter on every commit and don’t merge changes with any violations. Every code review checks carefully for duplication and standards violations.

Conclusion

Doing these things for the first time may feel like they are a waste of time- after all, who really cares how many newlines you have in between two classes? But in reality, these are a hallmark of effective software teams. Not because of any appeal to code “beauty” or anything of the like… but because clean code bases are easier to make changes to. When you can change a variable name, run the tests, and be confident that if they pass your code will work in production, it is faster and safer to actually make that change!