What is MISRA? More Irrelevant Software Requirements Again…uh no but certainly the sentiment of many developers.  MISRA (Motor Industry Software Reliability Association) is a coding standard, which first released MISRA C in 1998 and has since been revised.  Obviously, this came out of the automotive sector with a clear focus on helping software systems to be more reliable and maintainable.

MISRA has since grown.  Now you see more and more industries adopting these standards.   In 2008, MISRA released the C++ equivalent standard.  So the obvious question is, should I apply this to my software source code base?  In short, yes.  Maybe you don’t need ALL of the MISRA rules, but there are certainly some that are worth your time.

Examples range from the very simple checker rules sets that mostly fall into the coding style category:

MISRA C rule 19.1:  All #include directives in a file shall only be preceded by other preprocessor directives or comments.

MISRA C rule 2.2: You should only use /*…*/ style comments.

Down to more important issues (I hope everyone has the tools in place to find this):

MISRA C rule 9.1: Unintialized variables.

It really depends what you’re trying to accomplish.  Certain rules such as 9.1 are very important, while others can help you with portability or just serve to make your code more maintainable and less complex going forward.

Word of warning, taking an existing software code base and apply the entire MISRA rule set is guaranteed to throw many errors.  Take the zlib project, obviously not MISRA compliant, but to illustrate the impact of turning on all the MISRA rules, will throw over 5000+ issues.  That is an issue for every line of code…yeah that’s useful.  So be warned, don’t try to boil the ocean.  Start iteratively, even if that means only one rule at a time.

In my previous post I discussed where I thought Agile really falls flat.  The problem I have is working remotely.  Several times now I’ve misinterpreted what exactly we covered in remote meetings.  These have been mostly minor things but they do add up.

But here is where there is just a massive difference between Waterfall versus Agile.  By far the biggest lesson for me and why I love Agile is all based on visibility.  Having a working product in one simple iteration means the world.  So even though I was ranting in my previous post, imagine if we were doing waterfall.  Chaos could have ensued once the product was integrated (maybe months after).  As many point out, iterative development shows us up front (in two weeks or less) that we have a major problem.  I’ll stick to Agile, thank you.

So Agile is great, I’m all aboard but I still have to do something about working remotely.  Once I get this addressed I should be sailing.

I’ve come across a few things that people are doing .  Mostly with some interesting video conferencing techniques (here and here).  Do these really work?  There are some studies which are interesting but they are not really applied in an Agile context.  I did come across one article that might be helpful…although I need to shell out a few bucks.  I did find one reference on martinfowler.com that I thought was useful as it goes through the key points you need to consider with offshore development.

Overall, I still don’t have a good plan to deal with this.  So let me ask everyone out there, please let me know if you know of any good references.  I could certainly use some help.

The importance of code reviews has already been well covered by lots of smart people like Jack Ganssle and Jason Cohen. Recently, the subject has become more important around here, so we want to offer our take. In particular, we’re looking at the best way(s) to incorporate code reviews into an overall software verification strategy and how automated tools (such as static analysis, no shock there) can help unleash the benefits of peer code review. More on that angle another time, first the bigger picture.

Klocwork recently commissioned a survey conducted by Forrester research on this whole topic and the results are pretty interesting. While there’s a whole bunch of data that can’t be covered in a single blog post, a general theme we found is that developers see the value of code reviews, they’re often mandatory, but the process itself seems to be ad-hoc and quite ‘behind the times’. Here’s an example of what I mean:

Code Reviews - Mandatory but Ad-Hoc

So, code reviews are mandatory but you can kinda invite whoever you want to review the code. Shouldn’t who reviews the code be pretty important? (Hint: Yes)

We’re gonna keep talking about different aspects of this important development milestone, so stay tuned and we’d be interested to hear anything you have to say on the topic.

Unlike Todd who is this blog’s main Agile expert, I’m pretty new to agile.  I’ve gone through the typical training (CSPO) and all the other good stuff,  so I’m drinking the Kool-aid.  But I thought I would provide my perspective,  now that I’ve been working in an Agile shop for a while and tell you what I think really sucks.  I’ve read lots of warnings why Agile can fail and I’ve tried to stay focused on overcoming the hurdles.

Being a product manager, one of the things that is really ringing true to me is where Agile falls flat–working remotely.  Lots of discussions on how much it can suck here, here, here and here.  As part of my job, I travel… lots.  If I’m not at a customer meeting I’m at the next trade show.  This means many design and planning meetings are done remotely.  I end up finding we have developed something different than what was originally discussed or at least what I thought.

This gets frustrating because it has a major impact — all of a sudden as opposed to having that working functionality at the end of the iteration, you are set back by redoing that same work the very next iteration.  About as productive as watching every single sport of the Winter Olympics (I don’t even like figure skating…I swear).

As much as I’m puking all over Agile, I’m still very invested (messy as it is).  Let’s face it, offshore development is a way of life and there are many things people are using to work in this remote context.  Next week I’ll post the opposite side of things and discuss the consequences of working remotely along with the value Agile does give you.

As I write this, I’m sitting at the Dallas airport, suffering through a 3 hour delay on my flight to Washington D.C. to present at our 2nd Agile in Action Roadshow with our friends from Electric Cloud, Perforce, and VersionOne. As I have the time, I’ve been reflecting on my time here in Dallas, and the phrase “Everything is big in Texas” is bang on. Before I get to that though, I have to say that I do love Dallas…I’m not totally sure, but I truly believe I’m treated a little more special because of my last name (which I casually mention whenever I get the chance). Nothing like having the same surname as a famous coach from the Dallas Cowboys!

Okay, so why do I think the Everything is big in Texas is accurate. For starters, my big delay is due to a big thunderstorm. My rental car preference is a Compact car, and what do I get? A Yukon…I’m not sure what is bigger, this vehicle, or the Canadian Territory with the same name.

I saw big hair, big hats, big rings, big belt buckles, big omelets, big waffles, and big enchiladas. What I also saw was a big enthusiasm for Agile development. We had a great turnout that was fully engaged from the instant the roadshow began, asking questions wanting to know more, sharing their experiences with others, visiting with the vendors and not leaving until they got the information they needed. I wrote a few weeks ago about Agile adoption and where it currently was, and participating in this event, and speaking with the attendees, it allowed me to gain some additional data points that only strengthened my beliefs on this…Agile is definitely growing, and in all industries. As I said before, I truly believe almost all organizations have some Agile developments teams.

Hopefully the enthusiasm I encountered in Dallas will follow us to Washington D.C. And I’m thinking I may want to introduce myself as Todd Ovechkin…

We try not to plug Klocwork on this blog too much and keep the discussions around general software development issues, topics, and trends (with an obvious bias towards static analysis and software verification since those are our areas of expertise).

So, today I’ll go ahead and break that rule and encourage you to visit our new online resource library that includes videos, webinars, whitepapers, analyst reports, etc. All the assets are organized by category and tagged with their subject/content so everything is easy to find. I encourage you to check it out… here’s an example of the kinds of demos we’ve put up there so people can quick see what our tools are all about.

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.

At the risk of sounding like a co-dependent, in this post I discuss coping mechanisms that a “big picture” technical  writer (say, like my friend Beulah) can use to adjust to working in the granular conditions of an agile environment.

Don’t give up the big picture

Wouldn't it be great to use XPlanner for everything? Just imagine the velocity I could achieve.

When you work on a bunch of stories or tasks, it’s trees, trees, trees everywhere  you look and not a forest to be found.  This means that a nice concise how-to could be a long way off while you document myriad  features.

My advice is to finish the pieces and try to get to the minimalist documentation afterwards. In fact, Shannon Greywalker suggests going back and fixing things up later, but mentions that the business case for this can be a bit weak.  I think it’s worth the effort if you can swing it.

I’ve blogged before about how workflow can be helpful in getting the big picture. If the feature is big enough, workflow is your friend and can really pull you through.

Go for “What’s New” first
For each release, we document the cool new features on a “What’s New” page and “What’s New” is where I like to start.

If you can neither summarize nor explain why people would want to use a new feature, you have no business documenting it. “What’s New” keeps me focused on the whole point of the development work in the first place.

“XPlan” everything
I was a slow adopter of XPlanner, which is the tool our team uses to document development, testing and now, documentation.

Documentation has a separate project in XPlanner where we track our stories. At first, I found it difficult to update XPlanner regularly because some of our work can be difficult to account for.

For example, one our sales engineers is a prodigious reader of documentation who meanders over for his (thrice) daily “found a spelling mistake” or “did we document?” or “why can’t titles be printed on the PDFs generated by the wiki?” questions. All good points, with some requiring immediate action and others requiring medium and long-term planning.

But after reading Getting Things Done, I can really see XPlanner as a great life planning tool. See the screenshot above. For low self-esteem days, I recommend first completing tasks such as “Wake up”, “Shower” and “Eat breakfast” under the Personal Maintenance story.

Targeted procrastination
We’ve gone from blanket procrastination, which was a two-week offset, to carefully picking features that could benefit from a little more “fleshing out” before documentation. I like this approach because we show great planning with our procrastination.

For example, I like to spend bigger chunks of time on one thing, so I may delay documenting a bigger feature in favor of knocking some smaller stuff off the list one week, so I can string together several days in a row for the big stuff. I work better that way.

Ask a lot of questions
My modus operandi is asking as many questions as possible. Be annoying, but in a friendly and charming way. There’s an art to asking good questions, but sometimes it takes a bunch of stupid ones to get there. Dive in.