Why Project Maintenance Should Not Be Done By A Separated Team

Suppose you have to add a new major feature to an app.

Is it easier to add this major feature to a relatively small app, still under construction, not yet in production, or to a big fat app that has grown over time, whose overall quality is questionable, which is already running in production serving several clients

Well, there is no doubt. The second is a much more challenging task. But then, why do we usually find the most experienced developers, the architects, i.e. the cool guys, mostly involved in the first while the rest of the folks are often buried in the second?

Many years ago

When, many years ago, I entered the dev team responsible for one of the core systems of a big Corporation, the first position I was given was in the Application Maintenance (AM) team responsible for the legacy parts. The reasons were simple and shared: I was new to the place, new projects were running fast using leading edge technologies for which there was not much experience. AM would have been the right place for me to grow without too much pressure. As soon as I had gathered enough knowledge and experience I would have moved to the Project team, the team developing new features with new technologies, the team of the cool guys. After one year or so this actually happened, but I will never forget that supposedly not-so-stressful period of AM.

The Project team and the AM team

All this was many years ago but, since then, I have seen the same pattern repeated endless times, often in much more extreme forms. You have a new initiative, you start with the Project team. The Project team develops the architecture, the Project Team develops the features, the Project team accumulates delays with respect to a very optimistic initial plan, the Project team starts working extra hours, the Project team starts cutting corners. Quality is often sacrificed to the altar of the Plan, tests are forgotten and patches are added on top of patches. Developers start adding comments “To be refactored as soon as we have some time”. Technical debt is already there and its destiny is just to grow.Eventually the thing is brought to production and then, immediately after the go live, the Project team starts the transition towards the AM team. After some overlapping period, the AM team is left sailing alone. The AM team is usually younger, less experienced and considered less strong than the Project team. The tough part is over, the project is live. Now it is AM time, it is easier, it has to cost less, we can afford a new junior team.

One year after the go live

It has been one year of intense work. Bugs have been fixed, little things have been changed, little things have been added. The system has been eventually made ready to sustain real production load and the codebase has grown. At this point the AM Team receives a request to add a new big feature. And we are back to the initial question. Is it easier to add the new feature now or was it easier to add a new feature when we were in Project mode?The answer is clear: the task for the AM team is much more difficult. It is true that the AM team is sitting on the experience developed over time, but at the same time the AM team needs to touch heavily a not-very-stable code base, needs to avoid introducing regressions without having a decent test safety net, needs to devise a way to deploy a new major version without creating disruption.Let’s say it. The AM team often faces a much tougher job than the Project team. So why, if the task of the AM team is tougher, all the cool guys were in the Project team and now are somewhere else, probably doing something else cool?

A possible answer: the Project team needs to lay the right foundations

One reason to have the most experienced people starting a Project is that, at the beginning, we need to lay the foundations for what has to come. We need to define the architecture and make some fundamental decisions about the design of the solution, so the right experience is required.At the same time though, at the beginning of a Project, we have usually only a limited knowledge of the problem we are called to solve. At the start of any significant Project there are many known unknowns and also many unknown unknowns. For this reason, the Architecture of the system has always to be considered evolutionary, and we need to be aware that many crucial decisions can not be made at the beginning but have to be made when the unknowns start to reveal themselves.Considering architectural decisions as things to be decided once for all at the beginning of a Project is often an illusion. Critical architectural questions may pop up at any time in the life of the SW system. Critical architectural decisions made at the start of the Project may have to be overhauled later, maybe because of new requirements, maybe because of new technologies coming over, e.g. the Cloud, maybe because they were simply the wrong ones for the problem to solve.So yes, it is true, the Project team has to make architectural decisions, but also the AM team has to make architectural decisions, and it has to make them in a much more complex environment.

You simply can not do the reverse

While the classical model of a strong Project team followed by a more junior AM team is not the most efficient in the medium term, the opposite is not an answer as well. We can not imagine to have a junior team starting a project and then transition it to a more senior team for maintenance, this is clearly not an option.

A case for subconsciousness

Maybe one profound reason why more senior people start new Projects with new cool technologies is that they like to start new things with new cool techs and then over time, when the work seem to become more repetitive, they simply want to move to some other challenges.This is good for their tech curiosity and this is good for their resume. But this is probably not good for the long term health of the SW system they are building.

From Project team to Product team

In 2006 Werner Vogels CTO at Amazon coined the famous motto to convey the idea that a team responsible for a Product needs to cater for it from its inception down to its run phase, where run covers both the Ops aspects as well as the evolution aspects. To put it simply, the same team is responsible for all phases required for a Product to be successful: design, build, run, evolve. This is the model adopted by the digital giants that have emerged in the last decade, from Amazon to Facebook to AirB&B. Their undisputed success is the prove that the model is the right one in the digital era.Nowadays a growing number of people start predicating the need to move from a Project oriented way of organising work to a more Product oriented model. This is a complex transformation which involves many aspects of an organisation, but for the theme we are debating here it definitely means to abandon the idea of separate Project and AM teams and create more stable Product teams. Product teams need to have the right mix of experienced people, the cool guys, and more junior people who need to grow. Working together with the cool guys, juniors gradually become cool themselves. Controlled rotation is then possible without tampering the quality of the team. 

Conclusion

In the era we are living, the Digital era, we have to be suspicious when we hear something like “and when the Project ends we will transition to AM”. 

This is not to say that there is no space for AM any more. There are still old legacy systems, usually serving the back office, which are egregiously doing their work, which are very stable, which just need some Maintenance. But when it comes to develop new differentiating digital capabilities we need to move away from the Project/AM model and embrace a Product oriented model, where teams are designed to be responsible for building not only the first version of the Product but also to run it, to learn from running it, to evolve it over time to make sure it remains relevant for the final users.