@sunfire on December 4, 2009 6:56 AM:
“Microsoft uses a lot of statistics how many bugs could eventually be in a software at what level and how much bugs a customer wouldn’t take care before switching to something else.”
Perhaps that could be called the peanut butter approach to release management?
In a previous post (I don’t have the time or inclination to find it, at the moment), Jeff revealed how the the MS Excel team discovered a menu item that did absolutely nothing and had been in the application since v1, yet no-one had noticed. I would say that, in that situation, it was worth releasing early, rather than wasting the time on developing something that nobody used (although, maybe, the item should have been removed first).
We always ship high quality software on time. It always has all of the features promised and very few (if any) “bugs”.
If you are faced with this kind of decision on a regular basis then you have failed miserably at the software development process. Why do we keep tolerating this kind of practice? Why do so many people find it so hard to get it right the first time?
I agree to a point. While it’s true that striving to release a perfect v1.0 is a fool’s errand, it’s also wrong to value time-to-market over creating something of which you’re intensely proud.
Why release something a few months early when you can get those BUGS out and maybe refine a few features? Sure there will be bugs you didn’t know about, and sure some features won’t scale properly, etc. But spending a little extra time is something that I think users will notice and appreciate.
Not to mention, the more time you spend on version 1 and are dedicated to the follow-up (as you emphasize) the better your versions 2+ will be.
So yeah, don’t spend an extra year working on 3 awesome features that you originally planned would be done by now, but don’t release something that’s clearly buggy when you could at least take care of most (if not all) the known bugs. You want your users finding those unknown unkowns, and the less known unknowns you have when you release; the more unkown unknowns you’ll find.
You don’t get it people!
It is not about ship crap to the word, is about cutting down to a basic product. Errors will always come up no matter how much effort you put on. Unless you’re NASA there is not much to do about it.
Forget about the perfect solution since version 1, that’s the worse kind of crap, it is suicidal.
“The later any mistakes get found the more they cost”: Absolute overrated, obsolete, and stupid idea. There are plenty of new technology there that embrace change rather than trying to avoid it, there’s plenty of new approaches to do software (there’s more that waterfall did you know?).
Too sad to see how many people missed the hole point of this excelent article!
Yes… ship it anyway…
That’s what the guys did with KDE4, loosing half of their user base…
this blog post sucked but you have shipped it anyway
My two cents:
If you have no way of speaking to the customer before a particular date, simulate a customer -
(a) Demand a functionally competent tester who does not code
(b) Get a friend / colleague in the company who can help with a few hours of testing for this one project, then onwards, demand a tester from the first day citing that project as an example.
If the customer team has even one person of integrity and has genuine interest in the quality of the software (for his own benefit or for any other reason), get a hour or two to show him the working parts - even in that time you will have got enough valuable feedback.
The key is to look for and find the cooperative/proactive user.
He could be the overworked nice guy in his company (he’ll help out more than anyone else) or someone who values competence - yours or his own.
WARNING:
Make sure this guy is not the bean-counter at the customer’s, or invovled in their office politics (there’s a lot of that everywhere), or you are screwed beyond hope of repair.
The friendly user is often your lifeline.
I want to tag comments ‘helpful’, ‘vicious’, ‘troll’ etc.
Ratings / stars / “Was Helpful” / etc are NOT as important.
One would think that professional developers have evolved into humans living in society, and have Netiquette or even basic courtesy to discuss things.
Seems not to be so.
In some ways, this is a bug report for many of you guys to fix.
The global user base of this blog - we, the readers, would like the viciousness bug to be fixed.
No. I’m not talking of making a Demolition-Man style San Angeles society of weak sheeple.
@Mexpolk - if that was the point of the post, then why didn’t it say that? I guess those nuances were lost in the RewriteAsSmackDown(blog) method.
“The later any mistakes get found the more they cost” - no sorry, this is not outdated, but is unfortunately quite correct even in today’s web 3.5 world.
The newer methodologies (Agile) try to minimize this axiom by always focusing on what’s important and always trying to have a usable product that is verifiably correct. If you follow the rules, you’re not likely to encounter this too often. Don’t kid yourself - Agile doesn’t ignore this.
I also feel like if you want a public beta, you should call it a public beta. If you don’t feel like your v1.0 is ready for actual release, but you want feedback on it… that’s precisely what a public beta is. But don’t make people pay for your crappy, full-of-bugs initial release… The way I see it, people are generally pretty excited to be involved in a beta - they know it’ll be buggy, but they also know their feedback will help make the final product better. Because, yes, it’s definitely true that a product used by its intended users is more likely to have bugs or other issues raised, than one only used by a handful of developers and testers.
But nobody wants to pay for crap. Especially since, as far as I can tell, once a product has shipped, and people have paid for it, few companies are actually particularly motivated to fix complaints anymore, unless they’re 100% crippling, and common.
Many time some error found during making software that’s why makers are update interpretation. I think so.
@second:
“this blog post sucked but you have shipped it anyway”
Priceless.
Captcha: 200-mile jilting.
Reminds me of state highway 1, Cambodia
“I’m a developer and my software is far too important to release with bugs. JEFF, YOU ARE WRONG!!”
OK, that wasn’t a real quote, but it’s a exaggeration of some of the comments I’ve read here.
So, great, wonderful, you’ve now identified the fact that you are talking about different kinds of software. Perhaps Jeff is talking about consumer focused software, the non-mission-critical software. You know, the stuff Jeff ALWAYS writes about.
Therefore, if you’re so smart with your military-pin-the-bomb-on-the-third-world-targetting-device software, or your figures-must-be-correct-or-lotsa-people-gonna-lose-money software, why are you getting so angry about Jeff writing about a different kind of software with a different market and different types of users - most people who read this blog are aware of the difference. And those that aren’t will learn in time. There’s plenty of evidence that the most well-intended texts (for example the US constitution and various amendments) can be used mistakenly by the less enlightened.
Perhaps you should put your ‘angry’ back under your bonnet Bopeep, and perhaps write a researched response on your own blog, covering those important aspects of QA that YOU see as being important.
It just reeks of programmer classism in here. No pun intended.
Keep pumping out the goods, Jeff!
I have seen, (having read only about half the comments because There is an astounding quantity of them), just one objection to this advice.
“But Jeff, You can’t release buggy software!”.
If your primary reservation to shipping is that your software has a too long a defect backlog, then the advice was never for you to begin with. How has your development cycle allowed you to create such a huge mess of bugs in the first place? The advice you should be considering is something to the effect of “No new features until all known defects are resolved”.
Better yet, you should ship. Your customers will hate it, and abort the failing project for you.
If you can’t ship your product now, right now, then your problems are deeper than the shortage of features your customers expect.
(captcha “natal Department”… seems apropriate)
I THINK THE BEST PROCESS IS FOLLOWED BY JOHN CARMACK AND BLIZZARD…
THEY SHIP SOFTWARE WHEN ITS READY…AND ITS WORKED QUITE WELL SO FAR…AND VERY PROFITABLE TOO…
SO I DON’T KNOW WHAT JEFF IS TALKING ABOUT…
This would seem to be a couter-example:
The game “Saboteur” was launched with a known bug that causes it to crash on Windows 7 or Vista computers with ATI cards.
http://games.slashdot.org/story/09/12/09/0542246/Saboteur-Launch-Plagued-By-Problems-With-ATI-Cards
Somehow I really don’t think that was a good idea
I think you mean that you underestimated how long it would take the team to learn a new technology.
Hey Jeff, could you add Agree and Disagree buttons to your posts? I’m curious how many readers fall on each side of the fence.
good one. everyone should face it in IT field