David S. Read

As I read more and more about the Toyota debacle I’m struck by an apparently myopic management drive to cut costs.  In the case of Toyota it appears that cost cutting extended into quality cutting.  A company once known for superb quality had methodically reduced that aspect of their output.  This isn’t just conjecture; it seems that people inside the company had been aware of a decline in quality due to a focus on reducing costs.¹ Is there a general lesson to consider?

I believe the failure is one of misplaced focus. The focus when Toyota began cutting costs was to remove waste.  That waste could be found throughout their manufacturing processes.  Wasted materials, productivity, tooling, and equipment were all identified as Toyota’s management and workers struck out on a journey to reduce waste and improve productivity.  They ushered in a set of practices that others would soon adopt.

Head back to the 1950′s and you’ll find Taiichi Ohno² hard at work addressing myriad manufacturing shortcomings at Toyota.  Mr. Ohno is really the father of lean manufacturing and just-in-time inventory management.  He didn’t name them as such.  He was just trying to remove waste from the entire manufacturing process.  By the late 1990′s these concepts had become standard operating procedure at many firms.

It makes sense that a business would focus on reducing waste.  Although it may require effort to remove waste without reducing productivity, overall one would expect a leaner process to have an overall efficiency gain.  It would also seem that quality does not benefit from waste.  After many years of experience with these principles, companies have found that an approach of using only the resources that are needed when they are needed provides a sound basis for their operations.  So what happened at Toyota?  They apparently went beyond cutting waste.

(more…)

I recently overheard a development leader talking with a team of programmers about the trade-off between the speed of developing working code and the effort required to improve the run-time performance of the code.  His opinion was that it was not worth any extra effort to gain a few hundred milliseconds here or there.  I found myself wanting to debate the position but it was not the right venue.

In my opinion a developer should not write inefficient code just because it is easier.  However, a developer must not tune code without evidence that the tuning effort will make a meaningful improvement to the overall efficiency of the application.  Guessing at where the hotspots are in an application usually leads to a lot of wasted effort.

When I talk about designing and writing efficient code I am really stressing the process of thinking about the macro-level algorithm that is being used.  Considering efficiency (e.g. big-O) and spending some time looking for options that would represent a big-O step change is where design and development performance effort belongs.

For instance, during initial design or coding, it is worth finding an O(log n) alternative to an O(n) solution.  However, spending time searching for a slight improvement in an O(n) algorithm that is still O(n) is likely a waste of time.

Preemptive tuning is a guessing game; we are guessing how a compiler will optimize our code, when a processor will fetch and cache our executable and where the actual hotspots will be.  Unfortunately our guesses are usually wrong. Perhaps the development team lead was really talking about this situation.

The tuning circumstances change once we have an application that can be tested.  The question becomes how far do we go to address performance hotspots?  In other words, how fast is fast enough?  For me the balance being sought is application delivery time versus user productivity and the benefits of tuning can be valuable. (more…)