Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Funnily enough this concept applies equally well to optimizing a piece of software as it does a human business process. This is because it all comes down to some simple math. There are symmetries in everything.

When you look at system with the goal of trying to improve the speed and output, the first thing you need to do is try to look for what the biggest ‘bottlenecks’ are. Think of the problem abstractly in terms of components of the process. Let’s say they are A, B and C. If we look at the break down of time spent on these things maybe it breaks down as:

  • A takes 5 minutes (5%)

  • B takes 1 minute (1%)

  • C takes 94 minutes (94%)

Total time is 100 minutes.

As a manager or a software developer if we focus our efforts on making A or B twice as fast we won’t see a measurable improvement - increasing the speed of B by a factor of ten times only will barely produce a 1% increase in speed.

But if we focus our efforts on making C change from 94 to 47 minutes then the figures will change to this:

  • A takes 5 minutes (9%)

  • B takes 1 minute (2%)

  • C takes 47 minutes (89%)

Total time is 53 minutes.

If we further optimize C to take it down to 5 minutes then the figures stack up like this:

  • A takes 5 minutes (45%)

  • B takes 1 minute (9%)

  • C takes 5 minutes (45%)

Total time is 11 minutes.

What is interesting about this process is that as you solve one bottleneck then usually another bottleneck emerges as significant. At this point optimizing A would now offer some opportunities to make measurable improvements in the process.

Often though it’s easy to fall into the trap of not being analytical when it comes to optimizing things. People often fall into the error of optimizing things which they think will make a difference but do not which results in effort being spent on things which don’t create impact - i.e. optimizing A and/or B before optimizing C.

So the next big question is how, if our goals are to be trusted advisors to the management of our customers what are good questions to go about identifying bottlenecks? Here’s a few ideas:

  • Bob/Lois tell me about the breakdown of a typical week for you?

    • What did you do Monday, Tuesday, Wednesday, Thursday, Friday - what is consuming most of your time?

  • Give an example of a problem you had to solve recently?

    • What made it difficult to solve the problem? How long did it take?

  • What is the most time consuming part of your work flow?

For me personally if I am managing developers I look for typical patterns which slow them down - i.e. if it takes them a long time to compile, run and test to reproduce an issue they are working on solving.

  • No labels