The Revolving Door in IT Development

There is a big difference between completing development and actually getting the developed work to production. Especially when you work with high volumes of changes. Often, whenever things get stuck, managers tend to think that adding more development capacity will obviously fix the problem. Or, at least allows a catch-up on delivery once the unexpected problems are resolved. But in reality, boosting development capacity can actually make matters worse.

 

Fred Brooke explained this in his book The Mythical Man-Month: Essays on Software Engineering, first published in 1975 and now regarded as a timeless classic on the human elements of software engineering. Whilst working at IBM on the development of OS/360, he added more programmers to a project which was falling behind schedule. Afterwards, he concluded that adding manpower to a behind schedule software project only delays its completion. Brooke argues that large programming projects experience different management problems than small ones, due to the division of labour. To illustrate the issue, let’s use the analogy of a revolving door.

 

Similar to a building’s revolving door which continually rotates at a normal rate as long as there is a constant flow of people entering and exiting, if anything hinders the rotation, the door will either slow down or stop. Were someone to bump into it, the door’s injury prevention system kicks in and automatically stops the door’s rotation, which restarts again after several seconds. Similarly, during busier times a bottleneck might appear as the flow of people using the door will be superior to the door’s rotation speed and capacity. Finally, if those using the door are impatient, they will try to squeeze in and only slow the flow and door rotation, consequently only causing more delay.

When applied to IT development, the revolving door represents the environment in which code changes pass through. Whereas the people represent the changes being delivered. As long as they’re not yet released, they won’t cause much harm. Although of course, you don’t want to wait too long. But once you start pushing changes through the environment, the greater the risk of delays occurring becomes.

 

 

Following the analogy trend, let us adopt the “nine women can’t make a baby in one month” idiom to explain the difficulties associated to IT capacity planning. The notion that more programmers equals more deliveries, doesn’t consider the differences in the given work or the amount of programmers. When you look at the possible reasons behind delays or underlying causes for delays, this becomes apparent:

Take Mike for example. As a senior programmer, he possesses various skills useful to his team. So when his project starts lagging behind and extra team members are assigned, it seems logical to ask Mike to train the new members. But this also means that his own programming work is put on hold. The reoccurring challenge that appears whilst planning your IT capacity is related to determining the specific amount of capacity increase needed thereby reducing lag or preventing further delays. Consequently, this may mean shifting tasks or priorities for specific team members.

 

 

Typically, adding more development capacity generally does result in getting more changes in a deliverable state. However, this also increases the likelihood of things getting stuck in the environment it needs to go through. Moreover, the quality of work may falter under time-pressure, or, overtime will lead to fatigue and demotivation consequently adding more delays.

The best thing you can do is to improve your capacity planning and match the number of deliveries to the environment you’re releasing in. And what if your revolving door starts slowing down or even stops? Don’t try to squeeze more people in. Remember, patience is a virtue.