Bad code is like a virus, don’t let your repositry get infected

Bad code is like a virus, once it infects a code repository it starts duplicating itself everywhere until the all the code is corrupt – Hosk

I have written a few articles recently about code quality and why it’s so important to create and maintain quality in your CRM projects.  If you want to learn more read the three blog posts below

• Why your CRM code and customizations should be simple
• The problems with complex code and complex CRM Customizations
• Why rushed projects/code doesn’t save time and reduces quality

Bad code is like a virus

Bad code is like a virus because I believe bad code replicates and will start to tightly couple code in other parts of the system.  The reason bad code replicates is due to drop in standards, when a a developer see one person creating quick and lazy code they think believe it’s acceptable for them to start checking in poor quality code.  The bad code heap starts to build and then when

The bad code heap starts to build and then when a different developer fixes a bug, he calculates refactoring the code will take a long time because other developers haven’t done it.

If the no poor code had been checked in, the CRM developer would see all the code checked in is to a high standard, they understand the code in this project should be a high standard and the developer will follow the herd and check in high quality code.

If the code repository has been infected the CRM developer will see it’s OK to check in poor quality code and the easiest action for the CRM developer to take is the quick and easy fix, which is of lower quality and will cost you more time in the long run and make it harder to change the code in the future.

If bad code has already infected the repository it makes further changes to the code more difficult because complexity of the code will be increased.  The time and effort for the developer to simplify the code and refactor is increased because the CRM developer not only has to add the proposed fix but additionally the CRM developer would have to refactor the previous poor code checked in.

Refactoring lots of code to make your high quality change is a barrier to checking in quality code.  To encourage high-quality code you need to remove as many barriers to creating high-quality code and customizations as possible.

As the cost in time and effort of refactoring go up, developers will add more bad code, meaning the bad code is like a snowball being rolled in snow, it just gets bigger and bigger.

The way to combat this is to make sure no one lets the standards drop and no one checks in poor code.

Do the code right, do it right first time and don’t let your standards drop.

Broken code theory

You should fight hard not to let people check in poor code because I have a view there is the broken code theory

it’s similar to the broken window theory

http://en.wikipedia.org/wiki/Broken_windows_theory

The broken windows theory is a criminological theory of the norm-setting and signaling effect of urban disorder and vandalismon additional crime and anti-social behavior. The theory states that maintaining and monitoring urban environments to prevent small crimes such as vandalism, public drinking and toll-jumping helps to create an atmosphere of order and lawfulness, thereby preventing more serious crimes from happening.

The Broken code theory is

Maintaining and monitoring code repositories to prevent bad code practices such as huge methods, magic numbers, duplicate code and tightly coupled code, it creates an atmosphere or order and code simplicity, there preventing more serious code crimes from happening.

Here is a list of the coding crimes we need to prevent

• monster methods
• badly named classes, methods and variables
• duplicate code
• Methods which do many things
• poorly structured code
• magic numbers/hard coding
• tightly coupled code

When developers believe it’s not ok to check in bad code and no other developers on the project are checking in bad code then it keeps standards high.

One of the reasons is people have a herd mentality and although some CRM project managers may disagree, CRM developers are human

Humans Naturally Follow Crowd Behavior

Herd Mentality

Once the first piece of bad code gets into the system, other developers can sniff a drop in standards and will think it’s ok to write and check in bad code.

The best way to stop bad is to not let developers check it in and detail what is expected of them.

Stopping bad code getting into a repository

• Code Reviews
• Unit test
• Best practices document and make developers stick to them
• Style cop/FX Cop or other automated code review tools

Code Reviews/Peer Reviews

Code reviews which are sometimes known as Peer reviews is the number 1 way to stop poor code being created in a CRM project.

If a CRM developer knows a senior or another developer is going to review his code, this is usually enough to stop him checking in poor code.

The threat of his code being checked is enough.

There are numerous benefits to code reviews

•  Bugs are found faster
• Great way for junior developers to be learn
• Code quality is kept high
• Optimization methods and processes are learned by more members of the development team
• The code is more readable
• The reviewer learns about more parts of the CRM code (not just the parts they have written themselves)
• The code is checked against the company CRM coding standards document

Coding Horror has an interesting blog post titled – Code Reviews Just do it

This quote comes from the blog but also the great book Code Complete 2

software testing alone has limited effectiveness — the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent

I believe any steps to find bugs before the code leaves the DEV environment will not only save time but will also result in fewer bugs being found by the end users, which will give them more confidence in the CRM solution.

Write Unit tests

It’s difficult to write effective unit test for poorly written code.  The reason for this is because poorly written code is complex and the methods do many things.

When CRM Developers have to write unit tests as part of the development process they will start to create code which is easier to test

Code which is easier to test is because it’s simple and not tightly coupled.  This code will be easier to read/understand.

Writing unit tests will reduce the number of bugs which make it into production and you will be able to run the tests after you make any changes to the code.

Best Practices Document

I’m sure most CRM Developers probably have some kind of awareness of a CRM best practices document, a few of them may have even read it but how many CRM Developers make sure all their code adheres to it?

A code review would certainly ensure CRM developers are implementing best practices but if the development process doesn’t involve peer reviews then management/senior developers need to make sure CRM developers know they are excepted to write code to a high standard and follow the best practices outlined in the best practises document.

This message has to come from the senior members because unfortunately a lot of CRM developers will do the minimum required, so it has to be understood the minimum is sticking to the best practices outlined in your companies CRM best practices document.

Benefits of sticking to the best practices is it will bring some code consistency to CRM projects and common coding errors can be avoided.

Automated code analysis tools

A step further to implement best practices is to use and configure an automated code analysis tool.  This will analyze the code and create a list of warnings for the CRM developer to resolve and in some ways it’s a low standard code review.

There are lots of different code analysis tools but below are three popular ones

Resharper

FX COP

Stylecop

Summary

One of the continuous tasks of a CRM developer is to manage complexity and constantly strive to make their code as simple and as readable as possible, this makes maintaining, debugging and extending the code easier.

In a level above this is the overall quality of the CRM solution and project.  Keeping quality high is a state of mind/attitude.

This quote encapsulates the effects of keeping quality high

A rising tide lifts all boats

This quote is explained by wiki as this

The aphorism “a rising tide lifts all boats” is associated with the idea that improvements in the general economy will benefit all participants in that economy

If the quality of the CRM code and customizations is kept high by peer reviews and reminding developers to adhere to best practises then all the CRM developers will check code of a high standard because the expectations and performance of the other CRM developers code is a high standard.

The difficulty to keeping high standards when code gets rushed by customers shortening delivery dates, the only way to hit shorten delivery dates is to miss out development processes and the usual sacrifices are code reviews, unit tests.

This will reduce the quality of the CRM solution (read more in this article – Why rushed projects/code doesn’t save time and reduces quality).  The other danger is it can be seen by the CRM Developers as a signal to check in power quality code.  With every line of bad code added, the refactoring and restoring the level of quality becomes harder and more time-consuming and ultimately less likely.

The best method to stop the quality of the CRM solution reducing is to stop any bad code being checked in