So it’s that time again, when our team finally gets to sleep for a day or two and get their lives back in order. What am I talking about?

Answer: Klocwork Insight 9.5 releases today and boy are we ever happy to see it go live — we’re “out there Jerry” and yes, of course we’re loving every minute of it.

This has been a long release, taking significant research and development to bring to fruition, all the while continuing to release more traditional shipments as we went, but finally culminating in a new, game-changing technology for source code analysis. On-the-fly, as-you-type, instant-like-for-reals, call it what you like… full-on, in-depth C/C++ analysis performed as the developer enters their code, using the “squiggly line” usability metaphor created by spell checkers. It’s one of those “why would you do it any other way” moments and we’re happy to be unique.

Not to be outdone, our web tools team has done amazing stuff with a complete redesign of our Review and Inspect tools, showcasing an awesome look and feel that leverages the toys that come with HTML5 and, amongst many other new capabilities, brings drag/drop pivot report design to the web for on-the-fly metrics and trending analysis that managers and development leads will just eat up.

To our customers, our partners and our friends in the industry, we’d like to say Welcome to Insight 9.5, hope you enjoy it.

Creating a source code analysis (SCA) engine is a balancing act, a decision process of where you believe the most value can be found along the spectrum that is the signal-to-noise ratio of the detection process. At one end lies the realm of massive noise and hopefully complete coverage, whilst at the other is the quiet calm of the theoretically useful but ultimately useless realm of no noise, but ultimately no signal either.

That may sound counter-intuitive. Shouldn’t a zero noise point on the spectrum be accompanied by an infinitely strong signal? Perhaps in the world of DSP this is true, but in the world of SCA reducing noise comes right along with a reduction in detection capability – it’s unfortunately almost a straight-line correlation.

So if we assume that we’re trying to balance a couple of dials on our theoretical tuner, we might start by reducing or dampening noise – it’s the most obvious place to start, after all. Nobody likes to listen to their favorite FM station through the curtain of hissing and popping that accompanies the act of driving through a major city.  Likewise no developer likes sifting through a long list of bogus detection errors in order to find the hidden gems. But to drag out the analogy, assume that the only way of reducing hiss on your FM signal is to turn down the volume… now you’ve got less hiss, but also less Bruce Springsteen goodness to accompany it.

Balance is what we need here, obviously. Enough Boss to make us ignore the hiss, or to put it in a more SCA-like context, enough interesting bugs to make us ignore the incorrect, or the irrelevant (correct detections on the part of the engine that the developer just doesn’t care about, e.g. low memory conditions in a memory-insensitive environment).

Consider the following simple example that clearly lies “on the line”:

    void foo(char* s, int a)
    {
        char* s1 = s;
        if( a > 0 )
            *s1 = 'a';   // potentially use an uninitialized ‘s1’
    }

    void bar(int m)
    {
        char *s;
        foo(s, m);       // s is not initialized prior to calling ‘foo’
    }

So… to report, or not to report?

Lacking any other information, it is obvious that function ‘foo’ interacts under certain situations (when parameter ‘a’ is positive) with parameter ‘s’ (aliased as local variable ‘s1’). As we have no knowledge about the provenance of parameter ‘s’ when analyzing ‘foo’, however, there’s nothing here to cause a report and so we squirrel away the knowledge of what ‘foo’ does for later use.

When analyzing ‘bar’ we know what ‘foo’ does, and we know we’ve got an uninitialized local pointer, ‘s’. But again we’re lacking enough knowledge to know the valid values, or ranges, that parameter ‘m’ may take. There are definitely a set of circumstances here in which we know a problem will occur (if parameter ‘m’ is positive), and a set of circumstances in which we know a problem will not occur (if parameter ‘m’ is zero or negative) – this much is encoded in the functional behavior of ‘foo’. But is it a defect, or should we filter out the report in favor of providing only those situations in which we can be “sure” the bug not only exists, but can be proven to be exercised?

There’s the art of balance in a nut-shell, and it revolves around the phrase “lacking any other information.” In the ideal world, lacking any restrictions in terms of time, memory or computing power (or indeed actual from-the-wall power, as we have to worry about now), we might defer all such decisions until we categorically know that a particular data value is passed down the call graph far enough to get to ‘foo’. But in the real world of multi-million LOC projects, that approach simply can’t scale.

And so, calling on balance as our friend, we can bias a localized decision to report or not, given that we know to at least one order of approximation that bad things could happen here. Different engines pronounce that bias differently, leading to one of the greatest divides between prevalent solutions.

Now ask yourself, as the developer, is it a worthy report if you know that 10 levels up the call graph there’s a check on what eventually becomes parameter ‘m’ to ensure that it’s never positive? Perhaps you’d automatically classify this as a false positive and, annoyed at the tool, move onto the next report. Or perhaps, seeing the size of the gap in the call graph, you might just choose to code defensively, initializing ‘s’ to NULL in ‘bar’ and adding guard code to ‘foo’ because, hey, you never know.

And as we’ve all seen so many times over the years, “you never know” might just as well be written “and so it came to pass…”

There’s a tradition in R&D management that goes something like this: “give them toys and they’ll be happy.” Typically this has meant the biggest monitors, or the fastest CPUs, or an egregiously unnecessary SLI GPU configuration (for, ahem, high capacity computation tasks, right…), or whatever the latest piece of hardware might be that catches the purchasing manager’s eye.

But what about the software on that hardware? Sure, we equip people with an IDE (if they’ll use it, or whatever text editor they demand if they won’t) and whatever other tools are mandated as part of their development lifecycle. In fact, typical managers would dearly love to be able to mandate more tools for their developers. It’s easy, after all, for a manager to make the correlation that more toys = happy developer = more productivity = more code = bigger bonus = happy manager.

So why do so many developers, particularly in the embedded space, use outdated software tools? What’s the excuse, after all, for vi or some close derivative being a dominant code editor?

Inverse snobbery has been a popular theme in the privileged parts of the world for much of the last thirty years. “Yes, we drive a Lada because we just don’t believe that a BMW is necessary.” Really? Does anybody actually believe that tripe? I mean, I can well believe “I use vi because I have to; it’s the only editor that works on this cruddy piece of hardware.” But forgive me if I have a hard time with “I use vi because I like it better than anything else.” We all get used to stuff that makes no real sense, but surely there’s a point where even the most inverted technical snob has to look themselves in the mirror and know, deep in their darkest most hidden-away recesses of existential reality, that they’re just full of it.

Intransigence. Inertia. Feet dug in harder than you could possibly shift in a lifetime. Call it what you will, but unless something life-changing, like a project in a new language happens, many developers have a nasty habit of sticking with what they know. “What we do is hard enough,” goes the meme, “we don’t need to make it any worse.”

So how are those same developers coping with the demands of the ever-increasing footprint that is professional development? After all, it’s not enough anymore to simply bang out some code and check it in, moving on to the next assignment and hoping nobody notices. Now the professional developer is tasked with unit testing, performance testing, static analysis, memory profiling, code review, refactoring for maintenance, architectural cohesion, you name it. The list only ever gets longer as we move the goal posts for QA closer and closer to the consumer, requiring the developer to pick up the slack in the interim.

How does that footprint get coverage? There are still the same number of hours in the day, and the required amount of code generated by each developer hasn’t markedly decreased over the last 10 years. So what gives? One thing’s for sure… vi hasn’t made developer productivity much better than when it was first written at Berkley all those years ago (with all due deference to the strides made by vim/gvim in recent years).

I’m going to examine several different communities in upcoming posts and look at the approach they take to solving this problem, covering a range of backgrounds and roles from embedded driver writers to creators of modern web applications. In the meantime, have a look inside yourself and, if you pass muster as some analog of the crusty vi user I paint above, ask yourself why, and what might make you change. Recent history abounds with case studies, some of which I’ll reference, but at the end of the day it’s all about you and your personal work practice.

Part IV – Joy is in the eye of the beholder

In preceding posts on this topic, I’ve outlined the continuing shift from in-person, physical interactions as being the defining notion of both social and business contexts, towards virtual interactions and marketplaces, and the fact that in all aspects except the most personal the latter can fulfill everything expected of the former. But what does all this have to do with engendering a vibrant and successful code review practice within a development organization? On the face of it, nothing much. Code review, you could determine, tends to happen within organizations that enforce it, so all we need to do is to pass a rule requiring code review before shipment and we’re gold, right? I mean, what could go wrong?

Unfortunately the reality isn’t so clear cut. Most organizations worth their salt have a “requirement” for code review to be performed. At least on the important bits (a definition I particularly like, particularly when it comes to motivating programmers working on the “unimportant” bits). Or the hard bits (likewise). One awesome process description I saw in action recently called for the architects in the team to review each others’ code, but everybody else got a free ride – because obviously the code that our highest paid, most talented developers produce is the stuff we’re really worried about being wrong, amirite?

Despite such requirements, whether they make sense or not, the rarity of code review is out there for all to see. In fact, we recently sponsored the analysts at Forrester to produce a survey of code review practice in various different development environments (embedded, ISV, IT, etc.) and found that although most developers appear to believe that they live in organizations that do code review, most also claim that it doesn’t happen consistently for some reason or other.

Let’s take the most prevalent excuse claimed: too busy, got other stuff to do. Why is this claimed so uniformly? Certainly developers are busy people – we pay them a lot and expect a lot for that remuneration, after all, so sure they’ve got other stuff to do. But if we put this in another context, perhaps outside of the development process, say visiting Grandma, I’m sure there’s a parallel to be drawn. After all, we should definitely go visit Grandma more often. She’s probably not going to be around that long. She’s a nice lady, and she cooks cute little cupcakes when we do go there. So why not do it more often? Too busy, got other stuff to do. And, of course, it’s really annoying to drop whatever you are legitimately doing (whether development or otherwise) and go visit the old lady with the bad habit of talking about you as if you weren’t in the room.

As a manager, therefore, your task in ensuring code review has a much lower friction profile to it, is to remove what I think I’ll try to trademark as The Grandma Effect. If I have to stop what I’m doing, put on my Sunday best, and sit listening to stories from three decades past, I’m going to find all kinds of reasons not to. But if instead (to stretch the analogy to what I’m sure is the breaking point), Grandma were to learn how to play a wtf-pwning Mutilate-spec’d Rogue, then my interactions with her become much more palatable and manageable. Replace the trip to Grandma’s house with the annoyance of setting up a formal code review and you’ll get the picture.

There’s a tipping point here, and it revolves around the place and relevance of social tooling within your development team. You, your peers and your reports are currently interacting with friends over MSN, Twitter, Facebook, you name it. They’re booking dates, arranging weekend schedules, and getting the latest news from Reddit. You name it, they’re doing it and it’s all coming to them through a few pretty simple to leverage mechanisms.

Replace their social and common knowledge-gathering activities with knowledge leveraged within the code base, and it’s pretty easy to see how you could graft what has the potential to be a very annoying activity, e.g. code review, onto a natural way of conducting business. Instead of creating an entire workflow around the invite, simply inform interested parties about commits and let them decide whether to review or not. Instead of insisting on top-down imposition, encourage a bottom-up adoption simply through ubiquitous availability of information.

Nobody forces anybody to use a service like Reddit, after all. It exists and thrives because of the community that finds value in its presence. Personally I interact with it through RSS as I find that the most natural way of learning what it’s got to say. Lots of different feeds of information for the different types of news, all presented through a common aggregation mechanism that feels natural, that works well, and that I don’t have to think about.

So, if commits that my team members are making, or commits that others are making to a component for which I feel either moral or actual responsibility are available through that same mechanism, I’m going to take advantage of the tools to review those commits and to make my presence felt.

No formal review.

No formal sign-off.

But also a guarantee of way more participation, and what’s more, a broad reach around the typical chain-of-command style code reviews that we know and hate, instead engaging atypical contributors, not to mention the legion of lurkers just out to learn more. And isn’t that what it’s all about at the end of the day?

In summary: don’t require the architect, but appreciate their presence. And instead of bringing the people to the code, bring the code to the people.

Part III – Joy is All Around Us

When you think of a social activity, what do you think of? Perhaps a rave? Or maybe a quiet bridge foursome is more your style? Or even a Matrix-style meet-and-greet complete with latex and contortionists? Ahem…

Or maybe you’ve finally let go of this old-world requirement to actually be in the presence of an individual to enjoy a social encounter with them, and instead have embraced the reality of the 21^st century, that society and social interactions no longer require physical presence, and instead surround us every day, at every minute, as long as we (virtually) get out there and find them. Speaking as a long-time online gamer, I have a circle of folks I consider friends, with whom I talk most evenings, with whom I’ve spent quality time learning and beating goal-based activities, yet none of whom I’ve ever met. And whilst their reaction to some family tragedy on my part may result in no more than a weak “dude, that blows…” on some forum or other, in every other aspect of social interplay, they fulfill exactly the same role as those few- and far-between actual, you know, friends that each of us cling to throughout life.

According to a study on the topic conducted earlier this decade, friendship is becoming something of a luxury for the average American adult. Rather than expanding our circle of friends as travel has become more reachable for the masses, we’ve instead decreased that circle from an average of 3 to just above 1. So are we all just becoming obnoxious, introverted, “bah humbug!” Ebenezer Scrooge wannabes? Perhaps, and certainly that’s the trite response to the statistics for people in search of a quick buzzword or appliance to blame.

But perhaps instead of this reflecting a net diminution of our quality of life, we’re simply replacing much of what was considered necessary in previous generations (beer with the boys, poker night, ice fishing trips, whatever floats your boat) with a more constant, more consistent, but at the same time more arms length notion of friendship and social interaction. Though different, it fulfills everything we need in terms of communication and support, but leaves us free to concentrate on our family lives, or personal hobbies, or whatever else makes us happy to be, well, us.

Friendship when we want it, on our terms, and only then.

One potential projection of all of this can be found in the ongoing trending of the social nexus of life, business and relationships towards the online marketplaces that have sprung up around activity-, or focus-based requirements (I referred to this in my first post on this topic, drawing the correlation between Facebook and dating, LinkedIn and prospecting, etc.).

Find a marketplace, find a life (or maybe, a Second Life) – and frankly, is that really any different from the actual bricks-and-mortar reality of the rat-infested, smelly locales of the distant past (minus, you know, the scary crone shouting on the street corner, and the propensity for picking up the Black Death at a moment’s notice…)?

Indeed, my Chief Architect likes to describe an attendee at a recent conference as saying something like, “But what should we do about all these old people who can only e-mail or even worse need to use the phone? I mean, how am I supposed to communicate with somebody who doesn’t have a Facebook account, or doesn’t keep up with Twitter?” Note that this wasn’t a casual conversation over a beer, but rather a key point in a presentation (presumably to a room full of people with the requisite qualifications to be able to laugh affably at such an observation).

Whether we like it or not, whether we can personally deal with our relationships migrating into the ether, that’s where they’re headed, at double-quick time. So are you the guy with a red flag making sure that cars only drive at the same speed as horses, or are you busy building a Formula 1 car in your back yard?

And actually, perhaps more importantly, whether you’re either of these, you’d better believe your staff are busy climbing onboard with everything the new paradigm has to offer, so do you really want to be left playing catch up?

At a recent customer meeting I was surprised to hear that this highly compartmentalized, classified installation was putting a social media strategy in place (they termed it “our space”) to embrace what was happening anyway, and obviously to attempt to contain it within the security mechanisms required by their business. If they can do it, with all the restrictions and fenced-off classified strictures they have to deal with, why can’t we all?

Code review, you say? Social code review, more like. The current means of accomplishing the goal is fundamentally broken and will never scale, just like the requirement to only befriend people you could physically reach out and touch. The paradigm is changing, time to keep up…

And now in a deferential nod to the awesome Douglas Adams, this trilogy of posts on code review as a social activity will be continued in part IV, coming to a blog near you soon.

Part II – Joy is the word…

OK, so Grease is really the word, but it didn’t fit my theme, gimme a break… Anyway, back on topic, since Joy of code review – part one of this series was published last year we’ve seen our new code review product in action in a variety of customer and prospect situations, and much like the eponymous hair product in the musical mentioned above, what we thought of as an interesting twist on an existing paradigm has turned into a bit of a barn burner. I refer, in this case, to the notion of what constitutes a code review if you remove the formalism of the invite from the process.

Consider what I’ll call, for the sake of being what marketers insist on terming “edgy” (for no really good reason as far as I can make out), old fashioned code reviews. You know the type, we talk about how we really should do more of them all the time. Check in your code, mail out a bunch of invites, mail some more when those get declined, gather around a table, project your code and wait for the insults to come rolling in.

You want to try that again, Mr. Coding Specialist...?

On the down side of these things are all the obvious problems… People don’t like getting reviewed, and unless you have a particularly unpleasant architect, the reviewer is no happier about being in the room than the person on the sharp end. Factor in the time, the annoyance of the arrangements, the opportunity cost of yanking the architect away from whatever they were previously doing, and you’ve got a really expensive, not very productive, but very important from a pointy-haired-manager-perspective process.

It’s really the classical no-win situation. Your manager requires it to be done. You hate it, and you know everybody else in the room hates it too. It’s like a giant dose of spinach to a five year old – doesn’t matter how good it is for you, you’d rather scream and sit in the naughty chair all day than let that stuff past your lips.

So when we were thinking about changing the approach to code review, it seemed obvious to us that whilst code review itself is valuable, the means by which it gets accomplished is fundamentally broken. Factor in peoples’ unthinking delight when confronted with anything social and what the heck, we figured, let’s turn the whole thing on its head. Instead of going top-down into a software organization and helping the manager enforce something unpleasant in an all new and collaborative-y, enterprise-y way, how about reaching out and encouraging bottom-up engagement through a model that people are comfortable with anyway, namely formless (a.k.a. social) communities.

Who’s the most obvious person to review the code of a good developer, after all? It might be their architect, but the chances of a good developer making a blunder of the architectural type (or any kind of dumb error) is probably reasonably low. Not saying it doesn’t happen, but we pay people at that level a good amount of money on the understanding that they produce decent code, so why then treat them like kids? Instead, if the code produced by that guy is made available for anybody to review, quite literally, then rather than getting the architect grumpy because he’d rather be thinking about the next huge money maker than what this guy happened to have done mostly right but nit-pickingly-wrong in this one situation, you get other team members taking part who have (in most cases) more useful input to impart anyway.

Instead of feedback of the “so… rather than using that particular transitive constructor, I’ve found that explicitly instantiating a new object and then initializing only what I need saves me, on average, 3 cycles a day” type, you might get the “hey, I was hacking on that a while back… might want to filter that data, cuz Bob’s front end passes in all kinds of crap… just saying” type instead – your choice, but personally I’d rather hear an hour’s worth of the latter than a moment’s worth of the former…

So who is at the review turns out to be much more important than whether it’s held, given some arbitrary set of “holding” conditions. But of course this comes with its own set of challenges, notably how do you know when you’re done if there’s no formal “meeting” to review your code (and to insult you, have we mentioned that part?).

In fact, it’s much like how the transition from waterfall to Agile was accompanied by many a gnashing of management gums and misplaced wails of “but how will I know if it’s going to be done on time?” But hey, that didn’t work out so bad, did it? People got used to time boxing, to changing requirement sets, to not waiting until it was arbitrarily “finished” and instead shipping it so as to gather feedback faster.

In my next post I’ll look at this new world order from the top down and examine the benefits to encouraging (rather than imposing) a social code review paradigm, and how it can make those metrics we know you care about look better than ever before.

Part I – Ode to Joy

Since the launch of the seminal “Joy” work which hopefully doesn’t need mention here, we’ve seen everything from The Joy of Cooking to The Joy of Not Working (my personal favorite!), and so further to that deeply mined vein of authoritative works we bring you the necessarily over burdened… Joy of Code Review!

Joy, you say? Let me count the ways…

• I implement a task, using what I consider to be best practice patterns and guidelines; I slave over this, my creation, and when it’s done, I stand back and admire, much in the tone of an old master, this latest image of my greatness.
• Then I remember I need to get it reviewed…
• So, I timidly invite my Architect and 3 of his best friends to the war room to review my new baby
• After many rescheduling pauses, we finally gather…
• I hold my breath, turn on the projector, and bare my soul to the collective seniors in attendance
• 30 minutes later, having endured a ritual mind flaying, and the predictable but nevertheless enjoyable tortured examination of my parentage, education, upbringing and such fun rhetorical musings as “why do they let people like you graduate?” I slink out
• Follow up is, if anything, more painful as I’m reminded moment-by-moment of just how badly I’ve lived up to the expectations laid out for me by the senior team members

Anyway, so code reviews suck, amirite? But we all know we need to do them. Of course, we all know we need to do them for completely different reasons from each other…

• Kids right out of grad school know they need to do code reviews because although their code is, like, totally perfect, it’ll be good to show the old dudes their skillz, and for the old dudes to check out some rad new stuff that they might have missed along the way.
• Senior guys know they need to do code review because otherwise all kinds of terrible cruft will get promoted into the head branch and somebody (are you looking at me??) will have to fix it…
• Managers know they need to do code reviews because they read all about them in a book with a cool cover, and it’s all Agile and stuff, and let’s face it they’re being measured on code review coverage, so come hell or high water you’re going to do code reviews!
• And of course, regular professional developers know that code reviews, however painful, genuinely lead to better code, regardless of the pain involved in getting there.

What we have here, folks, is a social organization, complete with the crazy uncle, the embarrassing grandma and the pimply teenagers. And social organizations, as we’ve all come to know and love, are at their best when the forum in which they’re fostered exists for a reason that encourages the unstated, but nevertheless in-your-face activity of which those in the respective societal groups are desperately in need:

• Facebook? Getting a date. And then getting another one while simultaneously trying desperately to avoid the previous partner. Rinse/repeat. Seriously, I have no idea how kids manage today. At least when I was young and awkward we could hide behind the silence and foot shuffling of real face-to-face meetings. Now with a keyboard and the internet in the way, there’s nowhere to hide!!!! I’m off topic again… ahem…
• Linked-In? Getting a job.
• Myspace? Getting a clue.

You get the idea.

So code review as a social engagement… really? Parts 2 and 3 of this series of posts will examine how such interactions, fostered by social networking tools, are the best way to ensure code review gets done and returns value both to the participants and to the companies in which they work.

Truepath Analysis

Ever been faced with that glassy-eyed expression, the look of unthinking, unwholesome fear when some long, incomprehensible word escapes your geeky mouth and upsets the maiden aunts around the once-a-year, wear-your-best-tie, try-not-to-die-before-the-cake’s-all-gone tea table? OK, so this paper won’t help you in that situation whatsoever, but if you replace your maiden aunts with a bunch of your best geek friends, and replace the tea with a sturdy helping of Dew, knowing how a real whole program analysis solution works might just conceivably come in handy. Some day. “Dude, I was totally stoked when I read this thing, trust me it’s ahh-some.” Maybe.

Anyway, in the best traditions of self-serving corporate PR blogs everywhere, I give you… drum roll please… Whole Program Analysis, the Klocwork Way.

Enjoy.

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?