A jump to the left: Embracing software evolution

3 August 2017
| |
Reading time: 6 minutes

If you went back to the 90’s through a time-warp, you would experience a clear-cut distinction between software development and software maintenance. This has changed with the advent of DevOps thinking and tooling. And just in time, too.


As digitalisation transforms the world, businesses everywhere rely on evolving software solutions that keep changing while they are in active use and producing value.

Unfortunately, traditional thinking about software maintenance is still widespread and it inhibits the joint work ethos between “feature-minded” software developers and “service-minded” operations engineers.

In this post, I discuss why embracing software evolution is critical for creating value from all kinds of applications, whether they are mobile apps, web applications, or more complex solutions. These applications are the visible building blocks of digital services and successful services have to evolve with the needs of their users.

The go-live “jumps” to the left (in time)

When does a piece of software start delivering value? When it is live and applied to do useful stuff by its users. Naturally, we want this to happen as early as possible, without compromising quality.

Design thinking emphasises the use of prototyping to find out what users really need. Paper prototypes are fast (and fun), but at some stage a more detailed field test with real software is required. In our work at Zühlke, we see that we deliver software solutions in shorter increments: Demonstrators, proof-of-concepts, minimum viable products (MVPs), friendly-user trials. Instead of one “big bang” go-live, we see a succession of app versions that widen in scope and in reach. Therefore, being “live” starts early.

I think that this is just the start of a trend that will become even stronger. Lean startup guru Eric Ries says, “We must learn what customers really want, not what they say they want or what we think they should want.” We can only do so by experimenting and growing a solution, rather than through big design up front. Incidentally, this approach can also improve security.

Luckily, these business trends match the agile mindset of incremental delivery that is already established in the software development community.

Traditionally, however, software development ends with the go-live as the “final” delivery. Talking to software engineers as well as project managers, I have repeatedly come across the view that the following “software maintenance” phase is less interesting and should be left to lower-paid individuals.

This misconception starts with terminology. “Maintenance” often brings up an image of “correcting faults” and spending as little time as possible on this job. Would you then rather work in development or in maintenance? This is the problem.

DevOps principles to the rescue!

The Internet giants like Google, Netflix, and Amazon have pioneered a different approach, driven by their need for constant change. Integrating Development and Operations to form DevOps, they have achieved a software evolution process that allows for multiple feature updates per day.

Lagging somewhat behind Agile, DevOps is now also making its way into software product teams. But overcoming the gap between “feature-minded” and “service-minded” people is still a cultural challenge.

At Zühlke, we are developing new team setups for software evolution in the live phase. What are the challenges for these teams?

  • Integrate operational concerns early in development (e.g. in architectural decisions)
  • Scale up – for periods with intense feature development or refactoring
  • Scale down – for periods where stable usage is the key concern
  • Manage know-how sharing and Transfer
  • Coordinate work on ad-hoc incidents and planned backlog items

This list is far from complete. The move from software development teams to software product teams requires new roles and responsibilities. The best example that these are still evolving is the “DevOps engineer”, a role that has rapidly become popular over the last years (see chart).

Along with the service manager, we see the DevOps engineer as a key role in managing applications in their live phase. DevOps engineers come in different flavours, focusing on one or more of the following areas:

  • Development environment and continuous delivery pipeline
  • Runtime infrastructure for test and production, which is typically cloud-based
  • Operational monitoring and capacity management
  • Incident management, fixing defects, root cause analysis

Effective Service Management in any industry starts with a fundamental understanding of the customer” (John Hall). Therefore, both service managers and senior DevOps engineers need to develop a strong sense of business value, coming back to the need for software evolution in the first place.

Clearly, there are high demands on DevOps engineers, but how exactly does this role differ from the more traditional “system administrator” or “operations support” roles? To answer this question, we have to look at advances in computing infrastructure.

Cloud services and automation eliminate toil

Cloud infrastructure has fundamentally changed the level of abstraction for operating software. Platform-as-a-service (PaaS) environments and service APIs have replaced worries over hardware, energy, cooling, and redundancy. Through infrastructure-as-code, operational concerns like capacity, scaling, and security are moving further into the development realm.

Furthermore, frameworks and tools allow automation at a higher level than previously possible (think Kubernetes vs. bash scripts). This helps to eliminate the manual and repetitive toil that has given operations a bad name. The ITIL framework for IT service management still lists the relevant process areas, but what used to be manual effort now happens at the speed of light. The Configuration Management Database is called a Chef server now.

Consequently, the skills required for running modern build pipelines and cloud infrastructures are highly advanced. They require a full “engineering mindset” and the ability to work in an interdisciplinary software product team. The DevOps engineer is a role with an indispensable perspective – just as the product owner, the user experience designer, the software architect, or the software developer.

Always change a running system

Digital transformation needs software that emerges and grows towards customer value. Let us abandon the notion of development vs. maintenance and adopt a model of continuous software evolution.
The tools are there. The methodology is there.
We simply need to overcome the barrier in our heads.
Want to join the team and advance the art? Get in touch!

Comments (0)


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »