Software Maintenance

This freelancer or long fired employee may have written good code. However, as time passed, the original developer moved on: they were, perhaps, promoted, fired, or reassigned. Therefore, the responsibility for maintaining the software passed from developer to developer. At first, this is not a huge problem, the code is relatively simple, and the developer can understand what’s going on. However, as time goes on, software gets “crufty”, as we like to say in the industry.

This means it becomes more complicated to maintain: as each new developer joins, and takes over from the previous developer. valuable information and valuable experience is lost. In some cases, documentation and automated tests are no longer maintained, so new developers have a hard time understanding the software – and, importantly, understanding if their changes are breaking pre-existing code.

In time, this becomes a self destructive feedback loop. You see, as the code gets worse, new developers assigned to work in the project are less and less comfortable, they begin to view this project as a horrible mess. The result? They simply want to get away from working on it as quick as possible.

This tends to result in even worse code being written, since they’re trying to get in and out without breaking anything as quick as possible. Just like a firefighter entering a burning building to rescue a person. They don’t want to spend any longer inside that code base than they absolutely have to. That is, as you can imagine, not a good situation.

Often, the response is to bury the problem – ignore it as much as possible. After all, many software companies are geared around creating new software. This is understandable, since a significant portion of the software budget in many firms is geared towards that, not towards maintaining existing software. Unfortunately, maintenance is all too often seen as a second or third class priority.

The easiest to sell part of a software project is the beautiful screenshots and wonderful screen captures of new software being delivered. Maintaining the software on a day to day basis is more difficult for marketing people to market and for salespeople to sell.

Therefore, maintenance often takes a second or third seat at many companies. In fact, often when a person hires a software studio, it is true that initially, fairly skilled developers work on the project. Almost all software studios have at least some skilled developers – for example, the founders are often skilled programmers. But as time wears on, your software gets maintenance hassle, your software gets assigned to new hires to a less skilled staff. And this creates additional technical debt over time.

The Maintenance-as-a-Priority Approach.

At Durable Programming, maintenance is not an afterthought.

We believe maintenance to be an extremely important part of software. After all, when you create a new software project, it may be useful, or in time, circumstances may change, and it may fall by the wayside – in fact, some new software projects may never be deployed at all! However, when you are maintaining a working piece of software, you know it’s value – you are creating real value for people who regularly use the software.

We try to view our job not simply as writing computer code, but as delivering business value. Therefore, we are happy to do both maintenance and to create new software – but we like, wherever possible, to keep the business decisions with our clients. So, instead of forcing people to make a certain upgrade, choice, or invest funds in certain ways, we leave those business decisions up to the client.

For example, many forms before they will undertake, say, a Ruby on Rails upgrade will insist that a certain percentage of the clients code be covered by automated tests before they begin. Now, to be clear, automated tests have value. And there is a reason why other studios have such policies: it does make software projects more predictable for the studio, and it makes it easier to use less skilled developers on the projects.

It’s is, however, possible to leave the business decisions with the business people – it simply requires specialized experience, and a willingness to use logic and careful analysis instead of relying on best practices and experience. When a project has significant technical debt, a skilled development team can carefully improve such a project in the exact manner that the client wishes to.

When possible, we do suggest you invest in upgrading software, we suggest you invest in automated testing, and other useful modern innovations. However, we do not require that any particular versions of software be used or that any particular upgrade schedule be adhered to. It’s true that there are serious downsides, in many cases, to using outdated software, such as security concerns; we strive to make our clients aware of that. Ultimately, however, the upgrade schedule is a business decision, and we respect the decisions our clients make regarding their own software.

What’s Yours is Yours.

Fundamentally, our view is that your software is indeed your software.

It belongs to our clients, not to us. This is significant. Because although the client may not fully understand everything involved with our custom software, it is, nevertheless, their software – not ours. We do the best we can to educate the clients, so that they understand important issues. Likewise, we strive to let clients feel as if they have ownership of the code.

So instead of hiding away your software on our servers, so where you have no access to them, we do our best to give our clients access to their own source control systems, their own ticketing system if they wish. This is not required, of course.

Similarly, we do not attempt attempt to use technological or contractual means to ensure client loyalty. It is your software and you have a right as a client to decide who, when and what manner it is serviced.

So instead of attempting to make software changeover is as difficult as possible by refusing to document code or hiding away behind proprietary API’s, we attempt to do whatever we can, so that you can at any time change developers working in the code, you can add in house developers, you can add an additional outsource studio to work alongside us, and start or stop our service as you’d like.

We feel it is important not to use chicanery and foolish contractual or technical methods to ensure client loyalty. We feel that real client loyalty comes from doing an excellent job. And if you wish to change your budget or increase it or decrease it, you may contact us at any time in writing to do so.

Different Companies, Different Standards.

Many developers spend their entire career working at the same company. This has its advantages.

The company likely has certain standards – certain ways they do things. This can be advantageous – since they can prevent people from doing things in substandard ways.

The result is that a developer may spend their entire career working. If they work at Studio A working with code formatted and done in the manner of Studio A, they may use certain tools, certain conventions, certain habits, certain libraries, on every project, so when they go into a new project, they expect it to be there. However, Studio B may produce software that’s just as good, but they have different conventions, different libraries, they use different habits. And as a result, if Studio A takes a client from Studio B, it may be very difficult for them to manage. Because those developers may be wholly unaccustomed to those tools that Studio B uses. The situation is even worse if the software was created by an inexperienced or idiosyncratic programmer. In many cases, we want to cause software with very strange and not always understandable decisions that have been made. However, it is important to note that working with unknown software written by somebody else is in and of itself, a skill, a skill which you can hone and develop.

Our experience in this matters and this sort of thing. Makes it much easier for us to pick up other people’s code. However, it’s not just a matter of picking up the code and understand Sending it that’s an important skill. But another very important skill is to make changes in such a way that gradual improvement can be achieved while at the same time, not breaking parts of a system which we may not yet fully understand or have the ability to change. This is not a science, but an art and is an art in which we are very practiced.