The Developer Experience

Software maintenance as a whole is often given a low status. You do not often hear that a company's top talent is assigned to maintenance tasks. Perhaps they need be.

It is no wonder why the best developers do not want to be assigned to maintenance. There are often poor working conditions. This applies both to the physical environment and resources you are provided. It might also apply to the technical personnel you must work with.

Like many other areas of software engineering, I have heard that the maintenance phase is more and more becoming an activity that can be outsourced. This is understandable given the low status of the activity.

However maintenance is not all doom and gloom. There are some fun aspects to working on the maintenance team. You normally can achieve quick closure on issues. Bugs can be researched and resolved within a week. Normal software development cycles are very long, with customers not seeing the end product for a year or more. Given a broken maintenance project, you can implement process improvement and hopefully see positive results from your efforts.

On a personal note, I myself have spent the latter part of my career in the software maintenance realm. There have been a lot of ups and downs. Luckily I am on an up cycle right now.

Lack of Information

Software maintenance as a field seems to be kept in the dark. Have you ever heard of a conference dedicated to maintenance? It is just not sexy or important enough.

There is also a general lack of books dedicated to the topic. Some books might mention the maintenance cycle in passing when discussing all parts of the software engineering life cycle. But we need details to survive the maintenance conundrum.

The problem extends into education. There is a lack of courses on this topic as well. The best that I remember from Computer Science was one on Software Engineering. However I gauge that most of the class got little information on maintenance from that class.

Finally, I do not think I have seen many web logs focusing on the software maintenance task. Again this may be due to the fact that developers don't like doing maintenance. I figure I can do my part by continuing to explore the subject in this and other blogs I am involved with.

Making the Best

Given the challenges of maintaining software, we can still make the best of the situation. Part of this can be set up during the initial software development. Designs with high cohesion and low couple make for easier maintenance later. But often this is out of the maintenance engineer's control.

A good problem resolution process can also go a long way to keeping maintenance tasks under control. This can be applied to any level of software maintenance maturity, because there is always room for process improvement.

The main way to ensure quality software maintenance is to drive it from a management level. This could be as simple as keeping an accurate work breakdown structure of major tasks. It will serve as a communication tool to internal staff as well as external customers.

Another beneficial management tactic is risk management. Being proactive instead of reactive to perceived risks is essential. And being proactive requires more than just lip service. It means truly analyzing, documenting, ranking, and mitigating risks before they become problems.

This is just an overview of ways to control the software maintenance beast. I plan to discuss each of these topics at length later.

The Good News

Luckily there are some troublesome parts of software maintenance that we can impact. Often times these mark the difference between success and failure.

In the heat of a broken system, there can be a strong desire to fix bugs ASAP. Often a conflicting goal is to make updates which keeping costs under control. It then becomes easy but detrimental to allocate limited resources to problem resolution.

Even though maintence is often a huge part of the software life cycle, it is not given priority. Lowly employess get assigned the bug fixing tasks. Original developers are usually not around once the system has been delivered.

And while maintenance usually comprises of fixing bugs, the system requirements can be ever changing if customers are not managed well. The good news is that this and all other issues I list here can be avoided or minimized with good management. This is the heart of what I want to dicuss and explore in this blog.

Out of Control

There are many challenges associated with software maintenance that we have no control over. It is good to identify these to know what we are up against.

There may be a significant existing code base. This can make it hard to comprehend the big picture of the system. The system may span multiple software products. To compound this problem, there is almost always insufficient documentation if any.

The design can be hard to follow. Sometimes good initial intentions deteriorate over time. This is inevitable when somebody puts a patch on top of the patch of the patch. In the end, you not only have something that is hard to maintain. It can be nearly impossible to understand.

Use of the system may require live data. It may also require lots of it. Typically the software works fine in a development environment. You often cannot replicate production problems. This can lead to a balancing act to keep up with problems but protect the live and often sensitive data.

Maintenance Characteristics

Previously I had tried to define software maintenance. This proved to be a challenging task. It might be easier to list some of the properties of the maintenance world.

Most software maintenance is not actually "maintenance". That is, much of the work is more than just preventative tasks to keep the software running. It is frequently described as the evolution of the software.

Software maintenance can be likened to a service. Often times it does not involve touching the code. It may just be an advanced form of user support. One thing is certain. The activity is very expensive in terms of the total cost. It can easily be well over 50% of the costs over the lifetime of the system.

The dark side of maintenance, like software development, is that it has a low success rate. Software maintenance can often spiral out of control. This is just the tip of the iceberg of nasty challenges performing maintenance. But this is a topic all its own.

Maintenance Definition

Before we start discussing the intricacies of maintenance, it would be good to try to define it as it relates to software. One might think this is simple. A user submits a report that a program is not working. However maintenance consists more than just fixing bugs.

Even when problems are being resolved, the changes reach farther than just the code. Documentation often needs to be updated. The original design may need to be updated. Test plans may need to be updated or even written.

Some environmental changes result in maintenance work as well. The data being processed may change. Or there may be additional features required in the software. A new operating system and/or compiler could drive maintenance tasks.

A change that could be classified as bug fixing is resolving performance problems. These problems could stem from larger amounts of data. Or there could be unusual combinations of data which do not scale well. To the user this is just another problem. But the work performed to fix this may be much different.

As you can see, software maintenance does not fit neatly inside a box.

Start it up

I fix software bugs for a living. That means I live the maintenance trenches getting dirty daily. But recently I have been thinking more profoundly. I focus less on the details of the latest software bug. And I ponder the theoretical side of fixing code.

It is easy to jot down the random events that occur during the work day. It is more work to recognize the patterns of software maintenance. A great artist once sang, "Stand in the place where you are. Think about direction. Wonder why you haven't before".

So let's do this. Let the deep thought on fixing bugs begin.