Next week I’m heading out to the Software Assurance Forum (use SOF96945 for the conference code) in Washington D.C. (well, actually Arlington, Virginia, but D.C. sounds more glamorous). If you’re not familiar with what the SWA is, in a nutshell, its key objective is to encourage software developers to raise overall software quality and security from the start, rather than relying on applying patches to systems after vulnerabilities are discovered.

Anyways, while I’m there, I’ll be taking part in 2 speaking opportunities. The first will be as part of a 6 person panel discussion entitled “Understanding Technology Stakeholders: Their Progress and Challenges” (10:30 – 12:00 on Wednesday). The panel is made up of stakeholders from varying disciplines such as industry, academia, standards, and government. A good well rounded panel should provide for an interesting and entertaining hour and a half.

My second session (Friday at 2:20) will see me fly solo as I discuss our (Klocwork’s) experiences and observations as they relate to SATE. I’m not given much time, so I’ll be revving up the motor mouth to make sure I get our points across. I have a sneaking suspicion I just *may* go a little OT.

So, is anyone out there also going to this event? If so, drop me a line either by email (todd.landry@klocwork.com), or Twitter (@todd_landry) and perhaps we can get together to chat. Look for my next blog next Thursday, as I will recap the panel discussion and the other sessions I attend at this event.

I have always loved “I’m gonna write me a new minivan”  from Scott Adams.  To me, it never gets old.  Originally published in 1998, the theme that applied then still does today: driving 100% of defects or bugs out of the code-base is a laudable goal, but is it really the right one?   I would have to argue no.  There’s no silver bullet out there that will find all software defects and solve issues automagically, and until there is, software development will continue to struggle with prioritization.  Unfortunately, we live in a world of finite resources and constantly evolving demands, but we can always dream about being Wally for a little while.

I remember that idyllic summer day when I saw my very agile dog Maggie jumping through the sprinkler. I laughed until I cried. And then I thought:  This reminds me of what I do for a living.

Jumping into the Agile fray: a technical writer's perspective

I’m a technical writer and technical writing in an Agile environment is somewhat like chasing those water drops.

You can run after those features, but early in the game there’s not really anything to hold onto.

So, how does one document a feature that will probably change from one iteration (or day) to another without chasing one’s tail?

Workflow can be your rock in that ever-changing environment. While the feature is likely far from finalized, someone’s gotta have an idea of how people are going to interact with it.

The developers can get you started, but the workflow people (at least in my experience) are the product managers.

So, while my agile dog chases water drops, this technical writer chases product managers—and if I still don’t have enough of a big picture outline for the feature or a collection of features, then the Chief Technical Officer is in my sights.

For major features “in flux”, the best way to get “good enough” content to meet your iterative deadlines is to channel the Australian shepherd within and herd the developer, product managers and testers into a room with a whiteboard and a marker.

In half an hour, you’ll get something workable. And maybe a chance to put your two-cents’ worth into the design.

What if there’s no workflow available?

If it’s a sunny day, go find a sprinkler to jump through. These days, that’s a chilly prospect indeed.

In part one of Going Agile,I talked about how we introduced Agile to our development team. This next post will look at the events that led to our first iteration planning meeting.

During the weeks that led up to Iteration 1, there was much work that went on as a team, and much that each team member did individually. As the Product Owner, my biggest task was to create a backlog. Sure, I knew what the main new features were going to be, but I still needed to capture this, and add other oft-requested features. I scoured every correspondence I had with customers, sales, support, development, and so on to gather this information.

After everything was said and done, I had a pretty massive backlog… a pretty massive, unprioritized backlog. At this point, I really didn’t know any good techniques for backlog prioritization (that would change after attending the CPO training with Mountain Goat Software). This training was not going to happen for a few months, but something needed to be done… so I did what any good Product Manager does…I used the ‘wet finger in the air’ technique. Now, my ‘estimations’ were based on a number of concrete data points and some not-so-concrete assumptions and anecdotal evidence, so they weren’t totally of the ‘wild-assed guess’ ilk. After a few more days I had my backlog read for the team.

While the backlog creation was going on, a number of team meetings were occurring. Two of the more important meetings involved creating rules for the team and preparing our definition of “Done” . I highly recommend spending some time up front on both of these activities.

Creating the team rules was a great exercise, because it was the first time the team sat down as a collective and decided what the rules would be. Many of the rules were not groundbreaking…things such as everyone’s opinion is equal, treat everyone with respect, don’t be late for meetings, and when and where daily Scrums were going to happen.

The best result from this meeting centered on the team’s communication methods. Everyone was already using email, so that was covered. Instant messaging was rolled out to the team, and everyone was to use it. Of course face-to-face discussions were encouraged the most, but there needed to be some way to let people know you didn’t want to be disturbed (unless something was urgent). Everyone created a Do Not Disturb sign, and when it was posted, it was to be respected. Sometimes people just need to focus on the task at hand, rather than constantly being disrupted. We came out of that meeting with a clear set of easy-to-understand team rules, and we posted these rules in our team conference room for all to see. Note… rules can and will change over time.

Next was coming up with our definition of Done. The team sat down for a couple of hours to determine what should/should not be included. Looking back, we thought we were cavaliers and were blazing new trails with the definition we came up with…in reality, we put together a definition that was pretty much in line with the ‘industry norm’. One thing that we did not include initially was code reviews…that is, for a story to be considered done, the code had to be reviewed by at least one other developer (who was not associated with that piece of code). During our Iteration 1 retrospective, we modified our definition of Done, and code reviews became part of it. In fact, this definition of Done may go through many, ahem, iterations before becoming finalized.

Finally, we needed to get our ‘room’ set up and have all the necessary supplies on hand. Our team decided to use a wall board with color-coded cards for the tasks. Green cards were for development tasks, red cards were bugs, blue cards were for testing tasks, and yellow cards were for documentation tasks. Now we just needed a board to pin these tasks to. We didn’t want to spend a small fortune on a big pin-board, so we got creative and used carpet under padding. (You can get a huge piece of this at any DIY store for next to nothing and it works like a charm.) We fastened it to the wall, put on some masking tape borders and labels, and we had ourselves a Scrum board.

So with our prioritized backlog, team rules, definition of Done, and Scrum room all set, we were now armed and dangerous, and ready for our first iteration planning meeting…TO BE CONTINUED.

In a previous posts I reviewed the Top 5 C/C++ and Top 5 C# quality bugs that I that I see time and time again looking at customer code. I wrote my Java Top 5 with an embedded programming focus and the folks at www.embedded.com decided to publish it on their site. Here’s a snippet below and the full Top 5 Java bugs article can be found here.

While C dominates as the programming language of choice for embedded development, the use of Java is definitely on the rise. In fact, according to a recent VDC survey, 12.3% of respondents currently use Java in the embedded space, and 17.9% expect to be using Java in the next two years.

For those transitioning from embedded development using C, you might find yourself falling into the hype that Java is a “safe” language. For example, Java developers face no requirement for managing memory associated with objects. However, this is where the trap may be laid. Even though there’s no need for memory management, developers may need to keep track of specific resources the object allocates. This is especially true in an embedded context where resources are often constrained. Even for experienced developers, these traps pop up time and again and can easily jeopardize your code quality and security.

Here’s a round-up of the top five programming issues developers should be aware of in embedded Java development [More...]

In this 3 part blog series I want to cover general misconceptions with static analysis coverage.  This will include a discussion about:

• compiler warnings available,
• different types of style issues including coding standards, and
• your available options to fit them into your formal process.

Very often customers ask why we don’t cover specific checkers.  We always get great feedback on high value checkers that they would like to see.  But occasionally we get the request to find simple compiler warnings or code style issues.

For the first part of this series I want to focus on compiler warnings.  These are not the compiler errors such as syntax/parse errors you get with a compiler.  Instead, I want to concentrate on those pesky compiler warnings that still let you build your application, when you really know you shouldn’t.  We have all experienced compiler warnings that are just plain confused with your code.  But on the whole, you are guaranteed to find some pretty big blunders.

Most modern compilers focus on providing more details about compiler warnings.  These can be very valuable as it helps find many of those plain dumb mistakes.  It varies by compilers, but many find things such as constant expressions from conditionals, returning from a void function, assignment in condition (use = instead of ==), suspiciously-placed semi-colon and many, many more.

To find some of the issues, you usually need to provide a compiler flag -Wall.  For example:

    gcc -c -Wall foo.c 

Make sure you read your compiler documentation for available warnings.  Here is the gnu gcc compiler and Microsoft cl compiler docs.

Given that every compiler on the market provides its own “checkers” for compiler issues, does it really make sense for static analysis to get in there and detect these issues again?  I strongly believe that every developer should ALWAYS clean up their compiler warnings before going onto static analysis.

But you will still find static analysis tools providing these capabilities.  Why?  Well, first and foremost, not every compiler has the capability to find simple coding issues.  The other reality is that not everyone checks the compiler warnings…(we all know who we are).  Or sometimes you just want to run one tool.  In other words get the more complex bugs with static analysis along with the compiler warnings.  It is for these reasons that static analysis tools have introduced many of these low-level issues.

For the next part of this blog series, I want to go into the details of compiler warnings and some of the things that coding standards are doing as well.