Interesting article on static analysis tools to help find concurrency issues.  These so called “Parallel Lint” tools are specific to finding these types of issues.  Overall there are some great discussions on certain tools, and it is always nice when Klocwork gets mentioned.  But my problem is with the categorization of these tools.  It always makes me feel sick every time someone puts Klocwork in the same category of “powerful static analysis” with JLint, C++Test, FXCop and my favorite PC-Lint.

This is a point I feel keeps getting lost with modern static analysis tools today.  Forget the Lint of the past or these other tools, their focus is on file by file analysis.  These old tools are doing simple grep type analysis.  Sometimes where you’re lucky you get a little bit of control flow with a dash of data flow analysis.  But plainly they are missing the deep inter-procedural analysis and techniques that are used with modern static analysis tools today.  I’m hoping the message is getting out there that static source code analysis is far far beyond Lint and is providing the context you never had before.

Don’t get me wrong, I’m a big fan of open source, but why does everything have to be black and white? If it’s closed it must be evil and by association probably not written well, whereas if it’s open, it’s awesome and godly in its unnatural power to cure world hunger?

I’m referring, in this particular instance, to the righteous indignation that surfaced as a result of the castigation served up for the manufacturers of that ever-popular device, the breathalyzer. And yes, I’ve been stood at the side of the road looking stupidly at the officer whilst trying to remember just why I thought that 15^th shot of Jaeger was such a good idea, but I digress…

The manufacturer of this particular device, the Draeger Alcotest 7110 MKIII-C, had claimed vociferously that their device worked correctly, that their code was a part of their device, therefore proprietary, and not available to opposing council for analysis. Unfortunately for them, the courts disagreed and ordered the code handed over for analysis by Base One Technologies (who appear to be nothing more or less than your typical minority owned GSA hand-out specialists – your taxes at work, people…).

And what did they find? That far from being the highly skilled work of a bunch of Ph.D.’s that might warrant being labeled proprietary and top secret, it was instead a bunch of off-the-shelf engineering that had obviously been through many different iterations of development, through several different iterations of design, and wasn’t, bottom line, particularly smart. Nor was it particularly accurate, of course, which was the real hummer.

But come on, how many of us work on code (proprietary or open) that we can claim hand-on-heart hasn’t strayed from initial design goals?

Lest I now be pilloried for standing up for sub-par, closed (evil! evil!) source code, let me quickly segue onto the meme that is most aggravating me in relation to this story. And let me also quickly say for the record that anybody producing a breathalyzer that isn’t accurate needs stoning and feeding to the wolves, that much goes without saying. Back to the topic at hand…

So, Base One found a whole host of noxious practices and poorly executed designs in this particular code base. Not least, of course, being the afore-mentioned inaccuracies. But it did so in a very dry, engineering-centric sort of way that obviously wasn’t intended to pander to the pitchfork waving bigots, and so the ever helpful popular press took it upon themselves to take the one big number (ooo, shiny!) from the report, take it out of context (but of course), and then to label all closed source as bad by association.

• 19,400 potential errors in the code!!!

That’s obviously easier to get your editor interested in than a bunch of boring technical detail, like what was actually wrong with the device. 19. Thousand. Errors. Come on people, that’s a big number, amirite? Three out of every five lines of code contains a potential error. Sky. Falling. Must. Grab. Pitchfork!

But let’s read the small print here (or actually, not small at all, in fact it was right in the original report, but again wasn’t exciting enough to repeat): that number comes from an analysis performed using lint. You know, the tool that emits 400 errors for every 200 characters of input? You know you miss the days of 2,400 baud terminals that actually couldn’t keep up with the rate of error emission from this thing and just turned the whole screen into a weird whoosh of green CRT rays, don’t you?

Oh, but if only it was open source, goes the meme, the world (or at least that part of it which finds itself staring stupidly at the officer by the side of the road) would be a much better place. At least, that’s what we’re encouraged to believe.

Anybody tried lint on an open source project of any renown recently? I have (I won’t name them, not because it’d be embarrassing, but because it’s kind of irrelevant). Frankly it’s almost impossible to find a project that doesn’t emit thousands of lint warnings. Let’s face it, if you can write code that doesn’t emit lint warnings, you’re spending time in that happy place I like to call Hello World.

Come on people, wake up. There are very good reasons to hate bad software, whether it’s closed or open. Don’t be a schmuck and jump on the religious bandwagon just because it’s there. Think for yourself. There’s very good reasons why this device was castigated as a piece of junk, and they had nothing whatsoever to do with that big shiny number. If you’re going to report on something technical, do your readers the favor of at least trying to understand what you’re talking about before you go balls out into meme land.

Just returned from ESC San Jose, where I spent a very enjoyable few days surrounded by the “real men” of the programming world. Forget your managed language environments, forget abstractions or object oriented fantasies of design, forget processes like Agile, these guys spend their days down at board level working in assembler and occasionally sticking their heads up into the rarified world of C (but only, you know, for stuff that doesn’t really matter…).

Hell, most of the time the hardware they’re programming is custom built just for that project, sans O/S because, you know, why would you want that crap to get in your way. One guy that stands out in the procession of awesomeness was describing his ASIC to me, asking if we could help with stack overflow problems, and launched into a necessarily abstracted description of the fact that their (classified) device didn’t really have a stack, actually, but it was kind of a well known address range that they normally treated like a stack, although not always because, you know, stuff sometimes gets in the way, so if he, like, stuck something in there that was too big, could we tell him?

God, I love these guys…

Now I began programming on boards in Z80 assembler, so trust me that I do actually know what the heck they’re doing and why, but over time I’ve followed what has felt like a fairly natural migration away from the kind of “if I want to light up that LED I have to store 0x2d in address ‘x’” programming to C, then C++, and more recently to Java and C#. Of them all, I think C++ is probably my favorite, simply because it’s low-level enough to be useful, and high-level enough to let me express myself without having to think too much about it. Frankly, in my opinion while good developers are good in any language, really good developers find their own way and then excel at it. So yes, I can probably program in any language given a few days of spin-up time, but frankly I’m too old and too cranky to get all fired up over the latest innovation of hiding-the-useful-stuff-from-me just so I can do it a bit faster.

Note that I’m not espousing any kind of intelligentsia-sponsored BS argument over the “value” of OO languages over procedural or vice versa (for more vitriol than typically fits on one page, check out this beauty from Torvalds…). And no, I don’t use STL so just shoot me, but it sucks so get over it. And if you get your rocks off over Python or Ruby or Haskell or whatever new lambda calculus-based micro language you’ve just stumbled over, have fun and get your job done, there’s enough of them for everybody, after all.

But don’t try to convert me. Proselytizing is always ugly, so just step away from the bong and let’s all be friends here. The Urban Dictionary nicely summarizes things:

The men who program in C++ are Real Men. The women who program in C++ are Real Men too.

Substitute the name of your favorite language in there in place of C++ and you’ve got the way most developers think about their own language of choice. How about you? Any favorites out there you’re willing to get boiled in the pot for?

As software managers you’re undoubtedly being asked to do more with less in this economy. With companies continuously being forced to cut costs, the first shoe to drop is when you are told you need to cut headcount.

The second shoe drops the day after the painful deed is done and you look into the eyes of the team members that are left behind and try to put a positive spin on your world – their world. And that is when reality really hits home.  Less people, same number of problems.  No one “downsized” the backlog of customer requests, the bugs, the schedule expectations or the previous team’s workload.

At this point two groups form; the group of managers that simply puts their head down and grinds it out until things turn around (hoping things don’t get worse…which is really a do nothing strategy and those rarely work)…or the group that decides to be bold and innovative.  The natural inclination is to say the latter approach is too risky but in reality it is actually less risky, just more visible and more likely to be positively received by your team and your management.

The dev organizations best positioned to come out of this economic downturn stronger, are the ones with dev leaders that are focused on how to do things differently.  Agile development and further process automation with advanced tools become the mechanism to strongly position these dev teams for the better days ahead.  Why? Because just like every bubble, every downturn eventually ends.  As a dev manager, your real focus needs to be on what you want your team and your company to look like coming out of the downturn – heads down, battered and bruised but glad to be alive -  or lean and mean supported by a finely automated dev infrastructure and ready to capitalize on new opportunities.

By focusing on new approaches and automation, you  are helping your team feel they can get in front of the workload they have been presented with during these very challenging economic times. Automation is critical.  Tools such as continuous integration, refactoring, and code analysis all help eliminate wasteful, demoralizing “redo’s” of stupid mistakes they probably would not have made if they were not so maxed out, or if they were more familiar with the latest project you had no choice but to drop on their lap.  They see a way to spend more time on interesting, and challenging, innovation rather than just constant debugging.

“Hunker down” seems to be the mantra of our times, but “hunker down smart” and you and your team will be more readily positioned for the better days ahead.

Many of us have seen the # of lines of code (LOC) stats that get thrown around as a metric for illustrating how complex software development has become:

• The U.S. Army’s Future Combat System is estimated at 60 million lines of code (MLOC)
• The software that runs the Boeing 787 is almost 7 MLOC, triple that of the 777
• GM says future cars will have >100 MLOC (that sounds high, but hey, <insert GM joke here>)

So, yes there’s a lot of code out there, it’s growing, and it’s getting more complex. It’s tough to put these numbers into perspective… Jack Ganssle has a clever column that does just that:

• A million lines of code printed out would be 18,000 pages
• A million lines of code will typically have 100,000 bugs pre-test
• A million lines of code costs $20m to $40m

I won’t try to compete with Jack on the stats front since that column speaks for itself, and it’s not just the mission/safety critical systems that are trying to deal with the challenges of more code, more complexity, and less time (as in time-to-market). The consumer market is no different. Guess how much code is in the Xbox HD DVD Player? Not the whole system, just the player? 4.7 MLOC. Heck, you could fly an airplane with all that code (hopefully most of it can also be re-used on a non-obsolete disc format). Just as a point of comparison to today’s gaming systems, ask yourself how many software engineers worked on this “game system”:

Yes, I had to throw Digital Derby under the bus didn’t I? Not because I don’t have fond memories of playing this game that was about the size of carry-on luggage. In fact, I played it until the poor little conveyor belt just stopped working and I put up with the, ahem, limitations in the technology. I was actually quite patient (more patient than I am now with technology) and gave my little Digital Derby second and third chances to work properly.

More code, more complexity, impatient customers, and very little margin for error – these are the trends that are driving tool and process automation across the board in the SDLC.