Version 1 Sucks, But Ship It Anyway

blog
81

There’s a couple of issues I’d like to address with this article

  1. First impressions might be the last

Many who try out software might only use it once or twice before discarding it judging it to be of “no use” due to annoyances and “small” issues and never coming back.

That makes providing a polished experience with everything from installation, getting started etc to the actual interface very very important.

  1. User-driven developement

Iterative developement is clearly the best way to develop software, no one is going to design and build the perfect software in one fell swoop. Getting feedback and bugs reported can be very useful. However letting the users drive your development is usually a big mistake.

First off users lack what you might call the “cohesion of the design” that the designer has, you can’t build software to please everybody but need to inflect the user interface to avoid builing a frankenstein hybrid between a car, truck and landmower that no one wants. What you chose not to put into your application is more important than what you put in.

Secondly, to paraphrase Steve Jobs “The user doesnt know what the hell he wants”. You should never ask a user what he wants, only what problems he has, and what goals he is trying to achieve. Then it’s up to the designer to come up with a proposal and then perhaps get feedback on it. Start out with a smaller focus group for feedback before releasing it to everybody.

  1. The cost of doing major redesign/refactoring once you ship is exponentially higher. If you ship your product and then realize you left out some important piece of architecture or concept it will be very hard to implement, first you have to convince the powers to be that you should be allowed to do it, and then handle the users who might have gotten used to the interface and then provide version compability.

Software in development is agile (with the right designers/programmers), shipped software is rapidly solidyfying concrete.

  1. Aren’t we tired of software that over promises and under delivers? Nowadays it’s almost the default to start hyping your software long before it’s released, release a crappy and/or or buggy alpha and then spend two years before the application is finally “decent”. Meanwhile only the most dedicated users have stayed around.

One day someone is going to release a unhyped piece of well-tested and innovative software and I hope I’m alive to see it :slight_smile:

  1. Programmers aren’t designers. This is a delicate subject sure to piss of alot of people but sadly it’s through. Most programmers can’t design, but most think they do. It’s unfortunate that alot of software is built without some kind of interaction designer ever been involved.

You only have to look at alot of software to see that most maps more clearly to the programmers vision of doing tasks than the users needs and goals. There are a few exceptions, programmers who also can design, of course every programmers thinks he is one of them (even me) but must aren’t.

Get a good iteraction designer, it will make a world of difference

On the other side, designers who lack understanding of technical issues and possibilities won’t be able to do the most optimal design either, and unfortunately technical adept designers are about as uncommon as programmers who can design.

So to summarize my take on it. No software will ever be perfect, but be sure it’s polished and “conceptually” finished when you release it. It’s always better to release a little later and better than “on schedule” and flawed. That’s how you build user loyalty and not get content user but passionate ones.

Never ever ever release sucky software because that will be it and no one will care enough to give it a second chance.

(Sorry for the rant)

82

@Jeff Gordon: VMware Fusion comes to mind. When Fusion 1.0 came out, I bought it, knowing VMware was new to the Mac market. Parallels had already released their VM software for Mac long ago. I bought Fusion, and “suffered” through 1.0 (it wasn’t really that bad). As a reward, VMware gave 1.0 customers free upgrades to 2.0 when it was released. I was so happy with that, I bought 3.0 when it came out, even though it didn’t necessarily scratch any itches. That’s one model to solve the “who pays for 1.0?” problem.

@Joe: Don’t you gain a developer with a pregnancy, rather than lose one? :slight_smile:

@Jeff Atwood: I agree. Immeasurable are the number of things I’ve learned by releasing 1.0 and monitoring feedback that I never would have learned in a lab. After you see your program in the wild, you can really get to tightening nuts and bolts. Yes, each nut and bolt should be there in 1.0 and be more than finger tight, but it’s okay to save the torque wrench until 1.1 sometimes. (I’m talking about software, not cars or airplanes.)

83

I can’t agree more, and I can’t agree less.

When you ship depends on you, your team, your market, your risk, your cash flow, your sanity, your investors or lack thereof, your happiness, your experience, your upbringing and probably even your mood on the day you pick the day to ship. For every should and shouldn’t that someone takes the time to blog about, there are hundreds if not thousands of counter-arguments that are proven by successful companies and products.

I want to see us working in whatever way makes us and our customers happy. If we pull that off there don’t have to be any rules.

84

What about the unknown knowns? That is to say, the things we don’t know we know. I’m surprised by those quite often. :slight_smile:

85

Well, I never feel bad, and I never find feedback too useful.

There’s a difference between input and feedback, and a difference between problem domain and design feedback.

If you don’t know the thing you are trying to make, you can’t make it. That’s where input and learning your domain matter. When you undertsand the problem, you solve the problem instead of endlessly complicating it. When you don’t, it’s completely impossible to solve no matter how good you are at programming or interface design. If you have good input, you don’t really need the feedback except to point out bugs.

If you know what the problem is then feedback on the design you made is going to be largely useless. If someone can figure out a better interface that’s just as easy to program as the one you made and they are a secretary or engineer or whatever then you’ve got some serious problems. Not to say there’s not always simpler seeming ways to do something, but you should have already thought of them all already and chosen the best one that fits your problem (and your budget).

If you are getting big surprises it’s usually having no idea when it comes to the problem, but you should not only not be releaesing then but possibly not be starting til then. If you know the problem, and the users can outdesign you for a complicated system you are in trouble but that’s usually not the case.

The problem people get sucked into here is blindly adding features without understanding why the users want them. That doesn’t solve anything, just makes more mess. If you understand why they want them then you can address that. Or else determine it’s not worth the time an effort, offer them a bill to do more, etc.

Of course you don’t have control all the time or maybe most of the time depending who you work for, but if you require a lot of feedback it’s usually a symptom you made serious mistakes and you should not be releasing because trying to appease angry customers by hacking fixes on your bad design is only going to make it into an unusable garbage product over time.

86

Try Agile/Scrum/Kanban/Lean… I prefer Scrum and you will yield far better results as this is more focussed on What customer/stake holder wants…

87

I agree with GD’s comment about your cheapening our profession. Have some pride man! You are in a great position to improve our craft, yet you write articles about condoning shipping software that sucks.

Grow up man and take some responsibility about what you say to your +100K readers. Your words mean something you know. As someone that is trying to turn our craft into a profession, you are not helping!

88

–If users haven’t been using your software before you ship it… You --have already failed.
–John Sonmez on December 5, 2009 4:39 PM

I totally agree with mr Sonmez, and all the oters who said “Agile”, “Iterative development” and scrum or other software building ideas.

I do understand part of the blog, but I don’t see why someone like you (an expert on coding horrors and a perfectionist) would be advocating this type of releases with as primary reason: user feedback. I’m sure you are using agile development theories, so I must be missing something.

So what I try to ask is, what are we missing?

(Also about iterative development, I can really really recommend Craig Larman’s Applying UML And Patterns: an introduction to Object-Oriented Analysis and Design and Iterative Development, long title I know, but really a great book about I.D, I’ll try to put up a review about it on my blog. (http://roy-t.nl, or click my website)

89

@Mitch don’t take it so hard. It’s just smack-down at it again.

See you can’t just make a rational, well argued point, you have to take extremes and shove it down someone’s throat, which doesn’t really work for this particular post (or any if you ask me).

I have to say, the writing was very cloudy. There were a few times of the “but this is wrong” rhetoric that I completely lost what the point was. Then I realized I don’t care.

90

The approach is totaly correct,
Alpha testing should be more on the security part , other aspects of the software must be handled by the beta phase where the annoying and frankly users will reach the system.
Best Regards.

91

I blogged about this same issue from a personal application standpoint!

Here is the URL: http://oldschooldotnet.blogspot.com/2009/02/so-finish-something-already.html

It feels good to actually agree with you once in a while :slight_smile:

92

A couple years back, fresh out of campus, we were thrown onto a project that required us to create a nationally integrated system with several other players. Of course, we were given the project three months after everyone else. But we stuck to our guns.

Our code was buggy to say the least. Functionally, the B word is Bad. But we did release. And it basically broke all over the place from day 1. But then, as Jeff pointed out, we could easily fix problems and in the real world, the fix was something we would never have foreseen (in all our code monkey wisdom). Also it helped that with the spec changing every week, it was amazing the amount of things we WOULD HAVE misconstrued but didn’t, because it was pointed out by real end users. Not testers (in all their wisdom).

Those first two months were rocky to say the least. However now three years later, v3 has been running for 21 months with only minor bugs. And (un)surprisingly our system was has faired pretty well against the other systems. And has been hailed as an overwhelming success. All because during development, we got it mostly wrong :slight_smile:

93

Jeff, I don’t know why you always want to cheapen the profession. Bugs are tantamount to mistakes, and mistakes in any profession are best avoided or fixed before your customer sees them. Especially if they are glaring, in-your-face mistakes.

You should also either go easy on yourself, or try harder. I’ve been 90 - 100% HAPPY with every bit of software I’ve released, and absolutely smitten when the resulting bug fixes are relatively few and mostly trivial, and occassionally devistated if anything major comes back. I’m certainly not getting ready to take notes on the flood of issues/bugs/abuse coming back on what I’ve shipped, like you suggest I should be doing. And what other profession operates this way? None that I can think of. None that would hope to stay in business for long.

If it’s not a beta release or a release that is agreed by all to be for user testing, then it should be your best effort at a sound, final product. I guess it depends on your definition of “shipping a flawed version”, but taken at face value, this certainly doesn’t sound like a product I’d want to be selling or buying.

94

Incredibly refreshing words. Just released a drastically scaled-down 1.0 a week ago to the iTunes App Store, and had some initial pangs of guilt about it.
This post definitely soothes me a little bit more.

95

Can we downvote this post?
This is exactly the sort of talk you hear from software dinosaurs refusing to adhere to best practices.
If you release a beta, you should be addressing all the issues you mention here, without frustrating your user base.

96

I hanker after the old days of console game development (and it’s also true now on certain platforms).
You couldn’t have any bugs left in the game at release. None. No excuses. Just no bugs.
I think we were better programmers back then - I’m much more lazy nowadays, and it’s a shame.

97

v1.0? Fools. Real software is distributed as v0.1, before it even does anything useful, as source. Then everyone that finds it, can fix a bug, add a feature, etc, and re-contribute it to the project. Then by the time you got to v0.9, the project is basically in full working order, and doesnt suck.

98

I think you are right.

I believe that looking at commercial part of a software business we cannot afford to streamline and perfect a software for ever and ever.

We have to draw a line.

I personally believe that we should always have some defects in software otherwise how are we going to develop V 2 of that software!

I adopt this technique in my software so that I can always give a new version to my customers. But I also take care to give my customers more than they have asked for so basically I am not cheating them in any ways.

Just my views though.

99

I feel the software should be released to the customer only when it has passed all the stringent quality tests that have to be setup by the QA team. Surely after the customers use the product, there will be significant real world issues that crop up. But a developer shouldn’t expect to be fixing issues such as the software crashed after using the application 10 times after it’s release.

If the software can’t reach the acceptable minimum threshold set by the QA, then we perfectionists should wait [:D]

100

Christ… of all people you have to quote Donald Rumsfeld. The guy credited with letting Bin Laden get away by ‘saving costs’ and not sending in more troops to the Pakistani border.

Other than that we all agree in principle that shipping schedules have to be realistic, and failing that, the software being shipped should reflect as close to that shipping schedule as possible.