Isn't fun to be blamed for doing something wrong when writing code?  Nothing quite like having QA, or even worse a customer, find some major issue with something you wrote.  Writing software is a hugely personal thing; there is a tendency for developers to think of their code as reflection of themselves.  So when a big screw up occurs, the stages, not go all Kübler-Ross on you, go kind of like this:

What a strange name for a blog.

Less stress. More quality. Isn?t that an oxymoron?

A lot of people in software development today would say that one of these words doesn?t belong with the others. If you are going to create quality software, isn?t it a given that you?ve signed up (or been volunteered) for a lot of extra hours, headaches, worry, concern, fear, uncertainty, doubt, hassles, arguments, ulcers, and anxiety?

You know, stress.

While I have been known to keep an industrial drum-sized bottle of TUMS on my desk during various projects in my career, over the years I have learned that there are ways to deliver high quality software and still keep your stress level within reasonable bounds.

It?s not always easy, but it is possible. Most of the time.

This blog will focus on what I?ve learned about creating quality software with less stress. You won?t need your antacids if you have the following available for your next project:

• good practices
• great tools
• a little fun

Good Practices
I?m not a fan of the phrase ?best practices.? Don?t get me wrong, I have no problem learning from the successes and mistakes of those who have gone before me. Good software engineers, testers, and managers have sacrificed evenings with the family, their waistlines, and their next promotion to bring us hard fought knowledge of good ways to solve the software development problems that plague us.

I just don?t believe in a one-size-fits-all solution.

What works best for two programmers in a garage won?t necessarily be the best solution for the team at NASA working on a Martian explorer or a Hubble Telescope. Show me good ways others have solved similar problems and I?ll pick the best solution for my current situation.

On these blog pages, I intend to share what I?ve learned about creating quality software. In return, I hope you will share what you?ve learned on your own projects with me.

Great Tools

What can I say? There?s a reason I wanted to be the product manager for the best family of issue and defect tracking and test case management tools on the market. I love my products! I was a user and fan of TestTrack long before I joined Seapine.

Stop by these pages for tips on how to use TestTrack Pro, TestTrack TCM, and TestTrack Studio to implement your good practices.

A Little Fun
Some days we all need to be reminded to breathe deep and smile. (The light at the end of the tunnel isn?t always an oncoming train.)

Stressed-out, unhappy people make bad decisions. Bad decisions make bad software.

Good practices implemented with great tools make quality software. And nothing reduces the stress in your software development life like producing quality software.

I hope you can visit each week. I?ll be doing my best to fill these pages with good practices, great tools, and a little fun that you can use on your projects.

We?re investigating adding an annotate/blame feature in Surround SCM. If your not familiar with this concept, it allows you to mark every line in a file with the date, version and person who last changed it. For example, if the current version of your file looks something like this

int bar;
bar=7;
bar++;
if (bar>7)
    printf(?Big bar?);

The after running annotate, it might look like

Version     User        Date
25          gatesw     1/12/2008   int bar;
23          gatesw     2/25/2007   bar=7;
25          gatesw     1/12/2008   bar++;
8           ballmers   1/11/2006   if (bar>7)
7           gatesw     5/15/2005        printf(?Big bar?);

In looking at this feature, I discovered there was some ?unease? about it, specifically around the name. It centers around that blame word. No one likes to be blamed for something. No one wants to play the ?blame game?. ?Let?s not finger point, let?s solve problems!? Blech. I think I threw up in my month a little just writing that.

Early on it seems to be generally called blame, but later systems started using the name annotate. Much nicer. While the actual name might not be critical, how people use it is and I think the “blame” word makes more sense.

I?ve used functionality like this (or simulated it) for a while, and I have to say it was most often for  blaming someone. I saw some code, and I wanted to find out who was responsible for it. Often it was to have a reasonable discussion. ?Can you help me understand what this code does.? ?We?re not using that approach any more, can you change it.? Certainly there were occasions when it ran more along the lines of ?Who?s responsible for this mess?? or ?Who dared to touch the perfection that is my code??. Though, as the title of this post reminds, just because someone changed something it doesn’t mean the problem you’ve run into is because of that change.

You can certainly use this kind of feature for code reviews and related activities to understand the history of file. But I believe that the primary use case is when you see some changes that you question and want to track down the responsible party.

I don?t think there is any issue with that, and thinking of this feature in that way may drive different functionality than assuming it?s most often used for code reviews and such. For example, if the primary use is for code reviews, then you might want to really make sure you have excellent printing and exporting capabilities. On the other hand, if blame is your game, then you want to make sure it?s very interactive. You might want to easily see what other changes went in with that version. What other files were changed by that user at the same time.

I guess we could call it “responsibility”, but that doesn’t exactly role off the tongue either. The fundamental question still remains, though. What is the primary use for functionality which allows you to identify the person who last modified a set of lines in a file?

I?d be interested in peoples feedback on how they might use this. And if you don?t like how we implement it, please don?t blame me.

A few months ago we started our Quality Ready Assessment (QRA). This is a straightforward web tool to help companies and individuals measure their overall software quality level by asking them a short series of questions around overall application lifecycle. Companies who take this get a customize assessment, and internally we look at anonymize trends in the data.

We?ve gotten a tremendous response so far, and we continue to slice and dice the data to better understand how people who work in and around application development get things done. As a starting point, I?ve looked at the data for SCM usage and found some interesting trends.

The first one that jumped out at me was that 59% of the organizations have an SCM tool that does not support notifications and triggers. This means people are wasting time, plain and simple. This is a classic pull versus push model, where the ?puller? is a human needing to know when changes have occurs. Anyone who’s been in the car of a family vacation nows how unsatisfying that kind of ?Are we there yet?? conversation is from both sides. Far simpler is to get a call when something has changed.  A simple example of how I personally use this is to have Surround send me an email whenever one of the design or requirement documents change. Since the email includes the name of the file, the comments the person made when checking in the file and even a direct link to the file in Surround I always know when changes happen to the documents I care about.

Another fascinating one is that 55% of organizations have no integration between CM and their issue management solution. Being able to check in code and link that code to the issue that it addresses makes everyone more productive. Developers can mark issues as fixed as part of their normal workflow. QA engineers can see what parts of the application has changed to make their work more targeted. The whole organization is able to learn over time, rather than relying on memory (?What did you do to fix that bug last year??,?Something with file handling. I think it’s in Foo.vb. Or maybe Bar.vb. Or something like that?.)

Something that won?t surprise anyone is that a recent SD Times survey found the top two SCM tools were SourceSafe and CVS, both of which lack this kind of functionality. While cheap is nice, the time it takes everyone on your team to manually work around these short-comings dwarfs the cost of any tool.
Grant has some related data that show, again to no ones surprise, that companies that use tools with these kinds of shortcomings suffer in the quality and schedule department as well.

The title of this post is the same as an episode of the TV show West Wing, and refers to Franklin Roosevelt’s bold plans for America?s effort around the WW II. Every good company should make big plans for their product. But asking people to achieve them using SCM tools without capabilities like notification and two way integration with issue tracking is like making 100,000 planes using hand tools. You could do it, but it sure isn?t very efficient.