@Simon
Like many other posters you are being a little obtuse and missing the point that “releasing” your software to a large team of testers and a simulated office environment fits exactly with what Jeff is saying. Here your “customers” for the first few (many?) releases are the testers, whose feedback you then use to iterate on the product. You then release “Version 2” to the real customers.
Agreed, for sure.
The only exception is when you have something that would generate tremendous forward-compatibility issues or that can’t really be fixed in the future unless you fix it now.
-Max
What happened to the mentality of “Ship half a product, not a half-assed product?”
I think that the sentiment should be “Version 0.5 Sucks, But Beta Test It Anyway”. By the time you get to V1, you should already have gotten it out in front of real users in the real environment.
Version 1 should not suck, and you shouldn’t foist sucky software on your users.
How does this apply to the worlds of
-
“you have to ship this on Whatember the Xth, with all the features we wrote in the first doc and all the features we asked later for free” (also known as “Service” world)
-
“sure, version 1.0 will have this feature, and it’ll be available on Wathember the Xth” (also known as “Product sold to other companies by desperate salespersons” ?)
I wish choosing when to release was really an option, and I could listen to customers feedback. However no matter how perfectionnist we get, the only feedback that I tend to hear is “this does not work”, “this does not work as I expected” or “this does not work as I need it to”.
The counter-point to this is never to release an interim product. That is, a version that implements things differently than the final version does.
I had this problem with a community* website I developer in 1998 as a quick and dirty interim site while the final version was still in production.
Due to a lot of different issues, the “interim” site is still the production site 11 years later, with nearly 30,000 records that will have to be imported and verified whenever someone (not me by preference) actually creates a new version of that site.
*As in I didn’t get paid to develop it.
tim on December 4, 2009 7:20 AM - had I a big old rant prepared in response to this article. But you nailed it on the head.
And to add…
“Stating the obvious” articles like this really infuriate me. Seriously, if you’re as unhappy about every software release you’ve put out there (as you state at the beginning of this article) then why stay in the biz? If I was that unhappy with everything I’d produced in my day job then I’d be seriously thinking about a major career change.
Don’t get me wrong, I love writing code, I love writing good code, I love writing bug-free testable code and all those other good things, but seriously Jeff, portraying yourself(/us?) as some kind of martyr(s) to the cause of releasing perfect code is tiresome stuff. It’s our job.
How about some more articles on some of the challenges overcome when building the SO trilogy, that’s far more interesting and practical than this fluff. I know you can do better.
I believe what Jeff means (and certainly what I said in the ‘if you aren’t embarrassed by v1.0 you didn’t release it early enough’ article linked to above) is that it is OK to ship a v1.0 with minimal features, thin documentation and/or a less than beautiful GUI. But it isn’t acceptable to charge customers for a product that crashes all over the place, gives incorrect results or corrupts data. Obviously acceptable quality levels differ for a web log analyzer and an air traffic control system.
Great post, Jeff! I just wish they had touched on this “real world” stuff in college.
Having released an Android game back in March, I can honestly say I am embarrassed by my 1.0 version, but as you said, there is nothing, NOTHING, like getting real world feedback from your customers. They’ll actually tell you what they want, and really yell at you for the things they don’t want, but it’s all good!
I just wish my day job had this much exposure to actual customers. Ah - the corporate life…
I resigned yday just because I got rushed (long hours, stress, lunch at desk, missus left me) through our biggest project this year.It was paramount to release it beginning of November. and after that it came out we did not have an external client so it is not used. so if you can afford it, then take your liberty to leave 
Now, I’m not saying you should release crap.
So trust me on this one: even if version 1 sucks, ship it anyway.
So basically you’re saying to release something if it sucks but is not crap, but don’t release it if it’s crap that sucks. And you provide absolutely no metric or even thought as to what is “crap” vs. what “sucks”. So basically your whole post is a meaningless rant about releasing stuff somehow earlier than people normally would, but not so early that there would be consequences of releasing earlier than normal … ie. never.
Gotta say, this is not one of your better posts.
Just re-read my post, and it came across a bit harsher than I meant; “meaningless rant” isn’t exactly true. But hopefully you catch my drift; saying “release early … except when you shouldn’t release early” and not actually discussing the issue of “well when exactly is earlier than normal but not too early to ship?” kinda avoids dealing with anything real, and leaves this all in the high-level thought (aka fantasy) realm of discussion.
Anyone who found themselves nodding along with this article would REALLY enjoy the writing of Eric Ries.
Eric maintains a blog, “Lessons Learned”, and is (AFAIK) one of the earliest and most vocal proponents of the “Minimum-Visable-Product” philosophy.
Crap. That should have read Minimum-Viable-Product.
I think there is a difference between polishing the product (visible to the end user) and polishing the product (visible to the developer). I think cleaning-up code at the expense of a later release is a bad idea. Cleaning-up code to fix known bugs that the user will see is a good idea.
In the real-world (not the imaginary agile world of just-in-time bug fixes for web pages, but medical devices for example), you can’t ship buggy code. Everything must work on V1.0; you don’t let the patients and the doctors beta test your buggy software. If you think firmware programmers are expensive, try lawyers.
Am I the only one who interpreted “things wrong” as things that don’t work the way the customer wants or expects (interface/training issues), as opposed to things that don’t work at all (bugs)?
Our version 1.0 was awesome, that’s because we were 4 months late (4 months according to management, 2 months according to me and tech team!)
It’s our version 2.0 that sucked - that’s because it was released on time 
Thankfully, all the sucky bits are/were behind the scenes and so far the nastiest problems were handled before the users spotted them (touch wood).
@Simon, and a number of others: You sound like the ones being obtuse. I work in heavy manufacturing, where a minor but important mistake could mean a user’s lost hour, a thousand-dollar lost sale, or a million-dollar factory crash. So we have a whole testbed, and will mock up larger testing facilities as necessary to ensure that it works as we need it to. We certainly don’t throw software into production no matter how much testing the company claims to have done.
Yes, the scale is much higher - we expect software to be at 99% instead of 90%, even if it costs ten times as much and takes ten times as long - but we also expect to be able to bang on it before it’s done and send our feedback, because no application’s ever been perfectly polished or perfectly fit our needs, no matter how well we tried to spec it out - in-house, outsourced, or off-the-shelf. Sometimes we even run on half-baked systems because it has to be done now. The risk of losing profits from falling too far behind the competition is too great to demand perfection.
The only place attitudes like yours are valid is when there is no competition and lives are at stake. But the software you write is no more “grown-up”, it’s just polished to more 9s because you might be liable.
Surely there will be parts of the software that sucks, but the important question is not whether we should still ship the software.
No, the important question is, can we sell those parts as additional feature.
So true. Even major releases should be considered “v1” releases to some degree. Last month I released Paint.NET v3.5 after over a year of working on it. It had a lot of significant and tricky under-the-hood changes. After watching my inbox for a week I found some really bad/strange/rare bugs that people were running into. But I would’ve never found them in “the lab”! Two weeks later I shipped a “.1” update that fixed most of the issues. If I’d waited another 2 weeks, guess when those bugs would have been fixed? Yup, another 2 weeks.
In .NET you can get really nice call stacks when things crash; in fact, if you plop the PDB next to the EXE and DLLs, you get line numbers. Make sure these crash logs get to you! On a web app it’s easy, just toss it somewhere appropriate on the server. On the client it’s a little more difficult but doable (mostly to find a location that won’t “fill up”, or get annoying, etc.) Along with this, I watch to see what crashes happen frequently and then I put a try/catch block around those specific lines. But, I don’t handle the exception. I rethrow a new exception that includes extra detail that I hope will help me fix the problem – for example, “the size of the image is ____” or “i tried to allocate ____ bytes and failed”, or “this object [was/was not] disposed”. If it’s an argument out of range, I make sure to include the argument’s value as well as its acceptable range, e.g. “y=-1 but the allowed range is [0, 20]”.
So if there’s a bug in version N and I can’t reproduce it, then by the time version N+1 gets released I’ll start getting more info back on that crash. Hopefully for version N+2 I can then fix it. This all helps to relieve a lot of the anxiety around, “omg we need to ship” vs “omg we need to wait”. If you can’t solve a bug that people are reporting … add instrumentation, release anyway, then fix it for the next “dot” update.
(Oh and v1.0 of Paint.NET was pretty awful. But it worked!)