Time and time again I get asked, how does static analysis fit into my existing bug tracking system? ”I need an integration with my system (i.e. Bugzilla) because that is what we use everyday. Every time I find a bug I need to track this through my system.” This is where I take a deep breath as I scream on the inside. Taking every bug and putting that into your bug tracking system is just wrong. Horribly wrong. The best way I can describe this is through the compiler analogy. Every time you add a feature or bug fix,
Read More »
As a product manager, the only backlog I typically care about is my product backlog. Do I have the right stories in there? Do the stories have enough detail? Are they properly prioritized? You know, that kind of stuff. Today, however, I’m going to write about a very different backlog, that is the static analysis defect backlog. A static analysis backlog is created when you run a static analysis product on your code base for the very first time. Chances are pretty good that the first analysis is going to list a large number of defects,
Read More »
Nice blog post from Walter Bright over at Dr. Dobbs on the Patterns of Bugs. He ties together bug patterns, recommended process changes, and the resulting productivity payoff from making these improvements. He recommends a bunch of process changes, including static analysis, code reviews, and coding standards, then goes on to review examples of different bug patterns. A few can be detected with static analysis (coding mistakes as written) but many are errors with the code as intended (something static analysis doesn’t check… that’s what testing is for). His main recommendation seems to be that
Read More »
While I may not be the most active Twitter-er in the world, the one thing I have noticed is that there is an awful lot of activity around the term “code review” lately. Since code reviews have become a widely used practice, I thought I would share one of my experiences about code reviews with you, from a product manager perspective. In my first Agile team, many years ago, it was tabled (in our retrospective meeting after a couple of Sprints) that code reviews should be added to our definition of “Done”. Let’s just say
Read More »
I just couldn’t resist using the classic spaghetti Western as the title for this installment of my Going Agile series because it a) it was an awesome movie, and b) it truly sums up that 1st iteration of ours. My last post was all about the 1st iteration planning meeting, and how it was such an exciting and productive time for our team. We came out of that meeting a little weary, but extremely motivated to get to work. We were also just a tad naive. The next 2 weeks were a roller coaster as
Read More »
Just wrapped up a successful 2 day Embedded System Engineering conference in Stuttgart, Germany. This “all-German” show had just shy of 600 attendees, as well as about 60 individuals (representing the 20 or so companies exhibiting), so this was considered very good by the show organizers (who by the way did a fantastic job… the food here, for example, was as good as I’ve ever seen for such an event). The Klocwork booth was shared with our good friends at Emenda, and we had a choice spot that allowed a good flow of people. We
Read More »
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,
Read More »
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
Read More »In a previous post I provided the top 5 C/C++ quality bugs that I that I see time and time again looking at customer code. Time for the C# version: 1. Null pointer exceptions from a method 1 public class A { 2 public A foo() { 3 if (flag) 4 return null; 5 return new A(); 6 } 7 8 public void var() { 9 A a = foo(); 10 if (flag) 11 a.foo(); 12 } 13 14 private int flag; 15 } This is the most common issue I see. In this example
Read More »
