Object Mentor Blog: 20% more bugs? Or 20% less features?

20% more bugs? Or 20% less features?

Uncle Bob — Tue, 06 Apr 2010 22:03:23 -0500

People often make the argument that time to market is more important that quality. I’m not sure just what they mean by that. Do they mean that it’s ok if 20% of the features don’t work so long as they deliver quickly? If so, that’s just stupid. Why not develop 20% fewer features, and develop them well. It seems to me that choosing which 20% you are not going to develop and then choosing to develop the other 80% to a high standard of quality is a better management decision than telling the developers to work sloppily.

"20% more bugs? Or 20% less features?" by jenniferthomos2

Tue, 07 Sep 2010 02:58:10 -0500

How to convert AVI to iPad with best iPad Video Converter – AVI to iPad Best AVI to iPad Converter a professional iPad converter to convert avi files into iPad mp4 format, of course it can easily convert almost 100 kinds of videos to iPad for enjoying. The input format includes AVI, AMV, MKV, FLV, MTS, M2TS, MOD, H.264/AVC, RMVB, HD TS, HD MOV, WMV HD, etc. Best AVI to iPad Converter allows users to enjoy videos with the large and high-resolution screen freely with your iPad. There are many powerful editing functions such as effect, trim, crop, add watermark, merge and so on. RECOMMENDED: For Mac Users, you can try iPad Converter for Mac Version! FLV to iPad Converter DivX to iPad Converter

"20% more bugs? Or 20% less features?" by dupont lighter

Fri, 27 Aug 2010 21:49:59 -0500

dupont lighter, dupont lighters, st dupont lighter, s.t. dupont lighters. Great post,just as Great belts Sale time,you will enjoy the shopping time by belts Sale online store,and buy belts from belts Sale online store. Price Guarantee, sale now.time limited.seize the chance.

"20% more bugs? Or 20% less features?" by Men’s belts

Thu, 26 Aug 2010 21:18:11 -0500

Men’s belts, LV men’s belts, Fashionable Gucci men’s belts, Attractive style Hermes men’s belts.
This florist in Kensal Rise is an olfactory sensation, overflowing with flowers, foliage and stacks of ancient-looking vases and crockery. It all looks as if Vicky, the owner, has picked the flowers fresh from the meadows that day.

"20% more bugs? Or 20% less features?" by liveyou

Wed, 04 Aug 2010 22:14:25 -0500

Guide on how to copy dvd to ipad, how can I copy files onto an ipad, how to copy a dvd movie to ipad, how to copy files from computer to ipad.

"20% more bugs? Or 20% less features?" by clothes

Tue, 13 Jul 2010 02:17:58 -0500

dress or wild character because clothing

"20% more bugs? Or 20% less features?" by five finger shoes

Thu, 20 May 2010 03:30:34 -0500

I very much love all your writing way, very helpful ?

"20% more bugs? Or 20% less features?" by nappisite

Tue, 20 Apr 2010 16:22:57 -0500

This is a no-brainer. 20% fewer features.

"20% more bugs? Or 20% less features?" by Steve Py

Tue, 13 Apr 2010 17:09:51 -0500

@dan

Effective code re-use is always a good thing but it hinges heavily on many factors such as effective communication between team members, experience, and discipline. In a perfect world, all of the “best” mentors of these attributes would be spread out over all of the projects under development. But in reality they are few and far between, leaving most project teams to stumble along and fight their way through the pain with little more than blog posts to inspire them that there might just be a better way.

The cold, hard fact is that it boils down to cash. Development is an expense, and an expense towards an intangible asset. Some managers / businesses understand that and treat development effort as an investment. Most don’t so it comes down to “I want (A) by (T), How much is it going to cost? Ah, $(X), too much, $(X/2).” Not to mention that features of (B), (C), and (D) start popping in at any point through development. Even bad managers will typically understand that changes to an existing screen/feature they’ve already seen will cost extra time and $ to change, but changes to stuff that hasn’t been constructed yet, that has no impact for them. It’s difficult to count on re-use in such an environment.

If all you’ve got is lemons, pray you aren’t allergic to citrus. ;)

"20% more bugs? Or 20% less features?" by dan

Tue, 13 Apr 2010 04:45:24 -0500

It’s time to reuse. Software is not about rushing to be in time with the scheduler. If so, developers will choose the quick and dirty solution to finish the tasks.

Software is about speed (not a high one). The speed will be lower at the begining of the project. But soon as you built reusable code you will get higher speed to finish tasks. I gained weeks of development by reusing. TDD will protect you to introduce bugs.

"20% more bugs? Or 20% less features?" by Amy Thorne

Mon, 12 Apr 2010 08:01:37 -0500

Uncle Bob asked, “Do they mean that it’s ok if 20% of the features don’t work so long as they deliver quickly?”

Possibly.

Paul Buchheit makes an astute observation at the very end of the article “If your product is Great, it doesn’t need to be Good:”

This advice [to make your software usable] probably only applies to consumer products (ones where the purchaser is also the user—this includes some business products). For markets that have purchasing processes with long lists of feature requirements, you should probably just crank out as many features as possible and not waste time on simplicity or usability.

I don’t think it’s unusual in some markets for the purchaser to have a checklist of features—many of which they will never actually use—that they use to evaluate which product to buy. In order for your software even to be considered, it might need to tick off a bunch of those boxes.

Obviously, a purchasing process like that is broken, and it encourages the software provider to use a broken process, too.

That’s depressing.

We need to find a way not only to encourage software programmers not to go along with broken processes, but also to encourage software purchasers not to, either.

Because as a software developer, I very much want to code quality software. But as long as shipping crap software allows businesses to meet next quarter’s figures, it’s difficult to convince them to do otherwise.

"20% more bugs? Or 20% less features?" by Marc

Sun, 11 Apr 2010 22:50:57 -0500

I think it is a bit of a false antithesis to separate quality from released software. That crappy software available now is infinitely better than the competitions perfect software that will be released “someday” or “soon”. There is a risk, of course, that the competition wasn’t that far behind, and releases much better quality software a month later.

But I do like to believe that the best way to release software quickly is to write quality software the first time.

Other commenters made important points about distinguishing quality of code from quality of features. e.g. Features may suck with the highest quality code behind them!

"20% more bugs? Or 20% less features?" by Luca Minudel

Sat, 10 Apr 2010 16:43:18 -0500

Sometime “time to market” can be just an excuse from someone that didn’t take the decision in time before the Last Responsible Moment.

Sometime “time to market” can be a really good reason the make the difference between success and failure of a start-up. Kent Beck discussed this topic here “To Test or Not to Test? That’s a Good Question.”: http://www.threeriversinstitute.org/blog/?p=187

Think we should not call all technical decisions based on “time to market” just stupid, instead we should be able to discriminate case by case: this topic deserve more investigations!

"20% more bugs? Or 20% less features?" by Patrick

Fri, 09 Apr 2010 15:58:46 -0500

Show of hands: who believes that you can save 20% of your development effort by eliminating 20% of your features?

No? Ok. Who believes that you can reduce your bug count by 20% by spending 20% more your development effort on bug reduction?

No takers? I thought so. Claiming that bugs can be traded off for features this way is almost unbelievably naive.

"20% more bugs? Or 20% less features?" by Uncle Bob

Fri, 09 Apr 2010 14:35:32 -0500

Adam 1 day later:

Sigh. I believe you’re arguing for 20% fewer well-written features, rather than 20% less well-written features. But, the title of the post makes this unclear.

And it makes me sad.

That’s a criticism I’ll gladly take to heart!

"20% more bugs? Or 20% less features?" by Adam

Thu, 08 Apr 2010 21:34:23 -0500

Sigh. I believe you’re arguing for 20% fewer well-written features, rather than 20% less well-written features. But, the title of the post makes this unclear.

And it makes me sad.

"20% more bugs? Or 20% less features?" by Steve Py

Thu, 08 Apr 2010 20:36:12 -0500

@Mick

True, negative experiences are more readily discussed than positive ones. The trouble is that you can spend a crap-load of money up front to try and ensure your customers don’t experience any frustration, but it still happens anyways. The most stable, well engineered code will still be deemed “bad” if it doesn’t do things the way the end user would expect it to.

What’s more important is that the perception of quality does improve, and continues to improve. Features become more stable, and more in-line with what the end users expect. This would be my argument not to invest in the 100% solution up front. Get the concept in up-front and in the hands of users early, get their feedback from bugs and usability opinion, and always seek to improve upon it.

You still need driving concepts like “Clean Code” to keep that campsite tidy. If you accept that bugs and bad behaviour assumptions are a fact of life to be engaged and destroyed; The worst risk IMO is the regression of bugs. Nothing irks a customer more than finding something that previously troubled them and was fixed is reintroduced with a later upgrade.

"20% more bugs? Or 20% less features?" by Mick Maguire

Thu, 08 Apr 2010 13:09:30 -0500

A lot of the answers here seem to assume or imply that that all features are created equal and that if you cut quality you will effectively be choosing which features are broken.

In reality if you writer bad code your app will be a crap shoot – maybe it’ll be the fluff that doesn’t work properly, but it’ll be just as likely the meat.

Bugs are like service – people remember and share the bad things much more readily than the good.

Get it right – cut the fluff, and make it work properly, as it should and as the customer needs / expects.

"20% more bugs? Or 20% less features?" by Danijel Arsenovski

Thu, 08 Apr 2010 09:43:59 -0500

Not to mention how unlikely is to know really well all the features and their priority in advance. How can a feature that doesn’t work properly be beneficial for the product or the company? There was a similar discussion on LIDNUG some time ago. The question was: “Is it ok to cut corners to meet a deadline?” Here is what I had to say: It’s NOT OK to cut corners, but it’s OK to cut features.

"20% more bugs? Or 20% less features?" by Shook

Thu, 08 Apr 2010 09:07:32 -0500

If you plan your project properly putting the High importance/High risk items up front than the 20% should really be your exciters and deliters. The features that aren’t really necessary are but are really cool. A lot of these features will really only be used by power users and the base functionality of your app should work and be stable offering value to all of your customers. If the exciters and deliters don’t work 100% of the time it may frustrate some of your users but they won’t want to leave your product because they can’t live without that cool feature even though it only works 70% of the time. Merging in Visual Studio doesn’t work right 100% of the time… but I couldn’t live without it and I’m not jumping ship to a new product. It still works when I need it and there are work arounds to see when it doesn’t.

"20% more bugs? Or 20% less features?" by David Putnam

Thu, 08 Apr 2010 08:55:51 -0500

I am so much more cynical.

I don’t think that companies feel there is a down side to delivering buggy features. The rationale follows that all software has bugs anyway and if people complain, the bugs are the fault of the software developers, not the business people. It certainly is not the business’ fault if the developers can’t produce bug free code in the time we expect the features to be delivered.

"20% more bugs? Or 20% less features?" by Michaux Kelley

Thu, 08 Apr 2010 08:14:18 -0500

Communication is key. If you don’t have frequent contact with the product owner, customer, and a self-organizing team of motivated developers, then all the testing and planning in the world will have been in vain. I’ve been guilty of sitting in the cube in comfortable isolation more than once, and every time I’ve regretted the habit. If you want to deliver everything on time and with the quality expected, then plan for change, unexpected requirements, and manage risks. Do it early and often. Mold the process and planning around dedicated people, and the product might deliver even more than the expected.

"20% more bugs? Or 20% less features?" by flaviafm

Thu, 08 Apr 2010 07:14:56 -0500

How do you react if your family doctor say to you: Well 80% of your treatment is save 20% well wasn’t tested? Do you want that treatment?

Why the developers can’t give themselves the right a better time/budget to deliver a better product… Because the company goes bankrupt!!! Easy isn’t??? Why we keep accepting that? Is not a better question? Is not the whole culture that’s need to change??

We should be sincere with our customer: To deliver what you want we need more time/money. In this time/money we can deliver this!! If you want a product that doesn’t work all the time or it will be cheap do develop and extremely expensive to keep the XXX company can deliver it for you :)

Change culture takes time… But is necessary to start.

"20% more bugs? Or 20% less features?" by Geoff

Thu, 08 Apr 2010 06:48:51 -0500

Less is more

"20% more bugs? Or 20% less features?" by ctford

Thu, 08 Apr 2010 06:46:45 -0500

In our industry, quality isn’t always correlated with price. Customers have great difficulty judging quality, so often they pay Mercedes prices for something that doesn’t even have the requisite number of wheels.

Besides, developing high quality code is usually the quickest way to get it done. Tolerating sloppy code is like saying that you’re in such a rush to get to work that you don’t have time to fill up with petrol (or gas for you Americans).

"20% more bugs? Or 20% less features?" by dan

Thu, 08 Apr 2010 04:28:36 -0500

20% less features? You’ve got it right in your post; fix the title! ;)