Collective Wisdom from the Experts 47
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), it is probably going to be relatively painless to merge it into your cur-
rent 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 sys-
tem 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 his 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.