Blog

Squashing bugs, it's part of the job

Squashing bugs, it's part of the job

Squashing bugs, it's part of the job

Software bugs are part of the process

Software bugs or “defects”, unfortunately are a standard part of any software development process.  As a consultant my customers have varying levels of understanding and experience with what bugs are and the expectations of their existence.

Every software product has problems.  Some bugs may completely crash a system. These issues are pretty obvious, typically a nasty screen shows up and it’s clear to everyone that a problem occurred.  Then there are varying degrees of bugs that may just affect some underlying data that won’t be found for a couple, days, weeks or months.  Those types of bugs may not be obvious to anyone initially but are far worse then a bug that obviously crashes.  Other problems may not even be a problem or cause any negative affects but are still considered to be a defect.  Some issues are defects because the feature worked exactly how the developer programmed it but it wasn’t actually inline with how the user/customer expected it to work.  All of these issues are part of the software process, the goal is to try and catch them fast and preferably before they are in a production environment. But, all these problems exist at some point, even if they never make it to the end user.  Developers find and fix hundreds of bugs before anyone else even uses the system.  The amount of bugs that are found and fixed before it leaves the programmers desk is very high.

Simplified and not taking in to account any test driven development practices a developers flow usually looks like this:

  • Wrap your head around a feature. Try to understand what it needs to do and why it needs to do that.
  • Try and think of an intelligent way to implement the feature that will be easy to use, simple as possible to code and provide the least overall system complexity changes.
  • Think of the possible ways this feature could go wrong, or what people could do to break it.
  • Write a little bit of the feature.
  • Test what you have written.
  • Find bugs, fix bugs, test.
  • Write some more of the feature.
  • Find bugs, fix bugs, test some more.
  • Repeat until the developer feels the feature is completed.
  • Submit for Quality Assurance review.
  • Bugs / issues found – comes back to the developer to resolve.
  • Submit for QA – repeat as needed. 
  • If everything is good deploy to a testing / staging server – have the customer try it.
  • If everything is good deploy to production.

Bugs are constantly being squashed and a development team is trying to work towards 0 bugs when deploying to production but the amount of issues that did and could exist are high.  It’s rare that everything is found.  Especially on larger systems when a new feature is released and the developer and QA are testing that feature but not necessarily every other feature in the application.

The developer may have built a feature to show a graph of product sales.   2 months from now you may add a feature to allow users to add product credits or negative numbers in the system. Your graph could potentially crash now because of the negative numbers.  But, when you were originally programming it you wouldn’t have necessarily thought a sale or product value could be a negative number.  It’s also something the QA team may or may not have thought to check.  For some systems it is not practical to have someone manually review each feature for every new feature that is added.

Experienced/better programmers can see more ways a possible feature could have bugs and build tests and program more defensively to account for those potential bugs.  With more time programming you have seen more issues, you have fixed more issues and you can better predict future issues. 

However, bugs still exist – bugs still get into systems and bugs still make it to production. Great teams strive to write code that tests code, catch as many bugs as possible internally and fix found bugs quickly.

Bugs will come back up in a future blog post that goes more in depth on software complexity.

 

 

Photo creative commons: http://www.flickr.com/photos/jganderson/3760139388/


Post Rating

Rating: Article Rating

Post Comment

comments powered by Disqus

Keep up to date with the latest happenings by signing up for my newsletter. This will be monthly at most, so go ahead and learn something today!

My Ventures

view all »
  • Web Ascender

    Web Ascender

    Web/Mobile design & development.
    Learn More »

  • Post Kudos

    Post Kudos

    Mobile App for client testimonials and customer reviews.
    Learn More »

  • File Ascender

    File Ascender

    Easily upload and share files from anywhere.
    Learn More »

  • DNN Spot

    DNN Spot

    High quality, easy to use, accessible and search engine friendly modules.
    Learn More »

My Books

view all »

Executive Guide to Web Design

This book is designed for business executives who want to learn about critical factors that affect your businesses website and online marketing. After reading this guide you will be comfortable working with your web design firm, marketing department and steering the direction of your company's online success.
Learn More »


What Internet Startups Need to Know

Are you interested in making the next big thing? Do you have a great idea, know your industry, and have a good way to get your product into the hands of others? This short e-book will go through the primary things to consider when evaluating and executing on your web or mobile application startup.
Learn More »


I Speak!

I do presentations to small local groups as well as Fortune 500 companies.  I have been requested to speak about:

  • Entrepreneurship experience
  • Running a small business
  • Using Social Media to improve your business
  • Personal branding
  • Internet Marketing
  • Web design and internet trends
  • Numerous programming topics

Contact Ryan Doom »