I’m with Scott: Don’t let perfect be the enemy of good, but don’t confuse unusable with good.
I understand Jeff’s point, but I think there is a quality threshold below which the software should be canceled, not foisted on users. On the other side are the quality levels you might be able to achieve only after getting thorough feedback. Finding a reasonable point in the middle is probably one of the artsy parts of development.
So Jeff, you’re basically saying it’s okay to use your customers as beta-testers? Great! I can fire my entire QA department and save $$$!
No, I totally disagree with your “ship it no matter what” policy. Perhaps that policy has a tiny glimmer of hope when what you “ship” is free, but for paying customers, it’s a policy that will destroy your company’s reputation.
"There’s a big difference between the apps that Jeff is talking about (webby type apps and consumer software, kiddie software, social media software, ect) and real world software that has to work right. (e.g. financial trading platforms, IV syringe pumps, flight control software)
Jeff clearly has written software only for the former. That’s nice. But in the grown-up world where software has to work and your company does not get a second chance"
I pretty much agree with this poster. Your free web forum software or your 99 cent iPhone flashlight can go out the door before they are fully baked and it won’t be fatal.
If, on the other hand, your customers are business who are paying money for your app with the intention of using it to help them reduce their costs or increase their profits then that’s another kettle of fish entirely.
Business will never really be ‘dedicated users of your software’ in the sense that Stack Overflow users are dedicated.
You might get two strikes with a business customer, but you might not. You certainly won’t get three.
@anonymous no that’s not the microsoft policy.
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. If your customer thinks you v1 is totally crap he won’t buy a second version.
If microsoft have reached the level of quality, alphas and betas are released. first to msdn /technet subscribers who know what prolems an alpha/beta can make. At os public betas follow. And if they are succesful (note, you are at this point always far over the first level where a customer would buy the next version), it’s released. And at this point still the next or next 2 versions are in development.
There’s a big difference between the apps that Jeff is talking about (webby type apps and consumer software, kiddie software, social media software, ect) and real world software that has to work right. (e.g. financial trading platforms, IV syringe pumps, flight control software)
Jeff clearly has written software only for the former. That’s nice. But in the grown-up world where software has to work and your company does not get a second chance, Jeff’s advice is tantamount to negligence and incompetence.
I can cite quite a number of examples of shipped software that failed -and failed big. The results were death or millions of dollars lost. That’s a far cry from poor software causing an outage of an app that wastes your time 140 characters at a time.
Be careful of the advice you follow.
Your point is correct. However, I think such mission-critical systems are the exception rather than the rule. I would says something near 90% of programs can fail only causing minor annoyance rather than fiscal disaster.
I think anybody (programming or not) would modify their strategy as soon as they realized that this is the sort of program that cannot fail.
Voltaire quote (sort of) - Perfect is the enemy of the good enough.
Jeff, let me modify your statement:
Yes, you did a ton of things wrong on this project. But you did a ton of things exactly right, too.
And you should ship them, so everyone can benefit. Or more commercially: you should ship them, before another one gets the credits!
You should always be willing to put your reputation behind version 1.0. If you say software is good enough for widespread use, it should be. This means that you don’t package up your first efforts and call them 1.0.
Release beta-test software instead (either to the public or a limited number of people). Don’t ask people to pay for stuff that’s not actually useful as is.
And make sure the beta version does something good, even if it’s buggy about it. You want your beta testers to look at it and think “This will be cool when the bugs are out” rather than “Why would anybody use this even if bug-free and polished”?
Short iteration cycles are good but not if the result is that you foist upon your customer a heaping pile of crap early and often. This has to be coupled with some other things - knowing the rules (what we trying to solve here anyway? what are the domain requirements? ), having good testing practices in place, having good team communications (doing daily stand-ups?), realistic expectations, honesty, and customer interaction and input.
If the customer knows he’s going to be beta-testing the product and that his feedback is appreciated and will help drive the product toward a better solution and is OK with that, great. As long as the customer’s expectations are known and everyone is on the same page.
At the end of the day, you want to know early when you are having issues and resolve them early. You want to keep the customer in the loop as much as possible and if you are going to provide incremental releases and the customer is OK with that, leverage the power of the feedback loop they’ll provide. In some circumstances you can’t drop a ‘beta’ on them because they can’t afford to be running software that is buggy. There may be SERIOUS implications due to a bug. In that case, you don’t release early, you release when it is well tested and trusted to work well.
It’ll depend upon your end user and the industry as to whether you can ship a sucky version 1. You deliver a sucky version one of a medical app or a military guidance system and people could die due to errors in the code. You deliver a sucky version 1 of a social website and all that is probably in jeopardy from buggy code is your rep.
Just my opinion.
One of the projects I worked on slipped because the project lead decided that in the state it was in, it was very unlikely to actually be adopted at all. (Of course, technically it was a V2, where V1 had suffered from the product not having any customers.)
Honestly, I think Jeff’s advice here is poor. It’s assuming that you can’t differentiate between “this is not ideal” and “this does not solve the problem it says it does”, and if at the end of a project someone can’t tell the difference between the two, you have problems than cannot be solved by slipping the schedule.
@Practicality The problem is that Jeff sees the world only though his own experiences and then spouts off this nonsense. As a “thought leader” (I had to really choke down a laugh there) he should be more careful about the nonsense he publishes - since he apparently has a popular blog about “software development”. Kids in high school or college might take his advice as gospel. Since Jeff helped create a very successful site then we should emulate him and do like he says…
I’d also like to point out that this sentiment is nothing new - this is a repeat of the same stuff people have been saying for a few years now - “ship it and iterate.”
Well, that’s not exactly the whole picture and Jeff should take more responsibility for the crap he puts out there in the internets.
Of the many jobs I’ve had 4 had to do with things like real-time financial data, trading platforms and real-time data involving naval ship positioning, threat detection and messaging.
For me, the ratio is more like 50/50, not 90/10.
My working habits would make me a bad fit for companies like twitter and their ilk, likewise people like Jeff would not do very well at companies like Wombat Financial or Raytheon.
What if v2.0 sucks and v3.0 sucks. I usually know/think v1.0 sucks, and sucks hard…
Essentially release or not depends on SW usefulness in it’s current state. If it solves problem cheaper, in shorter time or more comfortably than number of pulled hairs, customers scared away, houses burn, and planes crashed then yes - release. Problem for safety critical applications is that usefulness threshold is exactly zero crashed planes :o)
My vision : release first version as version 0.9beta
Then… once you have that feedback… you can release the "official: verision 1 
Testing
Having a devoted testing team, while they haven’t saved us completely (nobody can perfectly mimic a user), has helped reduce the amount of crap we ship.
The other thing to remember is to make sure you have an audience.
About a year ago, I released an early build of one of my programs as a tech preview and a way of gaining feedback about any bugs I didn’t know about. I released a second, less buggy version near the beginning of this year and am preparing to release a third.
To date, the only piece of feedback I’ve gotten was some guy on Wakoopa saying “Sucks!” I think one of the problems is the program is way too niche.
(The other may be because I’m really bad at figuring out what “good enough” is, and cut the rope at the wrong length. ^^ Oh well!)
Agreed. Ship it already. I am currently in the middle of project that is overdue and needs to ship ASAP. It’s not nearly ready, but the moment to hold my nose and ship is rapidly approaching.
What a perfect article, I just got finished with a huge project with a tiny timeline, and we lost a developer to a pregnancy right in the middle. And now I am bug fixing all month long with compromise after compromise.
Thanks for the perspective.
Just slap a Beta tag on it… that’s what Google does 