Effective Bug Reports Require Good Communication

"If I went back to college again, I'd concentrate on two areas: learning to write and to speak before an audience. Nothing in life is more important than the ability to communicate effectively."

Gerald R. Ford

With all of the advances in science and technology it seems that one of the basic skills that many have difficulty with is communication. This causes a serious challenge at the workplace because communication is a basic building block required for just about everything we do.

For instance think about the last project you worked on. Whether you were gathering the requirements with product owners, working with the creative team designing the user experience or working with the technical team building the architecture and code - this all required one common denominator: good communication.

One area where poor communication causes a lot of problems for a software project is bug reports. Good bug reports that communicate effectively to a developer can make a big difference.

"It doesn't work."

How often have we looked at a bug report  and the only information there is something like "It doesn't work", or "it's broken".  If you want to quickly drive your software developers to Lovecraftian madness then please keep creating bug reports like this. Poorly written bug reports kill productivity. 

Think about it, if you were to bring your car to a mechanic and say "it doesn't work" how would they be able to diagnose the problem? You would need to tell the mechanic what the problem is, details explaining how you observed the problem and what you expect. In a similar way a good bug report should do exactly the same.

Therefore if you are pragmatic and want to improve in this area then communicating well in bug reports is essential. So what makes a good bug report? In simple terms one that clearly explains what the problem is, how did it happen and what was expected to happen. If a bug report  does not satisfy all of these criteria in a concise, simple manner then it has failed.  The following is a check list for an effective bug report:

- Short Summary

- Steps To Reproduce

- Expected Behavior

- One bug per ticket

- Include Test Data

- Provide Screenshots / Screen Cast

ServiceStack IOC Autowiring by Convention

A situation came up where we wanted to implement a convention to auto-wire many of our classes using ServiceStack IOC. Basically we wanted to eliminate the need to hard-code mappings over and over for every class in a bootstrap file.

For example we wanted to avoid this:

container.RegisterAutoWiredAs<MyType1,IMyType1>();
container.RegisterAutoWiredAs<MyType2,IMyType2>();
container.RegisterAutoWiredAs<MyType3,IMyType3>();
container.RegisterAutoWiredAs<MyType4,IMyType4>();
...

To achieve this we can use .net reflection to scan our assemblies and look for a special interface that represents classes we want to automatically inject. Then we can utilize the ServiceStack IOC method RegisterAutoWiredType to register the types during runtime.

Here's an example where IInjectable is the interface we use to identify which classes will be injected:

Dependency Injection of Multiple Objects Same Interface using StructureMap

I have been reading Mark Seemann's excellent book on Dependency Injection & applying what I have been learning to StructureMap.

Often times I have multiple objects that implement the same interface. In the past I may have used an abstract factory to create the instance I needed at a given time based on some sort of key or identifier like so:





However I was interested in using an IOC container like StructureMap to get rid of the ugly switch statement with the factory object. I did so by registering each object in my container and giving it a name with the .Named() method like so:

If you would like to see more please check out a simple example project over at my GitHub called MultipleObjectDemo.