Johnny Halife’s Blog

While attending some CMMi courses that we held at Southworks, and reading some papers about re-work written by Watt Humphrey and the CMU-SEI crew, I started thinking about how to avoid rework and what do I do to avoid re work while coding.

I realized while asking myself a couple of questions and analyzing the code review results for the reviews I conducted that most of the people make the code work, check the code in and then start caring about the quality of that code. For example most of the people check in code that doesn’t meet the code standards and then they do another check in in order to fix those.

I came up with 10 do’s and don’ts while coding that helped me understand how to avoid rework and ensure the health of our deliverables on every check in.

10 Do’s and Dont’s to avoid quality rework

These do’s and don’ts aren’t a silver bullet but they may help you as a strong starting point for avoiding rework on quality related subjects.

Do check-in often

As Alex always says Software Development is a team sport played by talented individuals. While you keep your code in your local machine you’re also putting a barrier between your work and the rest of the world’s work. Doing check in often helps you on integration, avoiding conflicts and even better gives the team visibility on where are you in terms of what you committed to do. In the other hand if you don’t commit often, be prepared to spend half a day fixing the code to avoid conflicts.

Do run StyleCop each time you modify a source code file

Code Standards are something big to be treated on another post by itself but as summary I’ll say that in Southworks we chose the working software over the comprehensive documentation as the Agile Manifesto states.

We have chosen to use Microsoft’s StyleCop to validate our code standards. Most of the code that we write often goes public, and it’s important to demonstrate that we follow a single line of thinking and the code has signature that differentiates it  from others code but also that the code is written in the same way by all the developers on the company.

In order to accomplish this, is as simple as doing right click on the source code file in Visual Studio and then Run Source Analysis. It won’t add an overhead to your regular coding routine but will ensure that the code is written on a consistent fashion the first time.

 

How to run source analysis

Do run Code Analysis prior every check in

Code Analysis (a.k.a FxCop) is the tool that validates the best practices of the Microsoft.net Framework. It’s based on the book written by Brad Abrams and Krzysztof Cwalina. The best practices described there were ported to an application known as FxCop.

Following Code Analysis guidelines ensures that our code is leveraging the Microsoft.net framework in the best way it can be done. And the same as Style Cop (a.k.a Source Analysis) it can be done by doing right click on an assembly in Visual Studio and then choosing the Run Code Analysis option from the context menu.

Again, doing this the first time is better than reworking the code and re committing to the main line twice in order to do it and then to fix it.

How to run Code Analysis.

Consider branching out code that may introduce risk to your deliverables

This is pretty obvious, sometimes you think a problem can be solved using some kind of approach that might have an impact on others work. The solution there is to branch the code out and don’t introduce the risk while you’re not sure that this will be the final solution or at least that your solution works.

Why is this? Some people might choose to keep it outside the source control but experience tell us that no source control will turn into something painful if something happens.

I’ll write another post about GIT which leverages this by having a local repository for each developer but that’s another story.

Do not forget the commit message

Look at the log above what can you tell about what’s going on on the project? If you don’t include a comment, a note, a reference to a requirement or something that states what are you committing you can get your team in trouble if you have to do any rollback or review of the requirements implementation.

It’s a 1 minute thing to say what are you committing and why are you committing, that also forces you to think what problem, requirement or commitment are you closing with that check in.

Do be polite with the Integration Server

This one is loved by my friend .jpg who is our Build Server & Tooling ranger. People often get confused with the intent of an Integration Server. The Integration Server is used to verify that there’s harmony in your repository, it’s not your tool to validate your code against. You should verify your work against it but don’t use it processor cycles to do your validation work.

Our build process is complex enough that might take at least 2 minutes to build a project, people often think that is the Integration Server responsibility to validate your process. Truth to be told, the intent of the Build Server is just to verify that there’s no integration problems and that all the code follows a standard.

Although the quick feedback is the most important part of the build server, you should have in mind that is a verification of work and it doesn’t do the validation you’re supposed to do.

Do not check in prototype quality code to your main line

I won’t go further on this one, I recommend you to read I.M Wright’s post about Prototyping that he just posted. As an spoiler I can tell you that the title gives a clear message “My experiment worked!”.

Do not check in until all tests pass

This one seems pretty obvious, I wrote a post about TDD last week and most of the people nowadays are adopting this practice. The important thing and a killing feature of TDD is that you are a click away of doing regression testing on all the code and check that nothing got broken with your changes.

Sometimes you get green on yours and then just wait to the Integration Server or another developer to complain about your work. This is the case where you should be polite not only with the integration server but also with your co-workers making sure that nothing is broken because of your changes.

NOTE: If you are running a huge solution with thousands of tests you might want to run just those hundreds tests on the impact surface of your code.

Do ad-hoc peer reviews to validate your logical thinking

Two pair eyes of eyes see better than just one. That’s the rationale behind this point. Developers (and I include myself on the subset) love to put their headphones, enter their matrix kindda world and write code as the music moves forward. But as I said on the first point Software Development is a team sport and a team that cooperates is by far more candidate to win.

Do not wait until the formal Code Review comes up to you and you have to explain what you’ve done. Just put pause on iTunes for 5 seconds, ask your nearest team member (doesn’t matter his expertise always there’s something good to learn from our peers) what does he think about your idea and that’s it. You just had a peer review.

Do be consistent and disciplined while applying the nine practices above

Now you know it, but the practice makes the master. Fasten your seatbelt and get ready to improve your personal development process. You and your team will be happy to share a principles in terms of quality so your code is nice, easy to maintain and well written.

And your team as all the famous painters will have a code signature that will distinguish yourselves from the rest of the mere mortals.

 

 

 

And in the end….

One thing that I’ve learnt from people that have years working on Software Quality and people that I met like Eric Brechner (Microsoft Engineering Excellence Director) is that the most important thing when talking about Software Quality is defining done. If you follow these simple steps you will be closer as a team to produce code in a standard and consistent basis while starting to define the meaning of done for code.

thanks,
~johnny