20% more bugs? Or 20% less features?

Steve Py about 2 hours later:

• • It depends entirely on the context of your market.

  • Lets say you have 6 months budget to get an initial release out to market.

  • Path A: Quality, of the possible features you could develop you decide that only 60% of those features can be developed “right” in 6 months so these are the ones you develop.

  • Path B: Market, of the possible features you could develop you guess that 80% of those features could be functional in 6 months.

  • Following path A you’ll probably end up with 55% of the features nice and stable ready for release.

  • Following path B you’ll probably end up with 50% or so features as “stable”, another 15-20% as having known issues with work-arounds, or possibly buggy but stable enough to have been integrated.

  • If you follow path B you deliver more perceived value to your investors, and more features to attract customers to your product. Chances are that even if you created perfect code, it wasn’t really what the customer will be happiest with anyway.

  • The simple fact is like any consumable, “perfection” implies cost. Why don’t we all drive Mercedes instead of buying Fords or Hyundai’s? Surely a lot more people could afford a Mercedes than those that actually drive them, yet they choose to buy a Honda. Companies are no different. Don’t expect them to pay an extra 20%+ for “quality” when the 80% solution gets them reliably to the airport & back. This isn’t an advocation that it’s ok to ship sh@t.

Keith about 2 hours later:

• • I think perhaps its more dependent on what you are applying the term “quality” which may have nothing to do with the quality of the code.

  • More that you want to get to minimum feature complete as soon as possible and release. (which could be nice tested code)

  • But it could mean, no spit an polish on the UI, very basic functionality, product concept might not be fully developed, might be very specific for a particular task and difficult to generalize later etc.

  • code quality is only a part of the quality equation of creating software products

  • also when you say 20% less features, then if thats even possible, then your target would be 20% less features 20% sooner!

Steve about 4 hours later:

• • You are creating a false dichotomy, there are actually three choices:

  • 1) Implement 100% of the features, omit to test 20% of them, ship 2) Implement 100% of the features, test 100% of them, miss the deadline 3) Implement 80% of the features, test 100% of them, ship an inferior product

  • Is it any wonder that a lot of companies choose 1)? Makes perfect economic sense to me, and having code well tested is of little help if your company goes bankrupt one month later because it couldn’t ship in time.

Mohinder about 8 hours later:

• • I agree with the comments above that time to market is important, delivering bulk of the features is important and quality is important too. In real scenarios, you always have to strike a balance so that a maximum value is delivered within the time frame. Throwing people at the job, in my opinion, is always counterproductive. Therefore, if you have too many constraints such as fixed budget then you need to look at the best development approaches with the skills your team has. This is where agile framework, if this is an option most favourable to consider, help you achieve the best within the time and resources. It is a myth that stakeholders would like to have all their requirements included in the final build which in reality is not so true. We all dream of Rolls Royce but end up with Honda because that is best the money could buy. Agile approach where stakeholder is in control would help shape the project as it is progressing and get the best value and feature that can be delivered within budget whether it is 20% buggy or 20% less features from the original requirements. You know who to blame but yourself if things do not work out as they should.

Larry about 9 hours later:

• • The last 10% takes 90% of the time…

Matt Green about 10 hours later:

• • If you’re asking if it is better to ship 80% of the features to reach the ‘deadline’ or ship 100% of the features with only 80% of them actually working properly or having poor quality or a high defect count then I agree – it is probably a false economy as the last 20% will incur rework fees, support costs or other less tangible costs such as loss of reputation.

  • Ultimately it is the client’s call – if the client wants to meet the deadline more than wanting the feature count to be 100% then that’s his choice – he may even want to scale back the last 20% of features to be simpler or narrower in scope.

  • The ‘quality’ however should remain the same in my opinion otherwise the technical debt will accrue. Agile approaches should be about delivering the simplest required feature set in the simplest implementation – NOT the stupidest feature set in the stupidest implementation!

  • Letting the client dictate the quality is like letting them dictate the estimate. If a technical team thinks Feature X will take 5 man-days to complete but the client wants it in 3 the team must hold to their estimate unless the rules of the Mythical Man Month don’t apply! Or de-scope Feature X to become Feature Mini-X. It shows a certain distrust if the client thinks he can get 5 days work done in 3 days – either the client is trying to get more for his money than is reasonable or the supplier has over inflated the estimate and the client suspects as much. Sadly software engineering is at the whim of human nature just as every other field.

  • (NB the ‘simplest implementation’ may still be complex or advanced – it simply needs to meet all the prevailing requirements – and it’s requirements in my opinion that are key to everyone understanding what ‘simple’ actually is and thus removing a lot of doubt and tension from the relationship.)

Zach about 10 hours later:

• • As someone has already stated, it totally depends on the particular market conditions. There are a number of issues at hand, but a couple reasons I can think of why you might not trade 20% of your features for 20% fewer bugs:

  • 1) Feature dependencies: There may be a number of features that you have to implement in order to support and provide the 1 or more market differentiating features. This may present a situation where you have only two options – reduced quality or longer time to market.

  • 2) New Market or Market Segment: If the product is entering a completely new market or market segment (or one that is just starting to take off – think iPhone apps right after the iPhone was released or the iPad now) then time to market is extremely critical. Being first or close enough to the front may have a huge bearing on how much of the market you are able to capture. During these “frontier” phases, the average user may be more willing to deal with quirks and workarounds and thus two products are compared more on features than on quality.

  • As a counter example, if you are moving into an existing market where there is already a product with traction, you may need to be fairly feature complete relative to the existing products. You may have a choice over having similar quality to their product with additional features, or a core subset of features with higher quality. What that market is currently asking for will drive which you choose (or even longer time to market with both).

  • Quality is something hard to measure, especially on a software product you are about to buy. In terms of marketing and sales, features are a much easier selling point. Therefore, the trade-offs of quality vs features vs cost vs time to market will vary with each product and each market. If you are writing software where a single failure will result in heavy backlash from the consumers (e.g. enterprise database backup software) then obviously for a fixed time to market, fewer features with higher quality is the way to go. However, if you are writing an application where the consumer is willing to put up with some issues in exchange for a “killer” feature (e.g. restaurant review applications and the killer feature of being location aware rather than entering in your current zip code each time) then choosing the features over the quality may be the way to go.

  • The key is being aware of the trade-offs, making an informed decision, and positioning yourself to improve your product’s deficiencies faster than the other guy. One thing is for sure, features and quality being equal, the one that has both first, is in a much better situation.

Maxime about 11 hours later:

• • Well there is many variables in this equation. First we have the fixed budget, the amount of features, the deadline and test coverage of those features.

  • We all agree that if the budget is low, even if the amount of feature is huge, it won’t be possible to have them all. Features will need to be cut down. Especially if those feature can’t be met within the deadline. If after cutting down the features to meet the deadline, does it still meet your budget? Throwing new programmers at a project won’t make it more efficient.

  • So if you have the budget to build a Honda but the features to fit a Mercedes… it’s sad to say but you get what you pay for.

  • Test should be included in the development of the product. Why exclude them? Sure you can implement the first few features fast but as the code quality lower so does your velocity. What do you end up? Well… cutting feature to meet your deadline with buggy features because they are untested.

  • Of course you can always take a technical debt but as we all already saw… it must fit properly within the quadrant as a voluntary sacrifice with a real grasp on the consequences of taking short cuts. But for me, technical debts is not skipping the tests. No body is going to go back and implement the tests. Ever. It’s boring/expensive to write test on code that “works” and nobody will end-up doing it.

  • But what is important, what happen after your deadline? There will be another… and another and another. Should we cut on quality every time?

  • I sure hope not because if our bridges were built like that… they would collapse all one by one.

Jason Y about 11 hours later:

• • I agree with the comments above.

  • One other thing to distinguish is the difference between fragile solutions that can blow up in the worst of ways (e.g. inadvertently deleting records from a database) and solutions where trying to do a certain valid thing results in an error message, but no damage is done and the user can continue working and can work around the issue. The former is simply unacceptable in any scenario, but the latter is often preferable over not including those features at all.

William Pietri about 12 hours later:

• • I have seen four separate things leading people to say that.

  • One is based on what you can sell. The box only lists the features, not the bugs, so as long as the bugs aren’t egregious, you can ship semi-broken stuff and people will still buy it.

  • Another is based on capital availability. Writing buggy software means you are leaving part of the work for later. If that “later” point is when you have income, you might be able to ship with more stuff. It’s basically taking out a loan that you have to pay back after release, but only if your product succeeds.

  • A third is markets where there is a strong first-mover advantage. Your bugs might drive off some people, but not nearly as many as would be pulled away by a competitor. E.g., eBay has been king of the online auction market mainly because it got there first.

  • Fourth - and most common, I think - has to do with promises made. People say, “We will launch by date X”. They say that to bosses or investors, and their social capital will take a hit unless they do that.

  • These all make sense if you think bugs are inevitable, and needing a database to track your bugs is normal. It’s the same way that 80-hour weeks seem like a way to get something done twice as fast. Personally, I think lowered quality and overtime both can be plausible short-term tactics, but are almost always terrible long-term strategies.

Eric Malamisura about 12 hours later:

• • Hi Bob we met at Agile 2009, and first off I whole heartedly agree with you that quality should never be sacrificed. However, as everything in life there are other driving forces such as ROI. Additionally if Google is any testament, releasing software that is knowingly buggy and tagging it was Beta is perfectly acceptable, although I often wonder if user perception would be different in this scenario for paid vs free software.

  • As other readers have mentioned, if you are in a highly competitive market than you need to release those new features. However, I was one of those people that was saying, who cares how long it takes Microsoft to release Vista, they should concentrate on making it perfect. We all saw how well that worked, they just tried to push features out, and it was extremely buggy.

  • Ultimately I think every company strives for bug free, and often they release with bugs. Microsoft is well known for this, they release with a slew of bugs remaining in Connect. Recently though they have been fixing these bugs, or at least the ones that are more annoying and IMO their software has been increasing in quality or at least perceived quality lately.

  • Just some of my thoughts…

Elroy about 14 hours later:

• • I wish more people thought like you. But, it’s really difficult to convince people about this. It’s more of a long-term goal to maintain your quality image. Poor managers just consider short term goals as their appraisals depend on it.

  • And, isn’t this the exact reason why Google Buzz failed? It could have been better.

Denis about 14 hours later:

• • I find the examples cited in the comments really interesting.

  • Apple, for the iPod, the iPhone and iPad has notoriously left features out in their first release and focused on having high quality.

  • Honda and Hyundai are cheaper to own because they are high quality. The difference between Honda and Mercedes are more differentiated by features depth (dimensional planning anyone ?) than by quality in my mind.

  • So the arguments of trading off quality are essentially the kind of reasoning that GM and Microsoft have/had: more features is better.

  • It is true however that you can contract technical debt, especially if you are not sure you will ever have to repay it, as William highlighted in his second point.

Abdul Habra about 16 hours later:

• • It seems to me that Steve Py comparison is not very accurate. The price difference between a Ford and a Mercedes is not 20%. How much would Mercedes sells if it costs only 20% more than a Ford!

Zach about 16 hours later:

• • @Denis: I wasn’t stating that Apple had to sacrifice quality for features or time to market for the iPod, iPhone or iPad. I was saying that Applications written For those devices had strong first-mover advantages (thank you William for the succinct term) because they created new market segments. As a result, many of those applications focused more heavily on the time to market and features sides rather than the quality.

Esko Luontola about 16 hours later:

• • “Growing Object-Oriented Software, Guided by Tests” discusses on page 10 nicely the difference between external quality – how well it meets the needs of its customers (is it functional, reliable, available etc.) – and internal quality – how well it meets the needs of its developers (is it easy to understand, easy to change). The book says that:

    • Everyone can understand the point of external quality

    • Internal quality is what lets us cope with continual and unanticipated change which, as we saw at the beginning of this chapter, is a fact of working with software. The point of maintaining internal quality is to allow us to modify the system’s behavior safely and predictably, because it minimizes the risk that a change will force major rework.

  • P.S. Who said that if the code does not need to work, he can get it done really fast? What is the exact quote?

Markus Gaertner about 18 hours later:

• • Immediately Weinberg’s Zeroth Law of Software came to mind while reading your short entry: If the software doesn’t have to work, you can always meet any other requirement. (Quality Software Management Vol. 2 – first-order measurement, page 111)

  • Of course, the Zeroth Law of Software goes hand in hand with the Zeroth Law of Quality: If you don’t care about quality, you can meet any other requirement. (ibid, page 112)

  • I’ll leave it as crisp as you did with just these two citations.

Steve Py about 20 hours later:

• • The comparison between Ford and Mercedes was not to parallel Bob’s example, it was to demonstrate that there are many more people that could afford to buy/finance a Mercedes/Lexus/BMW/Audi etc. car, but choose to buy the less expensive, less pollished option.

  • When I buy a car I put a value on the function it serves. If that’s $30k it won’t get me anything of the above prestige brands, but it will get me a Hyundai i30 or a Honda Jazz/Fit. Other people are free to set whatever value they choose. If it’s $50k that might be a BMW 1 series, or a pretty loaded Accord.

  • Companies simply do the same. They say we have enough money for 6 months development and want to get as much value as they can for it. When a product goes to market that market response will dictate how much further to invest in the product. So it makes sense to get as many “decent” condition (NOT read “crap”) features in as possible to give perceived value and showcase as much as possible of the potential of the product. Chances are some of the features you thought were going to be cool aren’t really used anyway, while feedback highlights which features really do need further refinement.

  • The hard sell of quality up-front is that you’re demanding of the business and investors to sacrifice perceived value, or incurr significant tangible cost up-front. While you might justify that an extra $50,000 today will, at most, “probably” save $100,000 of bug fixes down the road, that is $50,000 of their own money they really don’t want to spend today, vs. $100,000 of other people’s money if and when the product demonstrates it has enough value to justify improving.

  • Sorry Bob, I thought with you in the industry as long as you’ve been you’d know this better than most… Still, I can’t fault you for not liking it. :)

dan 1 day later:

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

ctford 1 day later:

• • 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).

Geoff 1 day later:

• • Less is more

flaviafm 1 day later:

• • 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.

Michaux Kelley 1 day later:

• • 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.

David Putnam 1 day later:

• • 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.

Shook 1 day later:

• • 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.

Danijel Arsenovski 1 day later:

• • 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.

Mick Maguire 1 day later:

• • 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.

Steve Py 1 day later:

• • @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.

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.

Uncle Bob 3 days later:

• • • 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!

Patrick 3 days later:

• • 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.

Luca Minudel 4 days later:

• • 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!

Marc 5 days later:

• • 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!

Amy Thorne 5 days later:

• • 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.

dan 6 days later:

• • 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.

Steve Py 7 days later:

• • @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. ;)