In this short post, I’m going to share my thoughts on why I think it is neccessary to align your software project portfolios growth with that of the development department headcount. This sounds logical enough but not actively managing this can lead to an unwanted team erosion that you will only discover when it is too late… This post will give you the arguments to defend it in front of managment.
In any IT departement of any company there are different kind of tasks to do. A company in a more traditional sector, like mechanical eningeering needs an IT help desk to support the staff with daily problems like installing new software, setting up new user accounts and so on. Possibly there will also be a team that takes care of running the IT infrastructure, making sure that the network is up and running and secured from the outside, that email and ftp servers are up and healthy.
As soon as a company has the need for very specific IT systems that are tailored to its own needs, a development departement will be needed as well. If the company is producing software as a product for their clients, the development department moves out of the support line, into the production line of the business.
The development team will be responsible for creating new software systems, applications and websites that are used within the organisation or by the organisation’s clients. Within the lifecycle of these products, the initial creation of the first one or two versions is only a tiny step. When they get into production the realworld test starts. Is the program really doing what it is supposed to do? Does it help to reduce costs? Does it meet the expectations, the initial ideas set out?
If the software product is of any use, it will enter a phase where users will request new features. For the initial developers, this phase can be frustrating. An initial design might needs to be refactored to meet the new requirements. There may not be enough funding from the business to do the refactoring properly and soon little hacks have to be introduced to meet cost requirements.
Developers usually take pride in their work but when time and cost constraints force them to drop their quality standards, they easily get upset and soon look for other interesting projects that are at an earlier state of the product lifecycle.
Nevertheless the project has to be maintained by someone. This is usually where the manager will look for less experienced newbie developers to join the project. While the newbies get a chance to learn from what the initial project developers did, they also get a good feeling for “how it works in the real world”.
They are forced to make compromises between “technically outstanding code” and “getting things done”. If you staff right, these are the people who will keep your development department running in the long run. They will appreciate the learning they get from the more senior staff while also understanding the need to maintain code over time.
The rockstar developers, the divas who do not want to spend their time with maintenance, those whom you employed as a startup, to get things flying, will by now look for new challenges. For the manger, it is too late in their careers to teach them modesty. They can leave the company and find a job out there with ease and within minutes.
What are the options?
The managers only option is to give them more work that they find interesting enough to stay. For the top developers, it is a very simple cost/benefit analysis: “Given all other incentives, like compensation and so on are equal at any other company, is the benefit of doing project X bigger than the costs of a job transition, if yes, stay”. If the company doesn’t manage this phase right, their development department will get into crisis.
This crisis can be triggered from two sides: If the company fails to come up with interesting new projects. This is the obvious one and is not necessarily a problem when there are in fact no new development needs and the only job left is to maintain the current software project portfolio.
The other cause however is when there are in fact new projects in the pipeline but due to either an understaffing or resignations from “maintenance staff” happens. In either case the top developers will be forced to do more of the maintenance than they are willing to as they are the only ones left fit for the job. As it leaves them less time to work on challenging projects, their benefits in the equation above will diminish and they will eventually leave.
So sum it up, overtime more projects are added, the codebase naturally grows and so does the mainenance effort. If the headcount of the development team is not increased over time to match the project growth, new projects cannot be done anymore as maintenance of a live system is always more important than working on new ones that don’t yet payoff.
As a consequence the top shots will resign and you end up with a handful of maintenance coders who will now also not be happy anymore. All their colleagues who they could learn from are gone and no one is left to show them new tricks. As soon as they find a better offer, they too will leave.
So, it boils down to a very simple equation:
Codebase growth and teamsize have to be aligned overtime.
Sounds like a no-brainer but you now have the arguments to defend it in front of managment. And if you stick to this rule, you will not run into these kinds of problems.
If a company fails to consider this, reality will kick it in the… knee.