const static or static const or what?

This issue crops up time and again: somebody looks at code like this:

and complains loudly that this was not legal C code: “static”, he screams, “must come before const”:

I’ve never had a compiler that generated wrong code from the first version. I guess this myth is nourished by the fact that GCC and PC-Lint issue odd warnings when confronted with const-first declarations:

(PC-Lint’s warning message is particularly weird, isn’t it?)
Both tools process the second version without any complaint.

I really don’t know where this rumor comes from. Maybe it was true in K&R C, but C++98 and C99 certainly don’t care about the order of qualifiers — they don’t even care about the position of the type!

is perfectly legal, but

still complains like before (at least when using the -Wall -W combination; -Wall alone doesn’t produce this warning).

The C99 grammar (see 6.7 Declarations) clearly says:

so the order obviously doesn’t matter.

Personally, I prefer the first version, because the fact that a variable is a constant is more important to me than its scope. Still, it is probably wiser to use the second version: not because the first one is ill-formed, but because of misbehaving compilers and static analysis tools.

[update 2009-05-20: Christian Hujer found the missing link: chapter 6.11. (“Future Language Directions”) of the ISO C99 standard clearly says:

“The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.”

There you have it. Forget my crazy preferences, write future-proof code by following the standard’s advice. – end update]

Internal Developer Turnover

Everyone is familiar with the term ‘staff turnover’: it is the number of people leaving a company in a year divided by the total number of employees in that year.

It is also common wisdom that high turnover rates in development shops are an indication that something is going wrong. Maybe people have to work long hours far too often, the money is poor compared to competitors or the boss beats up developers for checking in bugs. Who knows…

This classic definition of turnover does not show when people, who were once hired as developers, voluntarily move to jobs — within the same company — where they don’t write code anymore.

To me, such developers are also lost, much like they would have quit the company completely. This common phenomenon can give a more subtle insight into what exactly is going wrong within a company.

Why do developers leave their developing jobs but decide to stay within the company? It is quite obvious that the company can’t be so bad after all — otherwise they would have gone elsewhere. I think that there are two chief reasons for this internal developer drain: either there is something wrong with the hiring process or there is no career path for developers, or both.

If there is something wrong with the hiring process, a company will employ developers who aren’t really developers; that is, they only do coding because they wouldn’t know how to make money otherwise. Sooner or later, they get bored (or frustrated) or bullied by peer developers who are fed up with cleaning up after them. So they decide to work as ‘requirements engineers’, ‘project leads’ or join the marketing department.

A missing (technical) career path for developers means that if developers want to get more money (to raise a family, for instance) or responsibility, they have to follow the only career path available. Often this means that they are ‘forced’ to do a job that they don’t particularly like and that they never learned to do properly — a clear manifestation of the well-known “Peter Principle”.

These two sources of internal turnover are an indication that a software company is in serious trouble; they are typically found in companies with a traditional (non-software) background. Such companies were once successful in a certain technology which has been been replaced or heavily augmented by software. Their processes that worked so well in the past don’t work anymore…

It is very hard to establish a software culture in these traditional companies because a) the top management doesn’t understand the problem at all and b) the middle management is afraid of change — change that might ultimately have a negative impact on their own career.

TODO or not TODO

Are TODOs in source code good or evil?

In my view, TODOs are a tool and like any tool, it can be misused. I do agree with most of the critism but if they are used with care and if they are actively managed they can improve productivity.

Sure, TODOs tend to accumulate and, yes, there are selfish developers who use them to acquit themselves from checking in sloppy code (which they will never clean-up). Yet, there are situations where they are appropriate.

Sometimes it just makes sense to check-in code that is not 100% done. For instance, if all of your requirements are not settled yet or you are uncertain about some boundary cases. Here is my litmus test: if your unfinished code already provides value to somebody else and it doesn’t break existing tests it is OK to check it in. Be it a tester who needs a running system to develop test cases against or a coder who needs your class to continue her work. Maybe it’s a sales person who needs a quick tentative solution for his trade show. Unfinished code is especially appreciated in the ‘bazaar’ software development model.

If you accept the notion that unfinished code is useful if it already provides value, you probably also agree that it is not a good idea to keep the list of open issues in your head; even scrap paper is only slightly better. To me, it is much better to record ‘tentativeness’ very close to the code.

However, it is essential to manage those TODOs — if you don’t manage them, they will eat you alive.

In order to manage you need to track, and tracking is much easier if your TODOs follow a standardized format. Once you have a standardized format you can easily extract metrics. If everybody used their own style of TODOs it would be very hard to control them. A mix of TODO, FIXME, BUGBUG, ???, ### is TODO hell.

After years of experimenting, I’ve found this style of TODO comments to be the best:

Let me briefly describe why I consider this format to be superior.

First of all, it starts with ‘TODO’ in all capital letters, which is good, as it is recognized by many editors/IDEs and highlighted in a special manner. This makes it easy to recognize TODOs for human beings when browsing source code.

Next comes the date in ISO 8601 ‘extended’ format. Not only does this tell you when the TODO was added: it allows you to easily sort your TODOs:

The sorted output will show you which TODOs have been around for a long time, maybe for too long a time.

After the ISO date comes the name of the TODO owner. I suggest you use login names, but it doesn’t really matter as long as it is unique and can be easily mapped to a real person’s name. Due to the fact that the name is surrounded by colons you can build a list showing who owns the most TODOs:

Finally, there is a brief summary that describes the reason for the TODO; if necessary, additional text follows on the next lines. Describing a TODO is essential: it tells developers why it is there; leaving it out is akin to putting up a ‘Watch out’ warning sign without giving any additional clues.

In order to extract information automatically, the standardized format must be enforced. This grep command will catch most ill-formed TODOs:

In addition to pinpointing typical TODO comment keywords it ensures that the date is well-formed and that the owner and description fields are not omitted.

Ideally, you run such scripts automatically every time a developer checks-in changes. If you don’t have testbots you should at least run them as part of your daily build procedure. In case you don’t even have daily builds (pity you!) it is the job of the project lead to execute them regularly.

TODOs are useful for modern, release-early-and-often software development processes; by standardizing their format, all of the common disadvantages can be overcome. If you don’t use them yet, I suggest you put them near the top of your TODO list.

Tools I Carry

I recently wrote about the most important tools of a software developer. The tools that I mentioned are important to be a successful developer — they are not sufficient to master the other challenges of life.

Being the geek that I am, I carry all sorts of things in my pockets — things I couldn’t live without. Today, I’ll do a headstand and show you what I’ve got.

First of all, there is my swiss army knife. I need it for all kinds of situations: tightening screws, cutting of loose threads on clothing, opening bottles. Last spring we went on a hiking trip and my son got bitten by a tick — I used my knife’s tweezers to pull it out. It’s amazing: once you carry a swiss army knife, all kinds of occasions arise to use it and you wonder how you could have survived so far without it.

But I had to make a trade-off: naturally, I wish to have as many functions on my knife as possible: many screwdrivers of different shapes and sizes, a magnifier, scissors; and it should have a big blade such that its possible to cut off a slice of bread from a big loaf. All of this is available from Victorinox and Wenger (they even have knives that come with LED lights and USB memory). Alas, there is only limited space in my pockets! I certainly don’t want to carry a brick around. After years of experimenting with various models, for me, the Wenger “Evolution 10” is the best compromise. Always remember: the best knife is the one that you have on you; a 30+ function knife is of no use if it’s left in your cupboard.

I also need to have a pen on me. Not just an ordinary five cent plastic giveaway pen that might leak ink or run dry. Typically, those pens are also too big to carry them in your pants pockets (I rarely wear shirts, so all my tools need to be placed in my pants pockets). I prefer the famous Fisher ‘Bullet’ Space Pen. This pen is just so cool, so small, so sleek, so robust, so timeless. It comes with a special pressurized ink cartridge that allows you to even write up-side-down — on wet paper, if necessary.

Speaking of paper: a pen — even a Fisher Space Pen — is of little use without paper (unless you are willing to write on your palm or the back of your hand, something I do only in extreme situations). I’m a big fan of Moleskine notebooks and I would love to have one available everywhere I am. Unfortunately, even the small version is too big and heavy to carry in a shirt or pants pocket. By contrast, my ’emergency notebook’ is quite lightweight: a folded A6 index card, which gives me four pages of about 10 cm x 7.5 cm. It’s not much — but it is something!

Whether there is something to fix or an idea to be jotted down, with my tools I can rise to the occasion; I wouldn’t even think about leaving my house without them.

Reply To All

It simply had to happen again: an unfortunate coworker responded to a department Christmas party invitation, but instead of selecting “Reply” he accidentally chose “Reply to All”. Now 200 people not only know that he will join but also what particular meal he prefers.

Not a big deal, you think?

Years ago, I was on a team facing schedule problems. Our team lead sent an email to our sales manager trying to explain the technical difficulties that we were facing; the whole development and sales team was on the “CC” list. One of the developers replied to the team lead, indicating that a person like our sales manager would never understand our technical problems.

Well, he didn’t use the exact same words that I just used; in fact, he used quite different, actually, rather — ahem — colorful words to express his feelings about the technical abilities of our sales manager. And — you guessed it — he inadvertently clicked on “Reply to All”.

In my view, the one who really is to blame when something happens like this is the company that develops such bad user interfaces. Actually, I don’t know a single mail client that has some level of protection against such embarrassing scenarios.

Here is my solution: When the user selects “Reply To All” change the color of the background to red (or make a beep or some other noticeable change to the look and feel); most importantly, replace the text of the “Send” button with “Send to All”.

Advanced Programming

Today, Hartmut, a colleague, showed me some code written by one of his teammates. He found the code to be very confusing — in fact, he was quite upset about it and the author — and asked me whether I had ever seen tricky code like this.

Oh well, oh well, I had. In fact, I was the one who introduced this particular technique to the author and recommended using it.

Years ago, I had a similar problem on a C++ project. My teammates were not really experienced C++ developers and didn’t know much about templates. As a matter of fact, I like templates and if used with care, they can make the code more readable and maintainable.

But this was just my view — the view of the rest of the team was, well, quite different.

I was shocked and disappointed. I thought I had written great code, but my ignorant colleagues didn’t like it — they didn’t even bother to learn about advanced C++ topics!

Hartmut argued that I’m allowed to use any advanced feature or technique I want as long as the rest of the team understands it. Not satisfied with his advice I countered by explaining that I didn’t want to drive a Ferrari by only using first gear. Hartmut’s response was a complete revelation: “Then”, he said “you have to teach them how to drive a Ferrari using all gears”.

Let me summarize this as ‘Hartmut’s Law of Advanced Programming’:

“You may only use an advanced programming language feature or technique if the rest of the team understands it; if this is not the case and you still want to use it, you have to educate them about it.”