The hype has been on for years and although the frustrations of continued dropped cell calls  haunts us all, the future has arrived in full swing….pardon the pun!!! I thought this article between “Mad Money Cramer” and MLB is a fantastic illustration of a dream unfolding before everyone’s eyes.

This month has been a time to reflect upon the historic moment 40 years ago of man’s first walk on the moon.  I am sure just about everyone can remember where they were when the first televised pictures captivated the world.  For the legions of people that made that historic event a reality, they undoubtedly felt they  were living on the bleeding edge of technology with as many known’s as unknowns. But for the rest of us, it was a completely controlled event.  One we marveled at but did not participate in. One we were all touched by, but could not touch.

Contrast that event to what is transpiring today. We are in the midst of an “explosion of the mobile Internet”, but it hasn’t arrive with a single defining moment.  It has crept up on us virally, gradually becoming more pervasive and entrenching itself in our daily lives.  Even trying to quantify the market potential is difficult to predict, as Cramer exemplifies  - “Until you see these applications, you don’t understand how this thing is going to take over the world. It’s the definition of why I value the Mobile Internet as the biggest investable trend I’ve ever seen.”

There was a time when many of us tech-maniacs would hear from our significant other “are you ever going to put that damn thing down”  referring to our iPhone or Blackberry.  Now I for one watch in stunned silence as my kids and significant other are constantly glued to either their iPhone or Blackberry.  What was once the exclusive domain of the workaholic, semi-obsessed information junkie,  has become the “always connected” device of…well everyone I know.  It is no longer a “work device”  it is “my device.”

The transformation was fairly seamless and uneventful except for one subtle difference….one by one we are all participating in this event…not just witnessing it. Experts in the varied  fields of human behavior must be licking their chops as this new era spreads across humanity like the rising sun across the horizon.

The world has changed and I sometimes wonder if we now have “a new world disorder.”  A world where snippets of information are all anyone has time or interest in, a world where one on one communication is not the norm, a world where if we are not connected we are not comfortable.

Somehow it all seemed more managed when it was a “work device” as opposed to “my device.”  Time will tell how far out in front the “explosive mobile internet” progress is over the process necessary to support it.

I sat in on an iteration review this week and came away feeling great about the team, the process and the strategic direction we taking our products.  Reflecting on the meeting I asked myself what was the magic in the meeting? The strategic direction of the product had been hashed out months ago in a grueling multi day session,  almost all of the members of the development team that were present for the review have been with the company since it’s inception back in 2001  and the meeting covered what it was billed to cover –  there was no “ oh by the way we got this new cool feature into this iteration.”

The magic of the meeting was in what I will call  “The Unspoken Agile Advantage.”  We are working towards our next major product release with 2 week iterations.  We are coming up on the end of an iteration and the team got together to review a demo of a very significant new feature. I sat in unannounced to see our progress first hand.  The demo was solid and it was one of those good news – no surprise meetings.

So what is this magic I keep referring to?  The chemistry of the team’s interaction.  In short order, major new functionality was designed and brought to life.  The team could see the results with very fast turnaround –  2 weeks, while it was still fresh in their minds.  The Agile process lends itself perfectly to “very cool, hey can we do this now” or what about changing that adjacent part of the screen to better expose these capabilities….and on and on.”  The magic was in the rapid review, the visual context of the new functionality in relation to the rest of the product and the dynamic interaction of cause and effect of the new capabilities – all centered around making the overall user experience even better than “the plans on paper.”

I am sure every Agile Evangelist would look at me and say duh…yeah that is what Agile is all about.  As a CEO it is one thing to hear we are on track with the new release and be shown multi-colored spreadsheet or dashboards,  but it is worth its weight in gold to actually see the progress maturing and the ensuing feeding frenzy of ideas amongst the development management and team members in quick iteration bursts.

I recently read a very good blog on the Triangle Offense and Scrum, and it inspired me to write a basketball related item as well.  I used to play a lot of basketball growing up. I played point guard, and was in charge of running the offence, calling out the appropriate play for each time down the court. In order to get the best possible opportunity to score, a lot of things have to go right…1) the proper play for the defence presented must be called; 2) the play has to be communicated properly (from the bench, to the PG, to the rest of the players on the floor at that time) so that everyone understands what to do; 3) Execution…the team needs to execute on the play that was called; and 4) sometimes you need a bit of luck.

Now I’ve been a Product Manager for software companies for a number of years, and developing/releasing a product is very similar  to the basketball scenario above.

1)    Proper play must be called …From a software perspective, this is knowing about the market you play in, as well as the competition you are playing against. You need to understand the weaknesses (or opportunities) so that you can take advantage of it, and get that easy score.

2)    Play has to be communicated properly… Communication is crucial in the development/release of a software product, especially if your team is Agile. Everyone needs to understand the big picture, and this knowledge has to be consistent. What would happen if the PM, chief architect, and VP of Sales all had a completely different understanding of the deliverables for the upcoming release? I’m sure you can figure it out… Also, over-communicate (if that’s even possible). More on communication in an upcoming blog…

3)    Execution… Each team member is a part of that team because they possess a key talent. So whether it is the lead developer, or the QA lead, or the UI designer, they all need to execute ‘the play’ to the best of their ability. If this occurs, then you’re team has given itself a great opportunity to succeed.

4)    Luck… Okay, so back in the day, I’ve hit the odd jumper as a result of a broken play, and while I would like to attribute that to pure skill (ha ha), my reasonable/practical side realizes that there was probably a fair bit (okay, a lot!) of luck involved. Software teams sometimes need a little bit of luck as well because things don’t always go as expected. So when you hear that developer say, I stumbled across this, while fixing that… consider Lady Luck to be on your side.  

I was originally going to write about how software development and golf were related, but other than the amount of cursing I do in both, I couldn’t come up with 3 other good similarities. If you can come up with a few more, then I’d love to hear them. For that matter, I would like to hear how you relate software development to other sports as well…Cricket anyone??

Over the last few weeks, we’ve been working on cleaning up our product backlog, and the one thing that I always find to be the most challenging is the prioritization. I’ve worked on a number of different products over the years, with a number of different teams, and have used a number of different methods to prioritize a backlog, and I thought I would take a few minutes to share them with you now.

1)    Feature rating – This is the method where Excel really shines, because you get to create a cool matrix consisting of your features and a number of categories that are important (such as revenue generation, importance to existing customers, competitive differentiation, and so on). You then put a rating (usually 1-5, with 5 being the most important) in each of these categories for each feature…add them up, and the feature with the highest total becomes “most important feature #1”. Now, you can make this even more interesting by giving a weight to each category, to show which categories are the most important. So, for example if revenue generation is the most important factor in your company, then give that category a .5. Give your remaining categories a weighting, ensuring that the total weighting equals 1. This method can give very clear results, but can tend to be biased (I really like this feature, so I will give it a higher rating than this feature I don’t really like…)

2)    Baseline prioritization – In this method you pick a feature that you feel should be in a release, then compare all other features to this one. If any of the features are more important than that initial feature, then they become a higher priority, and conversely, those that are less important become a lower priority. I have found this method okay, but difficult to get a really good prioritized list…yes you get a list of the most important features, but not really fully prioritized list saying feature 1 is the most important, followed by feature 2, etc.

3)    Gut feel – This method is certainly the least scientific of the bunch, but it still relies on instinct, and can work well if you have a really good grasp of the market and your customer base. In the times I’ve done this, I’ve also tried to take the concepts of method 1 above, and apply that… so for example, Feature A has 6 different customers crying for this, will definitely generate more revenue, and further differentiates our product from our competition…sounds like our top feature for this release! This is the method that I find the most effective because you get to apply a number of concepts from a number of different methods.

There are a number of other methods out there that I haven’t used, so I would be interested to hear what experiences you have had with them, or with the ones I’ve listed above.

A recent article on the top five causes of poor software quality and top 5 non-technical mistakes inspired me to also provide a top five on software quality bugs.  Here is my top 5 list of bugs (with some simple examples) that I see time and time again looking at customer code:

1.    Null Pointer dereference

This is far and beyond the most common issue that I see time and time again.

void npd_gen_must() {
int *p = 0; // NULL is assigned.
*p = 1;  // pointer is dereferenced
}

Now this example is pretty basic and if you ever did something this obvious, maybe it was time to re-evaluate your development skills.  The idea is simple, you assign NULL somewhere then dereference it at some point later.  This is usually missed under a complicated control flow (many conditionals).  Or even more common is the fact that I see memory is allocated, but is never checked against NULL.  Now, some organizations don’t care about this but I would hope anyone doing embedded development is all over it.

2.    Null pointer dereference from function

This is really the same thing but with one very important difference.  This deals with issues from functions.

void xstrcpy(char *dst, char *src) {
if (!src) return;
 dst[0] = src[0];
}

char global;

char *xmalloc() {
  if (global) return &global;
  return 0;
}

void npd_func_might(int flag, char *arg) {
  char *p = &arg;
  if (flag) p = xmalloc(); // xmalloc() may return NULL
  if (arg) { p = arg; } // p may get a new value here
  xstrcpy(p, "Hello"); // p will be dereferenced in xstrcpy()
}

It is this inter-procedural (spanning multiple files/functions) context that is often overlooked.

3.    Memory leaks

I have yet to find a programmer in the C/C++ world who doesn’t know this intimately.  Sadly they happen, a lot.

void foobar(int i) {
  char* p = new char[10];
  if(i) {
    p = 0;
  }
  delete[] p;
}

Here we have dynamic memory stored in ‘p’ and allocated through the function ‘new[]‘ at line 3 and is ultimately lost at line 5.

4.    Array index out of bounds

Again, most people know what these are but there are so many variations of this that they are always inevitable.

int main() {
  char fixed_buf[10];
  sprintf(fixed_buf,"Very long format string\n");
  return 0;
}

The string is 24 characters so at line 4 the array index of ‘fixed_buf’ may be out of bounds.

5.    Uninitialized variables

int foo(int t) {
  int x;
  if (t > 16) {
    x = 1;
  } else if (t > 8) {
    x = 2;
  }
  return x + 1;
}

The value of variable ‘x’ can be used at line 8, when it might be uninitialized.  I always found these surprising that these come up as they are pretty basic.  But I tend to only see these in complex control flow paths.  So the developer might check for these under normal conditions but forgot on some path.  Especially for legacy code this might not bite you until you change something later on.

So that’s it.  These examples are pretty simple and certainly not reflective of the real world (or at least I hope not).  Later I will post the same idea for Java code.

There was a recent blog on whether or not you should have bugs (that were not found during the most recent iteration) added to your product backlog, or kept in a separate bug backlog. Here at Klocwork we have a defect database that is closely monitored by Support, dev, PM, and so on…suffice it to say, it has a high degree of visibility within the organization and will probably never go away. Being an Agile company we also have a product backlog that is reviewed daily and prioritized regularly. Every two weeks (coinciding with our iteration planning) PM and Support get together to discuss the highest priority bugs, and to determine if those bugs should/need to be added to the backlog for the next iteration. A key piece to this process is using tools to maintain this backlog. The backlog tool, which also has an integration with our defect tracking system provides a tight correlation between the two, and a level of automation that makes life a little easier for everyone. Once added, these bugs are prioritized just as we do with all of the other features (stories) we have in the backlog. We also have weekly status meetings where the most recent bugs are discussed, once again to ensure they receive the proper attention.

Since we are in the bug-finding business, we take bugs very seriously and adding them to our backlog (and as a part of our iteration planning) helps ensure we address them quickly.

Here’s a short blog review of Klocwork Solo by Jeanne Boyarsky. Klocwork Solo is a downloadable Eclipse plug-in for Java. Aside from a few installation hiccups, it’ s a good review with kudos for the range of checkers we provide in the default configuration.

Try it out yourself and let us know what you think.