Why traffic lights are evil

A few days ago I had to take a drive from Den Bosch to Tilburg (A65). If you know that little piece of road, you know there are a lot of traffic lights. I understand the value of traffic lights: they reduce accidents and distribute a fair opportunity for people to cross the road. If you'll ever drive on the A65 however, you'll notice that the abundance of traffic lights really slow you down. Also, you'll notice people pushing to get to the green light in time, slowing down only at the last minute, creating dangerous situations. If you think about the environment (who doesn't these days) you'll get annoyed by the senseless pollution of extra slowing down and speeding up needed (not to mention that traffic lights consume quite a bit of electricity too). So, why are there that many traffic lights?

The traffic lights on the A65 were the easy way out for the people that designed that piece of road. They basically had three choices: provide less intersections, provide bigger intersections with on-ramps and off-ramps that do not need traffic lights, or put up traffic lights. At the time, roundabouts were considered evil because they were different from modern standards, so I don't count that as a choice. Obviously, less intersections would mean people near the road would get angry, because they would need a detour. Bigger intersections would be more expensive, and make people that live by the road angry, because their houses would need to be demolished to make room. So, traffic lights were placed, making everybody that actually uses the road angry instead. Law and politics often lead to such awful compromises.

Traffic lights are common in a software development project as well. Basically, a traffic light is a control point that controls the flow of action in a certain process step. The control point works like this:

• The control is usually performed by a different person than the person whose work is controlled.
• The control consists of a check against a simplified representation of reality.
• The result of the control is usually a simple redirection (do this, don't do this).

Depending on your organization, this may be happening very often or only once in a while. Like the traffic light, a control point may have its uses. However, it always has downsides:

• The control point will slow down the work being controlled. This means the work is in progress longer and the return on investment will be later. Responding to changes will take longer.
• The control point will cost extra resources. Performing the control action will take additional time without adding value to the product. Slowing down and speeding up before and after the control point requires additional resources as well.
• The control point will almost always simplify decisions to a point where not all the information available is used, thus increasing the risk of sub-optimal result. It will be something like running a static check list or a manager needing to sign off.
• The control point reduces the opportunity of initiative of the person whose work is controlled. He/she will no longer feel responsible and is expected to blindly follow the result of the control.

I need to re-emphasize that control points are needed at times. Sometimes, laws require them, or they are needed to prevent catastrophic events (like a car accident). However, control points are often a result of excessive prevention strategy (not every problem is worth preventing), lack of trust, lack of skill, lack of delegation, or lack of communication. When you hit a traffic light in you organization, it may be worth thinking about:

• Why is an explicit control needed? What is lacking in skill, available information or decision powers in previous steps? Is a control point the only way to cross this gap?
• What is the risk being prevented? How expensive is it, in terms of money, time, damage, etc? What is the chance of the risk occuring with and without the control point?
• What is the cost of the control point? How much overhead does it impose on the project? Did you calculate this overhead in your estimations and budget as well?
• Can you optimize the control point? This can be done using automation or optimizing information flow for instance. Note that batching is almost always a very bad optimization strategy in a software development project.
• Can the control point be circumvented? At times, it may be legitimate to ignore a control point, for example because of time constraints (an ambulance en route to an accident). How often is the control point circumvented? Is the circumvention explicit and accepted, or does it happen under the radar?

I think a lot of traffic lights would not be needed if the roads would be constructed just a little bit different. Sure, it would be more complex to build roads, but the result would be more efficient roads. With traffic lights, the roads jam up pretty fast, requiring even more roads with even more traffic lights!

Share this