Development is support, support is development
Over many years in software development, I have observed a persistent industry pattern: companies typically structure software work into distinct project phases, then hand off completed products to separate support teams. This model assumes software is static — something you build, finish, and use indefinitely.
The Traditional Software Lifecycle
The conventional enterprise approach typically follows these steps:
- Someone has an idea
- Idea is considered good enough to be invested in
- A team is assembled and discusses vision, setting up a plan
- Plan is executed with software being written
- Team hands over the project to a support team
- Software is being used
- Support team keeps software alive throughout the years
Problems with This Model
The Static Software Assumption: This approach treats software as a finished product. However, bugs get fixed by people who didn’t write the original code and lack its context, resulting in poor support and additional defects.
The Static Business Assumption: Companies assume their business needs remain constant. Rather than software adapting to evolving business needs, organizations must adapt to inflexible software packages, harming performance.
The DevOps Shift
The DevOps movement is changing development practices, with teams now supporting applications during building phases. Yet supporting products during initial development differs fundamentally from evolving and supporting them throughout their entire existence.
A Better Approach: Software Evolution
Products in active use should evolve as user needs change. They deserve first-class treatment where maintenance and code evolution proceed together, preventing legacy code accumulation. While post-launch teams needn’t match initial development size, they must maintain customer contact and focus on product evolution rather than reactive patching.
We should stop using support as a bad word. We should start talking about software evolution.