Five Ideals of Software Development

Credits: Most of the text below are “Verbatim” notes from the book The Unicorn Project, by Gene Kim.

There are times, when you read a book - it strikes you really hard/well and you would like to share it with as many people you would like. Since this blog of mine is public - I decided to put it here so that it would help someone/someday.

Here are Five Ideals:

1. Locality and Simplicity:

Design things so that we have locality in our systems and the organizations that build them. And we need simplicity in everything we do. The last place we want complexity is internally, whether its in our code, in our organization or in our process. Rate at which a software team can add new features can improve only when - we pay down technical debt as a part of daily work and a good automated test suite to catch the failures.

Remember: the “S” in the SOLID Principles - Single Responsiblitity.

2. Focus, Flow and Joy:

Its all about how our daily work feels. Is our work marked by boredom and waiting for other people to get things done on our behalf? Do we blindly work on small pieces of the whole, only seeing the outcomes of our work during a deployment when everything blows up, leading to firefighthing, punishment and burn out? Or do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work? These are the conditions that allow for focus and flow, challenge, learning, discovery, mastering our doman, and even joy.

Remember: Test Driven Development(TDD) and Continous Integration (CI)

The process of stopping a system when a defect was suspected originates back to the original Toyota System Corporation to something called Jidoka. The idea behind Jidoka is that by stopping the system you get an immediate opportunity for improvement, or find a root cause, as opposed to letting the defect move further down the line and be unresolved.

3. Improvement of Daily Work:

Reflect upon what the Toyota Andon cord teaches us about how we must elevate improvment of daily work over daily work itself.

Remember: Refactoring, by Martin Fowler

4. Psychological Safety:

Where we make it safe to talk about problems, because solving problems requires prevention, which requires honesty, and honesty requires the absence of fear. In manufacturing, psychological safety is just as important as physical safety. A culture of fear where everyone is afraid to share the bad news - will only have a negative impact.

One of the Value of KLA (my current employer) is “HFC: Honesty, Forthright and Consistency” - which I greatly admire.

5. Customer Focus:

Question ruthlessly whether something actually matters to our customers, as in, are they willing to pay us for it or is it only of value to our functional silo.

Remember the 80:20 Rule.

According to Standish’s research and more recent estimates, 20 percent of software features are often used, while 50 percent of features are hardly ever or never used. The remaining 30 percent of features are used infrequently. (For package applications, like Microsoft Office, Standish found that just five percent of features are used.) Ref