Just came across this post about the 5 code metrics you need to watch.  I thought it was worth mentioning as I just blogged about this below (including something similar a while back).  These are interesting metrics and more high level, but certainly important.  I like labeling duplicated code as something important.  I think we often forget how much we reuse code and have the same mistakes in many places.

In a previous post, I talked about different types of metrics and how they can apply.  These were mostly focused on a system level and provided insight into system complexity from  release to release or build after build.  Now, let’s take a look at some other metrics and how they can be used effectively with the developers.

There are literally hundreds of metrics you can measure, so what is really important?  That’s a tough question because it depends on your organization.  Perhaps you have some coding standards in place or simply want to measure some basic functionality to help developers improve code quality.

Here are some of the more common metrics I’ve seen used in practice:
•    Lines of code
•    Number of functions/methods
•    Commented code
•    Nested includes
•    Number of compiler directives

Most of the metrics listed above are about maintainability.  The more lines of code you have or the more of functions/methods, the more you have to maintain for an individual file.  If these values are high, then perhaps it deserves a new file or new function.  The opposite end is commented code, where you obviously want more code commented.  Nested includes are a great way to alert the developer that adding a new include has all of a sudden added a long compile tool chain, potentially increasing your compile time and size of your system.  Tracking compiler directives is something, I think, is really useful–especially with platform specific code.  Compiler directives are a great way to give you visibility on how much you are using conditional compilation and hopefully, gives you a good understanding of the scope if a new platform is added.

Thresholds are the way to use any of these metrics.  For example, create a threshold that would throw an error if the number of functions per file is greater than 100.  Or,  first give a warning to developers when the number of functions exceeds 75 per file and then, if it goes over 100 print an error.  But what values should you use?  You can use the standard deviation to figure this out or use coding standard guidelines.  For example, many standards say that a method should not reach over 1000 lines or code, or the maximum level of include nesting should not exceed 8.

If you find that these metrics are not enough, start combining them.  Any good tool worth its  salt will let you customize these core metrics, so you can start creating your own calculations.  One example is using the lines of code metric with the commented code metric to create a calculation on the percent of comments.  We are all guilty of not documenting our code.  Use percentage of comments to make sure everyone knows when they are under the norm,  so if you have less than 10% of your file commented you get an error and less than 20% you get a warning.

Showing developers potential areas of concern will help them to be smarter at what they do and spend more time focusing on what they are good at–innovating.

So awhile back, I was begging for some good statistics on Agile adoption, since at that time, there really wasn’t anything substantial to sink your teeth into. Well, a new report from Forrester came across my desk, and it helped to strengthen what most people believe…that Agile processes have overtaken Waterfall as the development methodology of choice. In this report, which cites information gathered from a Q3 2009 survey of IT professionals, it states that 35% of respondents said that Agile most closely reflected their development process, while waterfall processes came in at 13%. I would even argue that iterative development could possibly be included in the Agile bucket, not because it is full-fledged Agile, but it is a baby-step in Agile’s direction. Perhaps I’m stretching things there…

Secondly, the data supports the fact that people are adopting the aspects of Agile that work for them and there’s no monolithic Agile implementation approach, something that is consistent with the many Agile teams I’ve spoken to over the last 3 ½ years or so. I’d be curious to know how many teams out there are doing , say, Scrum “by the book”…if there is such a thing.

Finally, the other thing that the report hinted at, that I have seen firsthand, is that while most organizations are not completely Agile today, they almost all have some groups that are. I honestly believe that the percentage of organizations that have small pockets of groups doing Agile development is very high…perhaps in the 80s or 90s. I don’t have any hard data on this point, this is more of a gut-feel, but I would be interested to hear from our readers as to what they think.

Spend 80% of your time on One Thing.

As a manager of a small tech writing team in an agile environment (are there any large tech writing teams left out there?), it’s easy to lose myself in how-the-heck-can-we-keep-up-with-myriad-coders-frantically-coding thinking.

So when my manager scheduled a meeting to ask what innovations my team has planned for the next release or two, I thought of a few choice responses, such as “Um… how about documenting the new features in time for release? Is that innovative enough for ya?” and “Innovate THIS.”

Eventually I calmed down, since he’s the boss, and I have a mortgage.

I looked at the presentation I’d given after our last research period, that oh-so-short breathing time between releases. I reviewed the precious feedback we’ve gotten from a few customers and thought hard about it. I felt a bit better when I realized several of the goals we’d set for ourselves were already underway.

I dutifully wrote up a wiki page (because I can’t think without writing) that summarized a bunch of initiatives under each of our themes: process, community, quality, coverage, usability, and media. And I decided whether they’d fit into this release or the next. And I sent it off to my manager before our meeting.

He said OK, but where does all this get us?

He called my list depressing. Death by a thousand cuts.

He told me that to be successful, you need to put 80% of your time or money into one thing.

He suggested creating completely different help for just one tool. Throw out the old stuff and start over.

Once I played devil’s advocate for awhile, I began to see where he was going with this. I suggested a tool that I thought would be a good candidate. So I think we’ve picked our One Thing for this release.

Here’s how I’m thinking about our One Thing so far:

• Make sure everything the user needs to know is accessible from one place.
• Target two very different points of interacting with the help: the getting started phase and the troubleshooting phase.
• Use media that are best suited to the user and the information that needs to be conveyed.
• Make the help interesting, fun and effective. Grab and keep the user’s attention long enough to convey what needs to be understood. Defuse frustration.

And again (annoyingly), my manager is right; it’s much less daunting to try to make one thing better than to try to make everything better.

Now to persuade a few of the developers to star in our walk-through video….

The last entry in my Going Agile series will look at the retrospective meeting.

The retrospective meeting is held at the end of every sprint/iteration, and it is the time to discuss what went well, and what could be improved in the next sprints. Some people will say the Product Owner should be in attendance, and some believe the PO should not. IMHO, the PO is a part of the team, and should be there…and in our case, I was. We weren’t sure how to solicit input from the team, so we decided that everyone should take a few minutes to write down their thoughts, and then the Scrum Master would read them out. This was a good way to eliminate the classic, “I was just going to say the same thing as Bob” response. After all the responses were collected, we realized we had 3 main things to address:

1)      Testing and documentation struggled…they were too heavily back-loaded

2)      Code reviews were determined to be essential but weren’t being factored into estimates, etc.

3)      Our team velocity was nowhere near what we thought it would be

From these things we made a few adjustments for our next sprint (again, these decisions were made by the team as a whole). Our developers stopped working on new stories 2 days before the end of the sprint, and would then focus on testing and documentation. This would help alleviate the avalanche of new functionality that would hit the testing and documentation team on Friday afternoons. Code reviews were added to the definition of ‘Done’ and were factored into to estimates.  For the 3^rd issue,  we found one of the key issues to be that developers just weren’t given dedicated time to code, and as such, could be interrupted at any time for an impromptu meeting, or discussion, etc. We decided to implement a Do Not Disturb mode for the developers, and if they had that DND sign up in their cubicle, or on IM, then they were not to be disturbed.

The retrospective is a crucial part of the continuous improvement process, and time must be dedicated to it. The first few are extremely important since that is when the warts are most obvious, but minor tweeking  may never stop.

I’ve enjoyed sharing my experiences about my first Scrum team, and I hope it may provide some ideas for your team. If you have any Agile/Scrum experiences you would like to share, I’d love to hear about them. Chances are others will stumble across the same problems at some point as well.

As Google Chrome climbs out of obscurity in the browser market and expands into a light-weight but fully functional OS, security seems to have become a top of mind issue over at chromium headquarters.

In the Chromium Blog, Chris Evans of Chrome Security announced a cash for bugs initiative, paying between 500 and 1337 USD depending on the severity for any previously undiscovered flaw.  I am glad to see Google encouraging the community at large to participate in hardening my current browser of choice.  As Chris points out, Mozilla was one of the first to embark on this type of program, but I am happy to see Chrome following suit.  Me and my online transactions appreciate it.

Hmm.  Maybe I should roll-up the sleeves and  invoke the  ”I’m gonna write me a minivan” approach and get the driveway cleared for the armored cash trucks.

But seriously, if you’re interested in helping out and getting a small reward for your efforts, visit the Chromium Security project.

Refactoring is a vital component for software developers, helping to prevent their projects from becoming unusable, and unmaintainable spaghetti code. Equally important to some developers, is the notion of refuctoring…check out this tongue in cheek look at Refactoring vs. Refuctoring. Be sure to check out the slide deck at the end.

Refuctoring describes the process of making your code unmaintainable by anybody but yourself.  I love some of the examples of Refuctoring such as “Pig Latin”, “Treasure Hunt” and my personal favorite “Stating the Bleeding Obvious”:

For example:

//initialize a to 1
int a=1;

Not that I’d ever do that (pause while I go clean up some code). Ahem, right anyways I thought I’d throw out some other refuctorings:

1.    “Catch me if you can” – Use so many goto statements that it will make anyone’s head spin.  Especially when you start adding backward goto’s.  Take a look at the CVS source code,  they have some nice (nasty) examples.

2.    “Giant tar pit of hell” – This is hard to blame one single developer as it really encompasses many developers getting together to create one big cohesive piece of crap.  You know you have a problem when you run out of printer toner trying to print these.

"Giant tar pit of hell"

3.    “WTF” – Using names that no one will know…ever.  If you create a bankaccount object, instead of calling it ‘x’, here’s a wild idea, why not call it ‘bankaccount’.  Let’s face it we are all guilty of this.

Now if you really want to be special (I don’t mean in a good way), try combining #1 and #3:

int afunction()
{

there:
   ...
   if(something)
   {
      goto here;
   }
   if(somethingelse)
   {
      goto there;
   }
here:
   ...
   if(somethingelseagain)
   {
   goto end;
   }
end:
...
return;
}

I have to admit, I’m not winning any awards either. It is certainly time to get on the refactoring bandwagon.