I've been unhappy with every single piece of software I've ever released. Partly because, like many software developers, I'm a perfectionist. And then, there are inevitably … problems:
I second what Bado said.
There is a difference between the functionality of software and its internal architecture. I think what Jeff is talking about here is the internal architecture of the software you release may not be exactly to your liking but the functionality should still work correctly without crashing or serious bugs.
For example maybe there was no time to wire in a IoC container and poor mans constructor injection was used instead. Or certain
components were not factored exactly to our liking but after we ship V1, we get feedback that the feature supported by those components is not needed. If we had spent time refactoring those components it would have been a waste of time and would have delayed the release.
It’s not just version 1 but recently it appears may major releases of software are riddled with bugs… some like Adobe’s Premier Elements 8, which I had the misfortune of buying, are almost unusable.
The problem is that most software companies feel compelled to release a new version every year or two without even bothering to issue patches for the bugs in the last release.
MartinC: "Yet again Jeff is thinking soley in terms of web software, desktop PC software and devices that can update simply, and forgets about the world of non-updateable embedded devices."
The notion that a short blog entry addresses all possible situations is a bit silly. One would hope that an intelligent reader would be able to determine reasons the advice might not be applicable to their situation.
Thanks for that great post Jeff. As always on coding horror, you see things spot on.
It’s worth noting that web software makes it soooo much easier to release a crappy “beta” version without (too much) guilt, because you can deploy the changes and bug fixes to all your users very fast. It’s not so easy with desktop-based computer, even with automatic update systems.
It’s also worth mentioning that the most annoying users who care enough to take the time to complain about your product are worth A LOT, and we should cherish them. In fact, if nobody’s complaining about your product, chances are you’re falling into mediocrity.
“Version 1 should not suck, and you shouldn’t foist sucky software on your users.”
I think people are obsessing too much on the word “sucks”.
Atwood’s point is that to a perfectionist any version of any quality is going to “suck” unless it’s “perfect” (which is impossible).
Clearly, the version can’t suck from the customer’s perspective.
Boy, I really hope that my company’s competitors follow this advice to the letter.
That mostly what Agile is all about right?
Just don’t release software so poor your customers lose faith. That’s the hard choice - you can’t polish the software forever or you never get the first sales, but you can’t release a product so riddled with quality issues that you never get an additional sale (or worse, returns.)
Hi. So, I’m 100% cool with the idea of releasing v1 into the wild to ferret out the known and unknown knowns as a means of testing and refining your work.
But in the world of commercial software, who should pay for that v1? Should it be the developer - the person/company who will eventually release a fully-realized product and make lots of money on it? Or should it be the end users - the people who are paying to do the testing in the first place… HOPING they already HAVE a fully-realized product?
All in all, I’m ok with the end users paying something… but there should be some give and take with the developer of such a product to provide future versions to those early customers at a reduced (or no) fee at all. The problem with enterprise-level software today, however, is that the first customers don’t get freebies… they get screwed.
How do we solve THIS problem?
Yup; ship crap, wait for marketing and sales to start pretending they’re surprised that it’s crap, then improve it.
If your PR is good enough to placate the clients you just pissed off, it actually works. If not, you’re SOL.
Isn’t that how microsoft works?
Have public betas replaced embarrassing v1.0’s?
Yet again Jeff is thinking soley in terms of web software, desktop PC software and devices that can update simply, and forgets about the world of non-updateable embedded devices.
Amen!
(After 5 years of alpha and just releasing the beta)
And to add to that, it’s better to release something that has only some of the features you wanted to include, but is solid, rather than something that has all the bells and whistles, but crashes occasionally (all right, a lot).
It’s way better to be able to say, “We can add that in 2.0” than to worry about how many 1.x releases you’re going to need to make all the fixes that are required to 1.0.
I find it amusing that the Captcha for posting this comment is “American pos Itzhak” That reads as American POS, It’s a Hack… that about sums up most of the software I’ve worked on!
WA
MartinC
You have a point, but even in that case early internal releases are a good thing.
I think the real point is to get software out there (for varying definitions of “there”) and get it hammered as soon as possible. The later any mistakes get found the more they cost.
Thank You! That post just made my day. Cause we have just released v1.0 and the clients were disappointed by the lack of a fancy UI.