Clever Code Is Hard to Maintain

Developers are often asked to create miracles. They must find clever ways to make today's project code work with yesterday's antiquated, legacy software containing multiple patches. And through skill and ingenuity they may create numerous lines of clever code that finally get the job done. But clever code may only creates future maintenance problems due to the code's length and complexity. There may be a better way.

If you are a project manager new to software development, don't be afraid to let developers explore new languages and development tools. Allow them this freedom, because this is how they discover innovative ways to improve their coding practices and results. They may be able to design a software solution to your legacy interface problem that is faster and has fewer lines of code to test and maintain. This is certainly an advantage to your project.

There are innovative new programming languages that can perform the same functions as your current ones with substantially fewer lines of code. This is of value in that a simpler code structure is easier to test, can be self-defining, is smaller to store, and is easier to maintain.

Obviously, there are some concerns about adding new languages and platforms within your organization. Will this new code truly solve the problem for the current software or upgrade under development? Will it interface long-term with the existing software used in your legacy databases, user interfaces within the organization, and third-party software in which the company has already invested?

Are there other developers on the team or the department who will be able to create software in this language or on this platform? Is there adequate product support from language authors? Will there be timely updates and improvements?

Even if you are not familiar with programming yourself, don't be reluctant to allow programmers to embrace new languages. If the new language can trace its tortured lineages back to C or Java (or any other common way of doing things) is probably going to be relatively painless to merge it into your current practices.

However, be sure to document any new practices within your code. Otherwise, your code base and the documentation about the code may diverge to the point that the best way to understand the system is to look at the code itself. This is called a "loss of coupling" between the software components and system metadata. And when there is inadequate documentation to maintain your software system, it must be replaced.

Encourage your project team developers to be innovative, but not clever to the point of excessive complexity. Being too clever makes it hard on those who follow. If later developers can't read the code, how can they be expected to maintain it? Any given programmer may try to be clever to enhance their job security, but no project manager will benefit from it.

Code that is too clever will ultimately be too hard to maintain. That leads to maintenance failure and a costly reworking of your software systems.