Channels ▼

Walter Bright

Dr. Dobb's Bloggers

Language Features for Management

July 14, 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:

  1. Things considered to be "bad practices" to be avoided
  2. Standardized ways of doing things to enhance a common look and feel
    for company code and improve communication and sharing among the programming teams
  3. 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.


Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.