Wastes of Software Development

 

​This was originally written in June, 2012. Re-posting since recent conversations on LinkedIn made it relevant to share. 

There has been a tendency to translate the seven wastes of manufacturing into wastes of software development. Not a bad start, but just that - a start.  There are several things about software development that is not at all like product development in the physical world.  These include:

• waste cannot be seen directly
• the appearance of a developer is the same whether they are writing bug free code and buggy code
• errors in software tend to take more energy to fix as the time between making them and finding them increases (this is true even prior to deployment)
• errors in manufacturing tend to repeat themselves, errors in software are unique, although they repeat a pattern

The point is, we need a new list of wastes for software development.  Here is a first cut:

• The Cause of Waste
  • Too much work in process
  • Delays
  • Handoffs
  • Bureaucracy
  • Interruptions
  • Unclear workflow
• Waste Produced (note how this adds to the cause – endless cycle)
  • Extra features
  • Defects
  • Complexity
• Waste in Work (note how this adds to the cause – endless cycle)
  • Lowered efficiency due to interruptions and improper methods
  • Fixing bugs
  • Redoing requirements
  • Thrashing due to out of synch integration
  • Re-learning
  • Poor technical practices
  • Improper order of work
  • Duplicating code
  • Overbuilding frameworks

 Much of the source of the problem is doing too much work. This can be too many things in play or the things in play are bigger than they need to be.  There are two general ways of managing the work of a team:

1. Plan it out ahead and give it to them
2. Let them pull the work when they are ready

 Waterfall and pre-agile planning uses the first.  All Agile methods use the second. The challenge is how does one get executives to understand that there is an inherent capacity of the teams and that this must be respected?  From their perspective we need to provide the following information:

1. Evidence that the teams are working well
2. Evidence that they are working at capacity

We’re trying to learn a better way.   Undergoing a change can be hard on us, as well as the people we are providing services too. In situations like this, exposure into one's methods is always a good idea.  Both for the teams to learn how to better work and for others to understand why the changes represent a true opportunity for improvement.

For a more recent, related post on this see The Software World Is Not Like the Physical World and What That Means