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 create
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.The author of the original content can be found here