(Seiton, 整頓, according to Wikipedia)
I am still not convinced that it was a good idea to only use English words that start with an ‘s’ for all the pillars of the 5S-System in the Wikipedia (and some other) explanation of the concept.
According to Hirano, who wrote one of the defining books on 5S, the second pillar is called ‘orderliness’ which – in my opinion – is much easier to interpret for software development purposes.
Ideas from production (as quoted from Wikipedia)
- Arrange all necessary items in order so they can be easily picked for use
- Prevent loss and waste of time
- Make it easy to find and pick up necessary items
- Ensure first-come-first-serve basis
- Make (the) workflow smooth and easy
- Can also be translated as “set in order”
The difference between ‘sort’ and ‘straighten’ is very subtle - especially when we think about software-development or other knowledge work, but if we consider the alternative translations ‘organization’ and ‘orderliness’, the difference becomes much clearer in my opinion.
How to apply these ideas to software development
While ‘organization’ calls for the removal of unnecessary clutter (be it in your File-System, on your physical desktop, on your computer’s desktop or anywhere else) ‘orderliness’ goes a step further and requires us to set the things that are not unnecessary – one might say those items that are necessary – in a definitive, understandable, reproducible order.
Let‘s look at other options to bring more orderliness into software-development
One of the things I tend to see here is the “automate ruthlessly“ or “ubiquitous automation” concept. Or, as they put it in the old days:
- The first time you do something, you just do it manually.
- The second time you do something similar, you wince at the repetition, but you do it anyway.
- The third time you do something similar, you automate.
But just using the tools of the trade in a more orderly fashion can make a huge difference. Using tags to categorize files (if your file-system supports such a thing), using a defined pattern for file names (not only for source code) and generally not only weeding out stuff but also ordering your tools and material falls into this category.
As James O. Coplien quotes in the foreword to the clean code book there is the old American (?) saying of “A place for everything and everything in its place” which really captures the whole concept very well for me.
What I propose in addition to Cope‘s explanation of this concept (a piece of code should be where you expect to find it) is to apply this idea to everything related to the value chain – from the first idea to the end-user actually interacting with the capability of the system that represents this idea.
- Where do the requirements belong?
- Where do the acceptance criteria live?
- Where would I find the swahili language translation of the help-files
- Where is machine specific configuration information placed? And how about user specific configuration?
- and so on...
Now what would you propose to do in our day-to-day work to get our software-development more ‘orderly’?
Till next time
Michael Mahlberg
No comments:
Post a Comment