A Case Against the Separation of Support and Development

Many large companies have made the decision to separate the support of software from its development - forming separate teams to focus entirely on one activity. The reasons behind this decision make a lot of sense on the surface. Developers are free to focus entirely on their projects unhindered by the distractions that day to day issues cause. Support teams can dedicate themselves to quality interactions and production incident resolution. Developers don't have to deal with frustrated users and support engineers don't have to mess with code. Unfortunately, in practice this model often leads to more problems than it solves.

Communication Breakdown

"Agile" is increasingly becoming a common buzzword in enterprise IT. Many large business are trying to implement agile practices in their development teams in order to become more responsive to the needs of their users. One of the core ideas of agile development is frequent and effective communication with users in order to bring continuous improvement throughout the project.

When support and development are separated, however, one of the most effective and practical opportunities for direct communication with the user is lost. When a user has a problem, they have a real-world example of a way the software they are using is not meeting their expectations or their needs. This is a perfect opportunity to work directly with a real user to understand how they are using the software in the real world and learn more about how they intuitively wanted it to behave.

A separate and isolated support team, however, acts as a wall between the user and the developer, shielding developers from vital feedback in an attempt to protect them from distractions and increase productivity. Developers operate without the guiding light of constant real-time feedback, and users become frustrated because software consistently misses the mark when it comes to usability. Support teams communicate trends and enhancement ideas to the development team, but the benefit of direct communication with users regarding their experience and perception is lost.

The Challenges of Dedicated Support Teams

Support teams that don't develop are at a steep disadvantage when it comes to effectively analyzing issues and identifying practical solutions. Support engineers aren't able to become truly familiar with the codebase since they don't spend time diving in and manipulating it. Documentation is typically one of the first things sacrificed when projects are constrained, and dedicated support teams suffer because of it. Support teams are not able to build up true expertise because they are not exposed to the underlying mechanics of what they support.

Support becomes very good at handling frequent and repetitive issues, quickly eliminating the symptoms of a problem and resolving a common incident. When a new issue arises that is not routine, however, it is often difficult for a dedicated support team to effectively troubleshoot because they have no experience debugging in the development environment and an incomplete knowledge of how the software works behind the scenes. Support teams are able to aggressively attack the symptoms of a problem, but they seldom get the chance to dig deep into the root cause and truly prevent the issue from reoccurring.

Accountability

In a separated support and development model, developers often miss out on the opportunity to learn from their mistakes. In the real world, no code is ever truly perfect. Coders will inevitably create bugs, and the process of troubleshooting and eliminating the bug is a very valuable part of the learning experience. When a dedicated support team is handling all of the incidents, however, it separates the developer from the results of those errors and takes away that opportunity for growth. Accountability suffers since developers are shielded from the effects of mistakes in design or implementation. This often results in frequent occurrences of common issues that are never addressed and bugs that survive for years simply because their symptoms are relatively easy to control.

Working Towards a Solution

My suggestion for a better way to address the issue of support in an enterprise environment would be to set up a rotation schedule for developers to handle support. I wholeheartedly agree that frequent minor distractions have a major impact of productivity. Instead of dropping everything in the middle of a project to handle production issues, developers should be able to set aside certain days to shift gears and focus entirely on support. On non-support days, they should be free to concentrate on projects and code. The development team would definitely have to take on additional headcount to compensate for the additional workload, but in my opinion the advantages would far outweigh the cost. User satisfaction would soar because they are able to interact directly with the developers that make a real difference in the tools that they use. Problems would be resolved more efficiently because the engineers involved in the resolution would have a more intimate knowledge of the software being supported. Developers would gain a more complete picture of how their software is being used and what their users want it to do.

In this model, it would be very important for developers to be prepared to handle this continuous feedback constructively. It should be recognized as the shining opportunity that it is, a direct channel for real time practical insight into the needs and expectations of the users. This kind of real-time communication with users in the midst of real issues is invaluable to pragmatic developers who can use this experience to make software much more intuitively usable and valuable to the target audience.

This is certainly not the only way to address this problem. I'm sure there are many reading now that have experience with this type of environment, and I'd love to hear what worked, what didn't, and why. I'm sure that there are also many of you who feel that the advantages of a dedicated support team outweigh the challenges. Feel free to use the comments below to give me your take on the topic, and continue the discussion. Thanks for reading!