QA should find nothing.

When a bug slips through and makes it into production the tester often takes the blame. Developers often just shrug and say QA should have caught the bug. However I feel it is the developer should take more responsibility.

It is a developers job to ensure that his code does not contain any bugs.The tester's job is to verify that the developer has done his job. If a bug is not caught both have failed.

 If a developer throws his code over the cubicle wall as soon as he gets his code to compile their will be a price to pay. The first price with be the testers lack of trust in the developers ability to modify code without introducing new bugs. So the next time the developer comes across code that requires serious refactoring he will hear the tester scream. "If it ain't broke don't touch it".

The developer should view every bug a tester finds as a failure and think about what he could do to ensure that a similar bug does not happen again.

High code coverage + low cyclomatic complexity = quality code.

I have often heard and agree with the statement that 100% code coverage does not guaranty quality code. However, if you also monitor cyclomatic complexity of your code you will greatly increase the probability that it is problem free. If any method does not have 100% coverage or has cyclomatic complexity greater that 7 it should be suspect. The tool that I currently use for cyclomatic complexity is Code Monitor www.campwoodsw.com/sourcemonitor.html

Debugger Driven Development

I have just discovered a new way of doing TDD and I am calling it Debugger Driven Development.

This is how you do Debugger Driven Development.
1) Write a test which calls some method that does some complex calculation.
2) Add an assert statement with a null expected value.
3) Run the test in the debugger get the actual value returned by the method and use it for the expected value.


Debugger Driven Development is just so wrong. It does have some value for regression testing assuming your code is correct but it will cause big problems if it's incorrect. What you should do is always calculate the expected value by hand. That way if the value returned by your program matches your hand calculation their is a high probability that your code is correct. Doing Debugger Driven Development proves nothing.

Encapsulate complicated or generic code

Whenever you come across code that is more complex or generic than it needs to be try to refactor it. However it may not be possible to do this in some cases. When that happens just wrap the complex code with your own class that has the interface that you wished you had to work with.

Here is an example

The following code calls gateway.GetProducts(criteria) to return an array of products. Notice that most of the code below is just used to set up the criteria object.


ICriterion salesDateCriterion = new SalesDateCriterion(newstring[]{uploadDate.ToString()},
OperationEnum.Equal);
ICriterion prodLineIdCriterion = new ProdLineIdCriterion(new string[]
{productionLineId.ToString()},OperationEnum.Equal);
ICriterion productNoCriterion = new ProductNoCriterion(productNo.ToString(),
OperationEnum.Equal);
ICriterion[] criteria = new ICriterion[] {salesDateCriterion, prodLineIdCriterion,
productNoCriterion};

IProduct[] products = gateway.GetProducts(criteria);

if (products.Length != 1 || products[0] == null)
throw new Exception("Product not found");

return products[0];


For my application I did not need the power that criteria gave me I only needed to find a single product by uploadDate, productionLineId and productNo. So I just wrapped the above code in a method called GetProduct. Now the client code now contains a single line of code that is much easier to understand.

public IProduct GetProduct(UploadDate, productionLine,productNo)

In the newly created class I also added two similar methods GetVariety and GetOrder.

public IVariety GetVariety(int varietyNo)
public IOrder GetOrder(DateTime uploadDate, int productionLineId, int productNo)

Microsoft Advertising Ruby On Rails.

Today I went to Microsoft’s ASP.Net website and was surprised to find it advertising Ruby On Rails.

"Experience the latest release of the most productive and powerful development tool and user interface platform on the planet."

However those guys at Microsoft screwed up the images and download link. The download link pointed to ASP.NET 3.5 instead.

IThis, IThat, ITheOther

I have seen projects where every class had implemented an interface by default. The interfaces always had the same names as the classes except they were prefixed with an (I). I don't call this good design. The flexibility that an interface gives you has a cost. If an interface is not paying for this cost it should be removed. Only use interfaces when the flexibility is required. It is often difficult to tell in advance where this flexibility is needed so it is usually best to add an interface when the flexibility is required. Also instead of using the (I) prefix I prefer to name the interface by how the client will use the class. So instead of creating and IBook interface for a Book class, I could create a Readable interface instead. Removing the last trace of Hungarian notation from my code.

Singleton Anti-Pattern

The Singleton pattern is probably the most over used design pattern there is. Singletons are the same as global variables and make object collaboration less visible. They violate the Single Responsibility Principle mixing an object with its creation logic. They also create difficult to test code because they bind you to the exact type of the Singleton object and Singletons persist state causing test order to be dependent.

A Singleton object should be rarely used and when used it should be only used to solve a performance issue or as a last resort when parameter passing becomes very difficult.