How do you measure and improve defect rates?

It's probably been mentioned a thousand times elsewhere. defect rate to me is essential to understand. It's effectively how much time do I spend developing code compared to how much spent fixing it. The essence being if I wrote it right first time then I wouldn't have to keep going back to fix it. I've read many articles before that talk about how to write things right first time. I've put the ideas into practise and by jove they worked. 

But why have defect rate as a performance measure in the first place? 

Well because if you don't make something a priority it often gets forgotten above other priorities. You also have to still make sure this priority gets implemented but essentially I tell people my defect rate is low. This means I have to match that statement in what I do. Yet it gets me other currency. Customers are willing to wait longer for something that works first time than something that's buggy. They chose me over other suppliers because they trust my work no matter what the price. if I say it's going to take longer than they'd like they still accept my terms and don't go elsewhere. Why? because by focusing on defect rat, being honest about it and making it core the customer knows what he/she is getting and they have confidence that when the solution is delivered it will work. 

I've also found that by focusing on low defect rates I began acquiring and developing tools to elicit defects in theory and design before they emerge. I've learnt from experience that a badly thought out plan, one that hasn't been reviewed by enough people who are in the right places will lead to defects. Mainly becuase you'll have to keep changing your plan as the bad design becomes apparent. Thus I prefer to express my interpretation of any clients requests in as many ways as I can given my available resources. That way I've done everything I can to make my intentions clear to my clients. They can see what I am planning to develop and try it out in various ways at their leisure.

This approach encourages discussion, or at the very least insulates me from a lot of liability. By doing this early I've made it clear what will be designed. If a customer comes back very late and asks for changes I then have a strong position to explain this should have been done earlier in the process. A lot of work has been done now and the cost of changing it needs tobe discussed. 

Of course change is common and to be expected. Again that's where you need to plan and built tools and processes into your methods. Every client on every project has asked for changes at different times. If you can't adapt and maintain quality then you need to learn. There are plenty of places to find out how to do this and plenty of different ways of achieving it. But if you don't even accept that change is normal and make adapting to it a priority then you're kind of doomed to failure. Atleast on the defect rate.

so how do you go about ensuring a low defect rate?

That's a big question. I don't intend to go indepth here. The point was to argue why it should be a key aim. In essence it's about understanding the resource you have, the features you're developing and the impact they're gonna have. You've then got to realise the exponential impact of any feature development on everything else. Literally the butterfly effect applied to code. A change in one line in a script in one component could affect the ability to log in elsewhere. 

A low defect rate in practice means being expert and identifying and fixing bugs. Don't let the customer identify them for you. Be good at solving them before they go out. This means you need eyes in the back of your head. Or, in reality tools or scripts that can tell you whenever a bit of code is not working right. Whether it's a full blown set of unit tests or just a simple script that runs through the basics. That's your decision. I'm very practical so I always start with small simple scripts that test key areas that I can run any second I like. 

I then literally test all the time. It's so much  easier to fix a bug when you identify it early. So I want to know the instant I've caused a problem. That means I know that the change or changes I just made caused the problem so I already know where to being looking. 

This also implies that I can roll back and forward my changes to remove and create the problem. That's generally the heard of good bug fixing. 

Any way I didn't want to go on here about exactly how to address defect rates. I jsut wanted to show that I've found that using it as a performacne measure with clients helped me

I should in time link to the other posts I've written on this topic to bring it all together