Language Features for Management
written by Walter Bright
July 15, 2008
Programming languages are developed by programmers for programmers. This is as it should be. The last language developed for management was COBOL, a language that is often held up for ridicule and I’ve never heard a nice word said about it. Nobody has dared making a language for managers since.
The stereotype of the programming manager is embodied in the Dilbert PHB, or Pointy Haired Boss. He’s clueless, inept, incompetent, unrealistic, selfish, etc. We all love to laugh at that, but many (most?) programming managers have come up from the programming ranks and are anything but PHBs. They often have a difficult job of getting a diverse group of programmers of wildly varying skills, motivation, and temperament to work together to produce a product on time and satisfy the requirements.
What kinds of language features would make management easier?
The first place to look at is a company’s “coding standards” document. Larger companies always find themselves compelled to write one. The language specification isn’t sufficient. Common things appear in those documents:
- Things considered to be “bad practices” to be avoided
- Standardized ways of doing things to enhance a common look and feel for company code and improve communication and sharing among the programming teams
- Checkboxes of things that must be delivered with code, like documentation and unit tests
If some of these could be put into the language, they could be mechanically enforced rather than manually, and this will save time and effort.
As an example of a bad practice to be avoided, the JSF C++ Coding Standards outlaw using the lower case ‘l’ suffix to indicate a long integer literal. The problem is that the ‘l’ looks like the numeral 1. ‘L’ should be used instead. In the D programming language, ‘l’ is simply disallowed as a suffix.
While bad practices are of course still possible in D, bad practices sometimes may be required to get the job done. Hence a number of red flags (such as casting) can still be done but have a syntax that stands out better. The red flags do stand out as red flags, and so can be more easily identified for further scrutiny in the code review process.
As an example of standardizing look and feel, consider the way debug versions of a program are built. Every group tends to develop their own style of this. For C code, I’ve seen endless variations on #ifdef DEBUG, some better, some worse, most are the same only different. It’s a case of too many different ways of doing something, with none clearly better than the others.
This inspired the debug conditional constructs in the D programming language. Technically, the debug conditional is redundant with the version conditional. What it offers, however, is a standardized way to build debug versions of the code. It works well enough that it removes the incentive to invent yet another group specific scheme. The management of it is reduced to simply a requirement to use the builtin debug conditionals.
Checkbox requirements are aided by being able to insert documentation, unit tests, invariants, etc., directly into the code with dedicated D language constructs. Of course, no compiler could ever ensure that documentation is thorough or well written, or that unit tests actually cover the territory. But experience has shown that the simple requirement that they exist in the source code dramatically improves the utility of them and focusses the responsibility for them where it belongs — the programmer. Documentation can no longer be “thrown over the wall” at the tech writers, and unit tests can no longer be shirked and dumped on the QA department. The mere fact that documentation, unit tests, and invariants exist in the D language has raised the bar across the board on expectations of what constitutes quality D code.
I think that language features to facilitate program management is a largely unexplored topic (nobody wants the legacy of COBOL to splash on their shoes), and I’d like to hear your opinions and anecdotes on it.