The Vicious Cycle of Support

Developers who don't have to support their code in Production unsurprisingly don't consider all the implications of their changes.

Logging, monitoring and alerting are afterthoughts. Questions like "What happens when the network fails?", or "What if we run out of disk space?" aren't at the forefront of people's minds.

The difficult test scenarios get ignored because "We should probably test those things, but the test environments are rubbish and besides, this is how we've always done it."

But the result isn't just that a particular feature going live drags some poor guy out of bed at 3am (the traditional time that hypothetical production issues take place). And it isn't just that the metrics on number of live incidents rises over time. It goes much deeper than that.

When Support teams are separate to Development teams, developers don't understand the domain of Support, and vice versa.

The problem with the former is that systems that weren't designed to be supported are hard to support. The cost of that support effort grows over time.

The problem with the latter is that if Support people make fixes, they do so without understanding the domain fully. This causes further instability and technical debt, and also creates a system which neither developers nor support people understand.

Of course, developers continue to build on these foundations, which compounds the problem still further.

Still, you shouldn't be downhearted as a developer in this kind of company. At least you don't have to support it!

See Is Eliminating Cross Team Handoffs Possible?