Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm working at a company that would score 11 on Joel Test - at least on paper.

In practice, however, nothing works quite as well as expected, and the project has been on DEFCON 1 for half a year. Now, most of my peers are happy if they can go back home at 6pm - on Sunday.

One of the apparently good practices that struck me as not working is the use of static analysis tools. The project both tracks gcc -Wall warnings and a proprietary and very expensive "C/C++" tool.

Gcc warnings do more often than not point to real(if most of the time inoffensive) bugs.

The proprietary tools, however, list things such as implicit casts and sizeof'ing a string literal. Implicit casts are also blacklisted on their stylebook.

The standard practice is that people is pressed to make every single warning shut up. Note that this does exclude warnings that are predominantly false positives, this is not the problem.

The result is:

  1. People add type casts to every rvalue and to every argument hiding real problematic type mismatches in the process.
  2. People introduce off by one bugs, or use a different problematic language feature.(strlen instead of sizeof, strncpy instead of strcpy, etc.)
  3. The warnings are silenced.
  4. The bug reports start rolling in.

The main point is the original code was working and written by people who were playing safe within their language abilities whereas the fixes were not.

Now, I don't really think this company can be saved. However, I would like to know if there is a better, preferably working, way to use the "pro" tools or if I should just avoid using them altogether in case I am the one making the decision in the future.

A solution which doesn't assume all programmers are geniuses that can't err. Because well, if they are, then there is no need to use the tools in the first place.

share|improve this question
add comment

5 Answers

In practice, however, nothing works quite as well as expected, and the project has been on DEFCON 1 for half a year. Now, most of my peers are happy if they can go back home at 6pm - on Sunday.

This is certainly a good chunk of your problem. A software engineer cannot work productively for more than 40hours/week. If you go above that, you do serious damage to your capacity to work- to the point at which even working 80 hours/week brings very little of value to the project, and sometimes, projects can even regress because the team introduces more errors than they can fix. If you've been doing 60 hours/week or more for half a year, then your whole team needs a good long break, and to come back at 40hours/week. You can't solve anything with a workforce that's hardly capable of bashing on the keyboard because they're so overworked.

The proprietary tools, however, list things such as implicit casts and sizeof'ing a string literal. Implicit casts are also blacklisted on their stylebook.

You really need to either just drop the tool entirely, or reconfigure/replace it. Warning on every implicit cast is far too much for anyone to deal with.

share|improve this answer
    
Could you please provide a reference to a research about 40 hours a week limit? –  user11408 Jul 28 '12 at 4:39
4  
here and here, just for starters. It's extremely well documented that you cannot do more than 40 hours a week of productive work. A simple Google will find you reams of articles. –  DeadMG Jul 28 '12 at 4:50
1  
Two small, but IMHO important corrections: the 40 hours/week limit is an approximate average value, and the rule only applies for prolonged periods of time. It is OK for a team to put in extra hours before an important deadline, then recover afterwards (maybe even taking some days off). Also, the limit varies between people and over time - some can work 43 hours per week without problems, others only 35, and one is more productive on some weeks than others. However, putting in significant overtime for more than a couple of weeks in a row is indeed going to cause serious trouble. –  Péter Török Jul 28 '12 at 14:01
add comment

It is not clear whether you are asking how to fix the problem, or how you could have avoided it in the first place. I'm assuming the latter.

It sounds like you have been relying on static analysis as your primary means of detecting and avoiding bugs. Maybe you would have been better off focussing more on unit tests, and dynamic tools ... such as memory checkers.

It is a bad idea to rely on a tool that generates lots of false positives, especially if you can't suppress those false positives. It encourages tired / overworked (or lazy) programmers to make "fixes" to make the warnings go away. If you can't selectively suppress false positives (e.g. with comments) or tailor the ruleset, then you need a better tool. Or at least, you should only use it sparingly.

It sounds like you have a problem with people being careless and / or making mistakes due to overwork. Maybe you should have spent more time / effort in code reviews. This directly addresses your observation that programmers are not geniuses.

Finally, it sounds like you may have been suffering under unrealistic deadlines, poor people resourcing and / or shifting requirements. This is a management problem, and has to be addressed at that level ... or else there is a significantly elevated risk of project failure, and long-term damage to staff productivity and morale.

share|improve this answer
add comment

I'm working at a company that would score 11 on Joel Test - at least on paper.

That test is just mildly relevant to software companies. I don't understand the hype about it. You can score 12 and still have 100% crap programmers. People matter far more than tools.

The proprietary tools, however, list things such as implicit casts and sizeof'ing a string literal. Implicit casts are also blacklisted on their stylebook. The standard practice is that people is pressed to make every single warning shut up. Note that this does exclude warnings that are predominantly false positives, this is not the problem.

This is the largest problem with all static analysers: too many false positives. The only way to handle this is to learn in detail why the tool was set to give a warning for a certain issue. Only then can you make qualified assumptions of whether a warning is false or not.

For the specific cast of implicit typecasts, it is there because of some very common, subtle and dangerous bugs in the C language, caused by the two (moronic) implicit type promotion rules in C. They are formally known as the integer promotion rules and the usual arithmetic conversions. I think less than one in ten of all professional C programmers can explain what these two rules do, and what they don't do. And yet these rules are extremely fundamental and applied thousands of times between the lines in any normal C program.

The MISRA-C standard devoted a whole chapter to explain these dangerous implicit conversion rules, and then they added numerous fairly complex rules for how to avoid bugs caused by implicit conversion. This had quite some impact on all static analysers in the market.

I would recommend any C programmer to read that MISRA-C chapter, or at the very least Google the two promotion rules I mentioned and read as much about them as you can. You can only ignore the static analyser when you know everything there is to know about these rules.

Now, I don't really think this company can be saved. However, I would like to know if there is a better, preferably working, way to use the "pro" tools or if I should just avoid using them altogether in case I am the one making the decision in the future.

A solution which doesn't assume all programmers are geniuses that can't err. Because well, if they are, then there is no need to use the tools in the first place.

There is no easy way around it. The real problem is actually not the tool, but the obscure C language. It may seem to be an easy language at a brief glance, but there are plenty of illogical and strange mechanisms going on between the lines. And there are also hundreds of cases of undefined/unspecified/impl.specific behavior in the language. Most of them you must learn and avoid.

So you must either become a veteran C programmer that understands all these obscure warnings, or you must be in a team with at least one such person. Companies that only hire a bunch of junior programmers with no veteran in the team should not use these tools, nor should they work with high-integrity software development.

share|improve this answer
    
I took the test with a pinch of salt from the beginning, but it is not a tool to test programmers but a tool to test employers. I guess you could include apt coworkers as "best tools money can pay". And I take your answer to be throw the SA tools away, and hire and/or train better. The former point seems to be the common denominator. –  qpr Aug 9 '12 at 23:07
    
@qpr It doesn't test the employer either, just the employer's willingness to spend money on software development. Things like recruitment procedure, corporate goals, market knowledge etc etc are not mentioned. I think most "IT bubble" companies would score 12 on that test, with a management that doesn't even know what products that are being developed or if there is any market for them at all. –  user29079 Aug 10 '12 at 6:09
add comment

I'd say (without knowing the details) that your company has made more significant mistakes and this is just the symptom: it failed to properly determine the domain of the software produced, to manage the team properly and to define reasonable goals.

If the software your team is writing is something critical that human lives depend on, static analysis tools are important and useful. Since the "cost" of a bug, measured in money (ignoring how cynical that is) is high, there are special tools required for the job. There are guidelines for both C and C++ for safely using the language features (read what to avoid and how far to go in avoiding it).
However, in such a situation having employees work on Sunday is a very bad idea, moreover from the context you've provided, I extrapolate that sloppy work is not infrequent. So if this is the case, the problem is very very big, and your management is trying to solve it by using "better" tools. Unfortunately, that's not how things work. If I'm even close to correct, I'd go as far as suggesting that you start looking for a different job. Mission-critical software done bad is something that can haunt you and ruin your professional reputation, not to mention lawsuit prospects.

If, on the other hand, your team is writing something that is far less critical, 'static analysis' tools with a high false-positive rate will only slow you down, and, as you've noted, people usually react to this by finding the local maximum in their effectiveness, in this case by simply cheating their way around the warnings, instead of trying to fix the underlying reason. So in your situation, using these tools may actually deteriorate the quality of the source code, and they should generally be avoided.

If you need to manage a software team that is writing some C or C++ code, I'd say first determine what are the main project goals. If writing bug-free code is of utmost importance (e.g., the new super awesome social app for iOS and Android doesn't fit this), then use static analysis, maybe even go as far as formal specification and formal verification. But if this is the case, choosing good programmers and having them work in a sane environment with adequate workload and proper 40 hour week is far more important.

People cannot work responsibly if they're treated like slaves (and someone occupying my holidays is exactly this) and good programmers will simply refuse to do this on a regular basis, unless they know no better (and if they're good, chances are they do).

Bottom point: Figure your goals, then determine the tools and the process you use, don't let the available tools define the process (ergo the goals) as (bad) management might want to force you.

share|improve this answer
add comment

As stated in k.steff's answer, static analysis tools for 'C' are useful if you are building software in critical situation (airplane software) and they must be used from day one (not after months of development when a un-reproducible bug occurs).

Using these kinds of tools late in the development process is usually a sign of bad design choices early in the process.

In non-critical software, these kinds of tools are useful to:
-reassure management, make them feel useful (we have done something, we have spent a lot of money to fix the software). It gives them actions that are easy to fulfill in their powerpoint reportings).
-Keep the 'toxic' developers busy. Let them configure the tool and analyze the tool results, so that you can have time to fix their nasty bugs.
-enforce coding rules. In that case it must be used from day one. But a good code review tool may be better choice.

So my opinion is you must avoid these kinds of expensive, time-consuming tools or use them to keep the 'toxic' people busy.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.