Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 1 down vote favorite

So, I think it look pretty bad when you release an update and pull it off the web. I'm pretty sure this has happened for at least two of the the last three Delphi XE2 updates. I'm not complaining because I'd do (and have done) the same thing.

The only problem is, how do you do this gracefully? And, how do you alert the 10-20 facilities ( 500-2000 end users ) who downloaded your awful software that what they downloaded is no good, but what they're going to download is super awesome?

The reason I ask it is because I work for a small business, Embarcadero is a big(ger) business and we do the exact same dumb thing when our release is found to be deficient. The problems might be as simple as a file missing or even a legal problem, the code might be perfect and there still might be problems with the app.

share|improve this question
why is the original no good and the update super awesome? – user1249 Dec 15 '11 at 17:22
the original would have been super awesome too, but I replaced select with delete in all my SQL queries and check it all the code 4 minutes before compiling the release. – Peter Turner Dec 15 '11 at 17:25
4  
In that case you probably did the same again in all the updates. – user1249 Dec 15 '11 at 17:30

4 Answers

up vote 6 down vote

Well, the alternative is to not put it up on the web in the first place, by not releasing untested software. Your automated testing should catch "stupid" mistakes like replacing all your select statements with delete statements, and it just shouldn't get that far without at least some smoke testing.

But if it gets out the door, I don't really see any alternative to pulling it down, communicating to your customers that they should roll back to the previous release, and publishing a fixed (and fully-tested) release ASAP.

share|improve this answer
Alrighty, I guess this might garner votes, but it's just the obvious answer and the obvious course of action, I'll edit what I was going to say into the question... – Peter Turner Dec 15 '11 at 18:11
@PeterTurner: No offense, but if running some tests before releasing software was that obvious: you'd be doing it already. Fixing the problem is important, but it's more important to learn from the mistake and make sure that it can never happen again. My company releases very large software to some pretty high profile clients. QA is in charge of what makes it out the door - definitely not dev. – Steve Evers Dec 15 '11 at 21:48
@sno No offense taken, we just don't happen to have a QA dept. So the boss is like, 'you pretty sure this works?' and we're like 'what could possibly go wrong' and that's the green light. If we landed a 14 million dollar contract making dental software for the coast guard, then yeah we'll think about a QA dept, for now it's pants and seats. – Peter Turner Dec 15 '11 at 22:01
You don't need a QA department to do tests. Some automated unit tests that run as part of your build and cover the risky areas of your code are way, way better than nothing. And at the very least, installing the software in a test environment, starting it up, and walking through the major features will catch anything as blatant as "replaced select with delete in all my SQL queries". I really don't see how you can be "pretty sure this works" without at least running unit tests and doing a quick smoke test. – Adam Jaskiewicz Dec 15 '11 at 22:38
up vote 5 down vote

Generally we have found it more successful to release an update to the update and flog that rather than pull the thing down. Pulling things down typically generates bad press and consternation. Multiple updates just make people think you are cool like google.

share|improve this answer
Understand that an update to an update in quick succession can still infer there was something wrong. Also, if the update process is not very streamlined/integrated (such as the user having to go out and pull the update from a site and install it) having multiple updates in a short time can cause almost as much frustration as having to roll back and then re-upgrade. – KeithS Dec 15 '11 at 21:17
up vote 2 down vote

10-20 people? Why not manually distribute a beta to 10, 20 people and then get their feedback before going online?

share|improve this answer
10-20 people, in this case means 10-20 facilities = 500-2000 end users. That's a good idea though and something we may need to do in a more serious manner for every update, not just the big ones. – Peter Turner Dec 15 '11 at 20:07
up vote 1 down vote

First, I would streamline the update process; try to integrate updating into the startup of the application itself (ClickOnce, perhaps a web service that's invoked on startup to check for updates and can automatically pull and apply said update). That makes upgrades less of a pain and thus you are able to release them more often if necessary.

Then, simply release an update to the update. It may help to somehow mark the update as "critical" and prevent users declining it (if they ever have the option). With the more streamlined update process, you'll cause fewer headaches, and you'll have less chance of people asking too many questions; you'll be seen as "responsive to user needs".

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.