When booking a hotel or a flight for your next trip you could do it the old way: surfing a lot of websites looking for cheap and relevant offerings. Or you could apply "Inversion of Control": specify your wishes regarding travel and accomodation and then wait for a lot of hotels and airlines to send offerings for you to choose from. Hotwire is one example of that kind of service.


When surfing the net, a lot of websites "push" commercials onto your screen earning money to the people running those websites. Wouldn't it be nice if you instead could "pull" selected commercials and thereby provide funding to your favorite charity? AidOnline is one (Danish) example of that kind of service.

As a programmer it seems to me that these two examples of "Inversion of Control" are structurally similar to the popular unit testing technique called "Dependency Injection".

Can you come up with other interesting examples of "Inversion of Control"?

By Lars Thorup

At a retrospective meeting with a client not to long ago, a really interesting point came up. The client had deliberately attempted to push a lot of feature work onto the development team, while keeping a fixed deadline - presumably to have the team work harder, and thereby producing more features before a particular deadline. Interestingly quite the opposite happened.

A total of 7 features were requested by the customer, while neither deadline nor scope change could be tolerated. The result? 7 features were reported done on the deadline. Unfortuately it turned out - in production - that only 2 was working as supposed, meaning that 5 was more or less defective.

When these numbers were clear to everybody an obvious question came up. Could the team instead have aimed for a total of 4 features (instead of 7), and actually completed 4 features upon the deadline (instead of 2)? Significant amounts of time had been invested in 5 features that were not completed anyway.

Who were to blame for this? The development team were only doing their best, trying to accomplish a goal not set by themselves. How could the client know any better? They did not know the kind of problems that are induced by using a push approach.

What the client and the development team had experienced was simple physics.

Little's Law:
Work in process = Flow time * Throughput

Little's Law describes the relationship between multiple key variables in any value stream (including software development projects)

What Little's Law says, is that - The more work you start, the longer it will take you to finish (given that your capacity/throughput is stable). Now imagine what happens if the customer asks for a fixed deadline - The amount of work that can be done before that deadline is indicated by the current capacity.

How about if we attempt to get higher throughput/capacity by increasing the amount of work, and asking people to work harder. Which variable do you think will be affected? ..you guessed right, Flow time will increase, as throughput (or capacity) does not increase magically over night.

I wonder how many people in the software industry are trying to outrun Little's Law, by putting pressure on the "floor" workers (e.g. developers and testers) ?

Lesson learned?
1) Don't try to run above the speed limit indicated by your current capacity. You will pay more and get less.
2) Favor pull systems over push - for instance as advocated in Scrum.
3) Never attempt to fix scope if you have a fixed deadline.

By Sune Gynthersen