The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How do you provide patches to users?

Say a customer found an issue and you fixed it. Do you rebuild and send the whole setup or just send the changed binary?

Friday, September 21, 2007
Distribute your application as an installer, and make your product such that a new version can be installed over an old version while keeping any user settings and/or data intact. If you have set up a decent development environment, a regular build yields an installer, which you can send to you customer instantly.

The problem with sending a customer a single binary is that you have to include instructions: Where to put the binary, add a registry key, leave this file alone, delete that file, change a setting in a third file etc. Experience has taught me such distributions are a recipe for disaster.
Jeroen Bouwens
Saturday, September 22, 2007
These days even a 60-MB installer can be downloaded in a matter of minutes for most users.  We haven't considered "patch" products in years.

Our target market is enterprises with wide Internet pipes (1Mbps or higher) so YMMV but building a small, fast download is just not an issue for us.

Additionally, you want to get away from scorch-fixes except in the most dire emergencies.  Allowing clients to dictate your release cycle even for hotfix items is suicide - you'll spend all of your time debugging, testing, packaging and distributing individual fixes for one customer after another and won't leave yourself any time to improve your product.

Think of it this way.  With enterprise software, with few exceptions, no matter how loud your client is screaming he's unlikely to switch from your product if you delay him even a month for a fix.  Yes, he has a problem; yes, he's paid you good money; but in the long run it's more important for his business that you have time to release bug fix hotfixes on a regularly scheduled basis and develop new features for him than for him to get a new build to fix his pet problem tomorrow.
Karl Perry Send private email
Saturday, September 22, 2007
What Karl has brought up is a different topic, but I disagree with it as blanket advice. If I find a critical bug in an application (like data corruption or security) that is actually affecting a customer who has reported it, EVERYTHING stops and 100% of resources go to fixing that bug yesterday.

If you don't do this, you should instead consider issuing a product recall press release. If you just decide to take your time fixing something critical, legally you are liable for all damages, regardless of what your unenforcable shrink wrap license says.
Saturday, September 22, 2007
I maintain an in-house system from off-site.

The setup used to be easier for me.  When I sent patches, I would send just the changed source file, and the new system would be compiled there.  Due to some program changes, the setup had to be changed and it got more complicated.  At the same time, my boss got busier with other things.  Consequently, I recently quit sending patches.  Now, I always send a full iteration.

The latest iteration which includes the executable, the full source (for safety), the schema, and some project control files is just under 1 MB of .zip files, so transmission is not an issue for me.


Gene Wirchenko
Gene Wirchenko Send private email
Saturday, September 22, 2007

With his advice, you can ask any customer what version they are running, then go to your source control and know exactly what is going on.  If you provide an updated DLL here and there, you'll never know exactly what they have and never be able to reproduce or diagnose the issue completely.
Saturday, September 22, 2007
Scott, you hit on the two primary things that will stop our developers, too.

But if a bug has a workaround or it does not corrupt, or it is not stopping a critical form, it doesn't make sense to stop the presses and get it to the user yesterday.  Again, we've played that game before and doing so ultimately slows things down, it doesn't speed them up.
Karl Perry Send private email
Saturday, September 22, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz