Your Next Role: Software Maintainer

Once upon a time, developers tested their own code. Over time it became clear that quality assurance was its own discipline and deserved its own role. Likewise, it seems to make sense to start distinguishing between developers and maintainers of software. We currently mix these together into a single position, and as a result, create a lot of frustration for those in the industry.

Maintenance is a fact of life. The great build-out of the internet is arguably behind us, and for various reasons, it seems clear that much of the resulting work is questionable. Real-time systems like internet services are not easy to rewrite - the current running version typically cannot be frozen.

Maintenance cannot be seen as inferior to development. There is a perception among many that quality assurance tends to be staffed by non-developers or failed developers. It is likely too late to change this perception, but it a similar schism cannot be allowed to form between developers and maintainers.

Software will be viewed as an organism. Iteration is a fact. Moving targets are a fact. Code is born, reaches maturity, and dies. Like anything organic, it reaches full utilization only when it is mature. Our industry will have to abandon the failed dream of "created" software and adopt a model of "grown" software.

I am not talking about Agile or SCRUM. Those methods still place the developer on a pedestal and treat post-delivery maintenance as an inferior trade. Agile and SCRUM focus on software development, not maintenance.

Developers may become prototypers. The role of the clean-sheet developer may end up being like that of a surveyor - finding the right conditions, picking tools, and knowing what the general goals are. The maintainer is the "closer". The maintainer would carry the code to a live operational state and keep it there over time. In most cases these two parties would communicate directly, but a common situation will be when it is impossible for the maintainer to communicate with the developer.

Forensics will be a big deal. Maintainers will often have to open code of unknown origin and shoddy condition, and be able to keep it running and move it forward. The maintainer will have to understand everything the developer understood while imposing operational discipline on the running system. The maintainer's skill set will be a superset of the developer's. Fixing something unknown is harder than making something known.

The maintainer will need new tools. We don't really have good tools for dissecting unknown code bases beyond trying to find the entry point and following events. We basically have nothing tools-wise to help the maintainer approach a new unknown codebase. Our entire industry is still focused on tools to write code instead of reading it. There is a major opportunity here.

Companies will realize maintenance is more important than construction. Construction is only done once, maintenance is perpetual. Companies will inevitably focus on lifetime management of living code as a key initiative.

last update 2015-05-02