You know Jeff there is also something called Beta testing…
nice try, publisher of defect tracking software. 
hmmm and you don’t think people are getting tired of testing your shit application for you, or have a lower opinion of you for serving them crap. Sorry but this is going from one extreme to another.
I guess part of this is about what Derek Sivers is talking about here: http://www.codinghorror.com/blog/archives/001313.html
Let how the users use the product inform you about how to do it. But yeah, alpha testing for features, beta for polish and big bugs and release candidate for tiny errors.
Sorry, that last link was http://sivers.org/walkways . My profuse apologies.
Let the users find out what works and doesn’t, and how.
I agree with most of this just as long as the code is not buggy and/or unsafe. There are many embedded systems that can cause property damage or cause injury to people. That’s not the kind of code you just want to be tossing out into the wild and fixing later. Of course, if you’re just talking about missing features or enhancements to usability, then I’m fine with the approach.
I’ve come to the same conclusion. When I first started developing I was almost unable to get behind with releasing software that wasn’t “perfect”. Aside from all of the great points that were made in the article, I realized one key thing that allowed me to put my OCD aside. We build software to solve problems for our clients but we do it for one ultimate, self serving goal - to make money. If version 1 is usable but not perfect, put it out there and begin making some ROI. Putting it out there and getting 3 months of user feedback is a plus but the even bigger bonus is making money three months sooner from your clients. This may not be the case for everyone but in the financial software industry, the moment a piece of my software is managing money, I’m getting paid.
That’s a very long way to say what could have been said in one or two sentences…
For the first time while reading your blog i have the feeling that you are completly wrong. Not only about your opinion, that is what is happening already. Barely any software is released today that doesnt require several patches to fix major bugs. I think its even wrong to write that here. You even reassure those who do this to go on with their bad quality.
The customer pays for a working software, handing him anything else than that is just not ok.
If software developers don`t have the time for enough testing it doesnt make it right to hand out a bad produkt. If you dont include the time for testing, it is your fault, you made an error in your project management, you have to correct it, the customers are supposed to use your software, they are not supposed to do your work for you by beeing abused as beta testers.
Imagine you would order a car and at the delivery date they present you a car without tires, telling you that they didnt had the time to assemble them.
You expect quality for other products you buy, why different rules for software?
If cars would be “released” with the same quality standards as software i would use my bicycle way more often.
I think this is nonsense, sorry.
Agile methodologies teach us to involve customers right from the start and to build only features that add business value.
A software product may be crappy from an architectural perspective and may need improvement there, but if you need to release a product to get customer feedback, you’ve never been building it right in the first place.
this sort of summarises all that is wrong in the world of slow and half-baked web, java, .net, and mobile phone software. Most of them useless for many reasons (if they even serve their intended purpose).
Most bugs are signs of deeper architectural problems, and the ones that aren’t, aren’t very serious, and usually get marked as low priority. To make matters worse, it usually only becomes clear after someone has tried and failed to fix the bug in a short timeframe.
Not finding and fixing them before releasing to the public is a very bad idea, since it increases technical debt tremendously.
In effect, the customer will be stuck with beta grade software until v2.5 because no sane project manager will want to touch these bugs that now have become a huge undertaking.
Nothing is perfect, just look in the mirror.
If God himself had wanted to launch a perfect ‘Adam’ then we would not exists.
It’s not the imperfections that are the problem.
It’s the imperfections that cannot be tolerated.
Or, to put it another way:
If your nose is too big that is not really a problem for most people.
If you have pancreatic cancer that is a big problem for just about anyone.
It goes the same way for software. The little used feature not workking or cosmetic flaw can be tolerated. The major feature not working correctly or heaven forbid, a major flaw that corrupts the purpose of the software, cannot be tolerated.
I disagree,
I develop commercial software which has to be reliable for clients, we have set levels of allowable bugs. We have to have the features we agreed to develop in the final product and have to have a low number of bugs. If the software fails, our client will be fined vast sums of money and we will be sued to breach of contract.
There are no ifs or buts version one has to work first time around. That’s is why we employ a team of testers and simulate entire systems in our office, to grantee it works.
That’s the real world not the wonderful word of web development
I kinda equate the “sucks vs buggy” to Vista vs XP. XP sucked when it first came out - but it worked as well or better than the current 2000 patched machines.
Vista was buggy as hell
When a product sucks because it looks terrible but does the job as good or better than it’s predecessor is one thing. A product that stinks like a cold bag of poo is another thing.
Good article and in complete agreement. I’m currently working on a site that’s going to be released “incomplete” for the very reason I want my customers to have a hand in the design.
Not sure where you get the notion of developers being perfectionists though… in my experience most developers are far from perfectionists - more in the realm of “mediocre” actually - but that’s no different to the rest of the human race. That said, I don’t see being a perfectionist as being a particularly useful trait for most situations either.
Another alternative is to work with your customers and do technical previews with them before shipping your v1. That is what we’re doing. Our close “test group” knows there are issues. They know what our tests look like, but they also know that their day to day use will uncover issues that we missed, and their users will find use cases that even their product managers missed.
The good thing doing it this way is that the customer tends to be more involved (they don’t just drop the software thinking it is too buggy). You still get the real world feedback that you wanted. Your customers get to more strongly influence the software. And you can release a v1 version to the world feeling a bit more comfortable with its quality.
@Matt, I’m curious as to what kind of software you’re building? I’ve never seen any company do what yours does. Do you have any links to your company/software? Your team has found the holy grail of SW Engineering.
Our software is also made up of our own assumptions that need to be quickly validated by our customers. The longer we delay shipping, the further down the wrong road we could go. Mark Twain put it best: “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.”