Monthly Archives: February 2009

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.