One of the criteria I have for separating true software developers from the hack and slash crowd is how someone goes about addressing the deficiencies and inefficiencies in their project. A project with a real software developer will see the number of pain points decrease over time, leading to higher efficiency and an easier to work with system.

So what is a pain point? I define a pain point as any element of the system or its development environment that is unnecessarily complex, time-consuming or fragile. Pain points are the things that get between the development team and the core tasks of building the required system.

One of the classic examples of a pain point is a manual build process. As the size of a system grows the effort required to produce a consistent, deployable system increases, as does the risk that the process will be performed incorrectly. This results in considerably more effort being needed to do deployments and a greater incidence of issues during those deployments. This can be eliminated by setting up a continuous integration environment that automates the build process and eliminates the manual steps required to produce a deployable system.

Another example in the development environment is the maintenance of database schemas. In some environments when a change is made to the database schema the developers will need to run a SQL script (or scripts) to apply their changes. This manual process may be error prone if the state of the database expected by the script does not match the actual state of the developers database. It can also be difficult to apply the scripts to a production database during deployment as they may not represent a workable transform from the old version to the new, despite having been able to make incremental changes to the development databases.

This may be addressed by scripting the application of the SQL scripts that generate the database. My personal preference is to start from a clean database and have the scripts build it in its entirety. By applying all the scripts in a known order, and by making the scripts immutable once they have been used in production we can have a fair degree of confidence that we can properly generate the database and move it between production versions.

Pain points may also be found in the code of a system. This can be seen when adding a feature requires changes to significant elements not related to the change being performed, or when the structure of the system fits poorly with the required change. This will commonly manifest as a need to duplicate logic in the system. This is relatively obvious when it is the same business rules, less so when it is a repeated pattern that is applied to different structures. A sure sign of this is that significant elements of the code are produced by using copy and paste and minor tweaking.

The solution to pain points in code is refactoring. There are a number of excellent references available, I recommend starting with Martin Fowler’s book on the topic.

It seems to be human nature that we can become used to a variety of things, doing them without really considering why we do so. It is for this reason that I try to evaluate my practices over time to see if I can really justify the way I do things. It is also for this reason that a new member to a team, even a highly competent and successful team, may be better suited to identifying issues than someone who has become accustomed to the way things are done. Some diplomacy when joining a project is generally advisable of course.

To come back to my original contention a true software developer will recognise pain points and address them. This necessarily has a cost as it takes time to perform these changes. However a professional will recognise that there is an overall benefit to be made from these changes and that addressing them will ultimately result in less effort (and hence cost) over the life of the system.

This is not to suggest that everything that could be addressed can or should be addressed immediately. It is still necessary to consider other concerns such as the need to deliver in the short term. What is important to avoid is a pure short term focus, the kind of “do this in the most expedient fashion possible, move on and repeat” attitude I find so deplorable. If someone is paying you to develop software for them it is your responsibility to make these tradeoffs in the clients best interest. An “expedience only” method of working ultimately produces low quality, high cost systems that represent poor value to clients over their lifetime.

It may be argued that clients demand expedience, but I believe that this is falsely implying that clients are idiots. Generally clients will be experts in the particular domain of their own business. It is unreasonable in most cases to expect them to be experts in software development but this does not mean that they cannot be reasoned with. As such it is possible to explain the benefits and tradeoffs of addressing issues. Preventative maintenance is hardly unique to software development and metaphors like Technical Debt can be highly useful in explaining these concepts to business people.

It is therefore my belief that if you develop software for a living that you have a responsibility to do so in a professional manner, and that this includes continual improvement so that you can focus primarily on the job for which you are being paid and not the incidental tasks necessary to support it. Or you could be a slack bastard who cares for nothing but convenience in the present, in which case I’d like to request you find another career.