Is a Project Good If It Cannot Be Managed or Maintained?

Throughout this website, as well as in The Programmer’s Black Book, I stress the need for a software solution to be maintainable. In fact, if it isn’t easy to maintain, the project may be a complete failure, leaving you with an extremely angry client (who will probably never trust you again) or a company facing a financial hole it has to fill.

We don’t build software just to work now; we build it so it can evolve and be maintained easily over time. For me, this is a mantra I repeat and a principle I won’t compromise on.

Maintaining a software project in production ultimately means knowing how it behaves, clearly identifying maintenance activities, being able to pinpoint problems easily, and, above all, being able to do all that efficiently and quickly.

Administration is related to all of this and is just as important: if any software product is inefficient to administer, we’re putting its viability in production at risk.

No matter how well our project may appear to work, if it can’t be maintained or administered properly and efficiently, we’ve actually built a rather poor project. To make software maintainable and manageable, we have to design it from the outset with ease of maintenance and administration in mind.

Recently, while carrying out some maintenance on the website of the company where I lead software projects, I was reminded of this crucial, intrinsic aspect of development. The site runs on Drupal, and some modules were overdue for updates. People who know me won’t be surprised that I lead software projects while also getting deeply involved in low-level development. Can you really lead something without knowing it well enough?

There’s a project well known in the Drupal community that makes maintenance, monitoring, and administration of a Drupal-based website very easy and, above all, very efficient: Drush.

For example, if we need to update Drupal Core from version 7.xx to the latest version (7.32 at the time of writing), we could follow the official steps on a staging instance. More or less, they are:

• Back up our system (files and database).
• Download the latest version of Drupal.
• Copy it over correctly while preserving our /sites folder.
• Run the /update.php script.
• Finally, check that everything went well…

This is routine work, and in my opinion the many Drupal 7 releases are a good thing, since each one improves aspects of Core or includes security updates.

Even so, the process above can be tedious, even if we only have to do it every two or three months. With Drush, however, all of that can be done with:

$ drush up drupal

One simple command-line instruction carries out all the steps above. What was a burdensome task becomes a single command with Drush.

Similarly, with:

$ drush status

we get an overview of the Drupal instance.

I mention this as a wonderful example of ease of maintenance: the first approach can take us 10 to 30 minutes; the second, less than a minute. Isn’t that productivity? I wonder how many similar activities fill our days that we could optimize.

Unless we’re building test or evaluation projects that will never go into production, I personally care a great deal that whatever we build provides enough options, information, and tools for easy and efficient maintenance and administration. This is the key to the success of many software projects.

What’s the point of a product that cost X euros to develop if it costs three times as much to maintain? Do projects make sense when several people are dedicated full-time just to maintaining them? Isn’t that evidence that things weren’t done quite right during development? I remember a few years ago, when I spent part of my workday maintaining a remote-management system at a client’s site. I’d lose hours digging through the database with tedious queries to find and solve certain problems.

I wonder how often, in situations like this, the old Spanish saying “worry about the peseta but not the duro” applies (before the euro, a duro was worth five pesetas). In technological terms, it would mean something like “trying to make short-term development very cheap without realizing that maintenance will be very expensive.”

Any software product is developed once but maintained continually (at least until we run out of clients).

Likewise, any sensible client should consider how much something will cost to maintain before buying it, and whether its administration will be efficient and straightforward.

What’s more, we could turn this capability into another value proposition for our product: maintenance that’s simple and inexpensive.