Over the years I have worked in software development, one discussion I’ve often observed is the benefits of structuring software in projects, as most of the companies still do today. It seems that the de facto standard for software in an enterprise still is (rough sketch, this process varies a lot from company to company):

  1. Someone has an idea
  2. Idea is considered good enough to be invested in
  3. A team is assembled, and they discuss the vision and set up a plan
  4. Plan is executed with software being written
  5. Team hands over the project to a support team
  6. Software is being used (hopefully)
  7. Support team keeps software alive and kicking throughout the years

Admittedly, this is just a simplified version of what actually happens. Organisations differ in how they execute all of these phases and how long it takes to go from one to the other, but my main point is that there is usually a project team, that creates and puts a product live, and they will leave once everything is done. In some cases there will even be a country difference, where a local team will do the development, handing over to an offshore support team with the aim to keep the overall cost low.

As a consultant, I’ve seen the consequence of this behaviour too many times. Since no one is actively working on that product anymore, it keeps decaying, with some patches made once in a while to add new functionality. After a few years everyone realizes that it is cheaper to just throw the big ball of mud that they currently have away and rewrite the product from scratch… and the cycle starts again.

Now this helps to keep developers employed, so I should be happy about it, but from a company’s perspective, there are a few problems with this model:

It assumes that a software project is something static, that you can write, finish and then just use it for ever. Since it isn’t, the result is that bugs are being fixed by people that didn’t write the code and don’t have the same understanding of it, which results in poor support and probably more bugs.

It assumes that not only software is static, but also that the business is. So instead of thinking about software as something that is there to help an ever evolving business, it delivers a package that the business or their customers have to adapt to, probably resulting in worse business performance.

With the devops movement gaining momentum around the world, this scenario is currently changing in the development phase of a project, as Jen described here. We are starting to see more and more cases where development team support the application while they are building it, which is definitely a step forward, but it is not all that needs to happen. Supporting a product during its initial development phase is one thing, evolving and supporting it throughout its existence is another.

If a product is live and being used, than it should be evolving as the needs within that user group (and even new user groups) evolve. And if that’s the case, it should be treated as a first class citizen, where maintenance and evolution of the code walk together, guaranteeing that code doesn’t turn into legacy. It doesn’t mean it needs a team the same size as the one used to build it in the first place, but it needs a team that is in contact with the customer and aiming at evolving the product, not just patching it and keeping it running.

We should stop using support as a bad word. Actually, we should stop using the word support completely. We should start talking about software evolution.


Get every new post delivered to your Inbox.

Join 835 other followers