Comment by jvanenk | Hacker News Reader

Comment by jvanenk | Hacker News Reader

Parent Full thread

> Overall though, I think the most important thing is to have skilled developers who understand the tools, libraries and languages that they're using.

I work with C every day as an embedded developer. I've done a lot of safety critical work. By far the worst aspect of safety critical development is the complete inadequacy of many programmers who work on it.

The level of complexity that shows up in these system scares me. Even when introducing languages like Ada, people find a way to abuse them. Budgets get tight, schedules slip, and verification gets lax. These programmers are then the only people capable of dealing with the massively complex system they've built and the cycle repeats itself.

Ada's a great language, but it's not a panacea. I'm working on a language for embedded systems as well, but it's not going to ever fix the 'bad programmer' problem. The best I can hope to do is find ways to reduce the complexity of these systems through language features.

> The level of complexity that shows up in these system scares me. Even when introducing languages like Ada, people find a way to abuse them. Budgets get tight, schedules slip, and verification gets lax.

That is the absolute major issue with doing safety-critical development right: it has a cost, that cost is very, very high, and few want to pay it.

One of the few groups I'm aware of which does pay it is the (now defunct, I guess) software shuttle group. Their work was expensive, it was process-heavy (the 1997 story on them quoted 2500 pages of spec for GPS integration which ended up totaling 6.3kloc change to the source, 1.5% of it) but they delivered exactly what they were set to: critically safe code (in fact, if I remember correctly the Shuttle software group is the only area of NASA Feynman praised in his Challenger report)

> That is the absolute major issue with doing safety-critical development right: it has a cost, that cost is very, very high, and few want to pay it.

This is absolutely true. The costs to manage complexity now seem high when software is being built. The costs of managing that complexity in the future are far higher and may have to be paid in lives.

I wonder whether it would be possible to make a lint-like verifier which rejected code whose local complexity exceeded some objective thresholds. I imagine it would be pretty easy to come up with an objective measure of pure control flow complexity, but the complexity of interactions between control and data would be harder to quantify.

Interesting idea. Instead of aiming for something hard and true, you can probably find a good proxy of complexity fairly easily. Once you have it, just don't confuse the map with the territory; but use it as a hint to see what code to investigate.

Global complexity might not be much harder to measure than local complexity, perhaps even easier. Look for interdependencies.

At work I set up one of our project's automated build to fail if the cyclomatic complexity of a method exceeds 20. It's a C#/.NET project so we use NCover as part of the automated build. NCover has a reporting tool that you can set to return a non-zero return value (which will fail most build systems) if it's metrics exceed some value -- in this case class-level cyclomatic complexity exceeding 20.

I've thought about ratcheting it down to 15 based on stuff I've read, but unfortunately that particular failure metric can only be set as low as the class-level in the latest version. The next version (4.0) will have the ability to set the threshold at the method level.

In any case, I'd rather have a handful of places in the code where someone has to do something goofy to work around that metric rather than accidentally allow the whole project's complexity to creep up as time goes on.

> At work I set up one of our project's automated build to fail if the cyclomatic complexity of a method exceeds 20.

Are your co-workers cool with that? Complexity metrics are a little "squishy", but the costs of a broken build are large.

There's the 'pmccabe' tool, which can check for # of lines of functions and their cyclomatic complexity.

Then,

  pmccabe `find . -name '*.c'` | sort -nr | awk '($1 > 10)'

gives me all functions that have a cyclomatic complexity over 10; I often add it as a target in a Makefile, so I can easily check this. Similar, for functions of a certain length.

Tools for measuring code "complexity" already exist. Cyclomatic Complexity is a popular metric:

https://en.wikipedia.org/wiki/Cyclomatic_complexity

checkstyle is a Java lint that, among other things, can check code complexity:

http://checkstyle.sourceforge.net/config_metrics.html

Reply on news.ycombinator.com