You have to downsize projects to save them

In an essay in 1955, Cyril Parkinson observed how bureaucracy expands over time regardless of outside pressures. One of the examples he used was how the number of employees in the British Colonial Office was at its highest when Great Britain had barely any colonies left to administrate.

The development of a software project is similar. In the beginning, a lot of work is needed to build the first few versions of the project. The teams on the project grow in size and sooner or later the project is close to the original vision.

At this point the project is in a crucial phase. There is a lot less to do than there was in the beginning but all the employees hired to ramp up the project are still there. It is now necessary to downsize the project to save it. If you keep more people around than the project needs, they will invent their own work. Teams will build features that nobody uses, iterate over UI designs that are more annoying than beneficial, add a homegrown Common Lisp interpreter to generalize whatever harebrained functionality in the name of good design, and generally just muck around.

It should be the goal of software projects to reach a level of maturity that they can be handed off to a maintenance staff that keeps the servers up and does the occasional bugfix. It should be the goal of people working on software to get their projects to this state of maturity so that they can move on and build the next great thing.

Most software could be like that. However, we need to acknowledge that it’s OK for software to be complete and it’s OK for employees to leave their project babies behind in search for new things to build.

You have to downsize projects to save them