Welcome to MSDN Blogs Sign in | Join | Help
Shipping is a Feature

There is a world of difference between a successful product and vaporware: one exists and the other doesn't. Both sound the same on paper, both have incredible features, ambitious goals and both teams will work very hard in finding and fixing bugs. The difference, however, isn't very obvious. The successful product team will cut features early and decide not to fix a certain set of bugs later in the cycle. The vaporware team will push through their set of features insisting everything get implemented and later never "not fix" anything. And so the successful team will ship a high quality product with a good set of features where the vaporware team will keep working on their ever growing feature set, never cut anything and try in vain to fix every last bug that comes up.

The phrase "feature creep" is important to know and be able to identify. If you don't settle on a feature set early and if you're inflexible to what features you will ship, the product will snow ball in development cost. The reason is simple: every time you change the product it costs time. Changing code creates bugs, changing features means changing code which creates bugs. To fix a bug you have to change code, and guess what, that creates bugs too.

Bugs

There is a big difference between college and industry: in college your assignment is clearly defined, and you have a set of end goals that you are graded on. Bugs in code means lost points. In business, your "grade" is determined by income and customer satisfaction. Bugs in code does not equate directly to loss of income or customer satisfaction. Why? Because software quality is not an exact science. You will always ship bugs because the goals of income and customer satisfaction are fuzzy. An assignment has exact requirements, a customer gives you no such luxury. What one customer thinks of as a great feature can be the end all bug that prevents another customer from buying the product. Therefore no complex piece of software will ever meet customer needs 100% and it's necessary to have a quality bar that allows for a few defects. Just like you can't have a perfectly sharp knife, you can never have a perfect piece of software. You need to defined a "quality bar" and decide which issues can be tossed and which need to be fixed to keep the product at that quality level.

It's not the case that all bugs are less important in business though. An off by one error may mean a point off of your Computer Science project, but the impact on business of a buffer overrun leading to an exploit can be huge. Knowing which bugs are important to your business and which are not can greatly affect the quality of your product. It's important to factor business needs into how you grade the quality of the product so that you know where your quality bar is and so which bugs you can live with and which need immediate attention.

So a quick and dirty formula for determining if a bug gets fixed in business: Customer Impact / Cost and Risk of fixing the bug > 1

Fix the bugs that have the highest amount of impact or prevent you from shipping (like security issues), ignore bugs that have little or no impact or are so costly to fix that you will miss shipping the product.

Business Value

Not punting bugs isn't the only way a product can fail. You can have a successful cycle, all bug goals met, every feature works great and you give it to the customer and they go "Huh? Why should I pay for that?" While it might be a noble idea to convert your 3 million line program from C++ to C#, if this is all you spend time on then you haven't achieved anything. "But wait! Haven't we achieved better memory management and now coding is easier and…" The customer isn't going to care because there's no benefit to them. Why should they pay you money for something for a product that already exists, just in C++? If you don't focus on business value then you will never sell anything.

The bug here is in requirements: no customer impact means no customers. Shipping is a feature and shipping should mean features. Your requirements need to address business value as well so that when you do ship, the product is something people will want.

Posted: Friday, February 02, 2007 1:21 AM by Chris Becker

Comments

CoolBeans: From College to Industry said:

Assignments in college come with specific parameters for good grades. If the project assigned doesn't

# March 22, 2007 1:54 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker