Not all bugs are equal

The term ‘bug’, is widely used in software development circles, to describe a fault, or defect, in software. Your average dictionary will confirm that the word itself has many meanings, and usages, in the English language. It is because of this wide usage, that I find it strange that the word has been embraced so readily, by software professionals. A developer claiming that their code is “bug free”, gives the wrong impression that the software is perfect, regardless of the many other criteria that need to be meet before ‘perfection’ can be achieved. During testing, Product A was found to have significantly fewer bugs than Product B, yet Product A poses the far higher risk due to the nature of the bugs found.

Perhaps we should introduce the concept of ‘nasty bugs’ and ‘cute bugs’? Maybe not, but we should definitely consider using different terminology, to describe software faults, and crucially, understand the impact, that different types of ‘bugs’ will have, on the quality of our software.

Comments

Post a Comment

Popular posts from this blog

All new developers should read this book

Image
I read this book a number of years ago when I was a junior developer in my first job. At the time I had about one years experience developing web applications (Classic ASP, JavaScript, CSS, and HTML) using knowledge I’d gained at University and anything I could find on the internet. Keen to keep up with the latest technologies our development department decided to use, the then newly released, Microsoft ASP.NET. To help smooth the transition, from Classic ASP to ASP.NET, we were sent on a “suitable” week-long training course. Eager to employ our newly acquired skills we returned from the course and went to work hacking together ASP.NET applications in the same, mostly non object-oriented, fashion. Soon after, a new senior developer joined our team and upon recognising my limited object-oriented approach, and complete lack of design pattern knowledge, suggested I read this book. I highly recommend this book if you have: Little or no object-oriented, or design pattern, knowledge. 
Read more

Requirements Change is not an excuse

When was the last time you developed a product and knew all, and I mean all, of the requirements, before you started implementation; never? That’s right, requirements change, they always change. If you’re developing a product, for yourself, and you’ve created your own requirements, chances are you’ll change what it’s required to do, whilst you’re actually developing it. This is only natural. As you spend more time on a project, you should gain a better understanding of what you’re trying to achieve and how best to achieve it. This holds true when the product requirements come from somebody else. Developers are often asked to develop a product, based on a set of loosely thought through requirements, only to find that the requirements change, when more thought is given to the idea (often as a result of the developer asking for more information because the original requirements don’t make sense). Because requirements always change, it is not reasonable to use this as an excuse for late
Read more

The Beginning

I've been a software developer for about 7 years. I've enjoyed it, mostly. I've learned a lot. I’ve worked pretty hard but I’ve never been one for working long hours. I value my   spare   time too much. I recently,  officially,   started a new role as a program manager. The role, actually, isn’t quite that clear cut (are they ever?) as it involves some line management responsibility also.     I’m going to use this space to document my thoughts on software development
Read more