Why the Update Fever is Bad

I just got asked by a customer why there hasn't been an update for several months now for one of the software products I create . And if this means that this software is dead now. I'm really baffled by this. Especially because that product has already gotten nearly a dozen free updates, and is pretty stable and bug-free by now.I just updated Windows 10 on my main development PC with the Fall Creators Update , causing several of the software I use to have failures, or degraded performance. And worst: Some of some very old Microsoft Office tools I still have to use occasionally (for backwards compatibility for some customers) even completely stopped working after the update.Googling for the error messages I get, I find that a lot of people have the same problem. This is something new for Microsoft: Usually they won't break their own old software with updates, they are known for keeping up backwards compatibility at all costs. Wondering why this is. Purpose? Sloppyness?Software users are now trained by this behavior: An app or software now has to update at least once a week, or month, otherwise it is considered dead. If you ask the users about it, they don't even know why they want these updates. Is there a feature they are missing? A specific bug they want to have fixed? They don't know. They only want updates, because they are used to it.Especially for development software, it is better sometimes not to update that frequently: It could change a feature you are relying on, which causes a lot of work for you to adapt to that new update. Or worse: Even introduce new bugs.So for non-security critical software, it is sometimes better not to update that often. This update fever is bad both for developers and users.

fifteen comments, already:

Bug fixes and various improvements code for keeping product in your mind

Anonymous - 18 11 17 - 06:38

Just give it a new version number and push out the same software. Easy

Earl Grey (link) - 18 11 17 - 10:34

I think this cant be seen without considering how the user paid for an update. If its a (today also very popular) subscription model, the user should expect regular updates (if the user isnt paying for storage or CPU resources).

But I also think the old days are over, where a software developer releases a new version when the old one is so old it doesnt start anymore. Constant incremental updates can also be a slow update path for that nice feature you used to use to some new alternative software function (instead of a hard break with the next software release).



Its good that Windows ditches old functions/APIs finally. All that backwards compatibility has made windows a very bad system. My girlfriend installed a printer driver via INF and was presented with an Windows XP dialog which defaulted to “a:” as path .

Mark - 18 11 17 - 10:41

I agree with you.



Many beautiful programs that I love only receive a few updates each year, and customers constantly ask if they’re abandoned, even though the developers have a proven track record of yearly updates that can be very easily checked.



Nikolaus! You MUST not let your encounters cloud your mind with sadness! WITHSTAND the barrage of distress! DON’T let the encroachment of sorrow emblazon your mind with hatred! You MUST stay STRONG! You MUST stay IMPERVIOUS!

wild master - 18 11 17 - 14:05

> So for non-security critical software, it is sometimes better not to update that often. This update fever is bad both for developers and users.



Non-security oriented software may be a security issue and require an update to libopenssl or similar to close a security hole it didn’t know it opened.

Piotr Gabryjeluk (link) - 18 11 17 - 15:12

[devil’s advocate hat: on]



I don’t understand. What’s stopping you? Do you not know of any bugs in your software? Or are they all so deep and complex that they would take prohibitively long to fix? Or is your release process so inefficient you can’t ship a new version every week or two?



Asking for bug fixes (or performance improvements, or whatever) is not asking for interface changes. Surely you have bugs you can fix while maintaining your current interfaces. Your interfaces may not be perfect but you’d have to have screwed them up pretty bad for it to be impossible to improve anything else without changing them.



If you’re afraid to release an update because you’re afraid that fixing one bug could cause even more bugs, that’s a troubling statement about the repeatability of your process. How did you ever write the software in the first place, if you couldn’t tell if any solution you implemented wouldn’t cause more problems than it solved? That would make me not trust your software at all.



What does “non-security critical software” mean these days? Almost every program works with untrusted data from the internet today, like image files. Your apps aren’t sandboxed, so I would definitely consider them to be security critical. They aren’t signed or distributed over a secure connection, either, so I’m not sure how I can trust them at all.



I see a lot of hypothetical excuses, but I don’t see a good explanation for why updates are inherently bad. Microsoft had a bad release of Windows, therefore you’re not going to fix any issues with your own software?

Sam - 18 11 17 - 17:29

Had the same idea as Earl Grey… But in response to Sam, even with the funny hat on: IMHO the arguments do miss the point Niko made in the post, namely that there simply aren’t any relevant bugs to fix (at least that he knows of) – and nothing indicating a bias against security updates. So probably that hat is made of tin foil…



What in my experience does come out of the “constantly update” paradigm is not so much an incremental improvement, but even more pressure to add new features, even if they are complete shit and mostly not working, because “it is what users expect”. We can then fix it with the following updates – which rarely ever happens as these shall then include other new features, of course.



Then again: Security updates and other bug fixes are another thing entirely (and do at least ameliorate the previous point). That sometimes something goes wrong isn’t new – it is about as easy to break software with an update as it is to make not working software in the first place, and it wasn’t the first time nor will it be the last that Microsoft sent out an update that broke stuff.



It may even be intentional, even if that sounds like an evil scheme (note that this is hyperbole): If a particular interface is deemed broken beyond fix it might be best to remove it (invoke an analogy with cancer at your discretion, I won’t). Now in this case apparently it didn’t work out so well, but there have been numerous APIs over time that just disappeared, and it was for good. So while the outcry is legitimate to a point we may start to exaggerate the issue out of proportion.



And yet back to the actual issue: I still think Earl Grey has the best solution – just publish an update every couple of months with a new build number, which will without further interaction give an indication that, yes, this program is still maintained.

xaos - 20 11 17 - 07:46

Month ago im back to Win 7 after year of using Win 10, cause Win 10 is horrible OS…

Vitaliy (rolevix) - 20 11 17 - 09:43

So we should stay with Win98se because it is already stable ?? We should not compete with other engines because it just works right now ??

Seriously niko I challenge you to put status at Steam and your website saying that you wont update Coppercube anymore because there is already tons of updates and you afraid that you will break stuff up. Heck just copy paste this blog status and put at steam and your website and see the responses.



Maybe tim sweeney should just maintain unreal engine 1998. Or johm carmark should just stay with doom1 because it just works.

People buy your software not just for the software alone, we buy the software to support you and have your commitment with the product. When I found out that you are busy doing your game and just left the coppercube the way it is now , I kinda dissapointed with you. You dont even use coppercube for your games right ? Just shows something can be improve your engine. Why dont you use coppercube for postcollapse ?

labu - 22 11 17 - 05:12

Labu, CopperCube is the main product of my company. It is and will be updated. And PostCollapse is using CopperCube.

niko - 22 11 17 - 05:14

Why is it in your blog you mentions that when you tried Javascript it is too slow. So you convert it to C++ ? What version of coppercube are you using then ?

labu - 22 11 17 - 06:40

If you are using coppercube just as a level editor or placement editor for your ingame objects, that does not count the same as using Coppercube for your game development. If you dont even believe or use your own product , why should we ?

labu - 22 11 17 - 06:43

He is using CopperCube Pro. Click Help -> About, there you download the full C++ code.

erik - 22 11 17 - 06:53

If that is true, why dont he implement all the changes he made in Coppercube postcollapse c++ into the main product? He just said at his blog that Coppercube is already good and no changes are needed? The reason he changes to C++ because Javascript performance is poor. I believed he said that at this blog. So the main product does require some changes right? since he himself cant use it for his game due to low performance.



Based on his logic, maybe I should buy RTS creator on steam, you know one of the abandon software by the developer at steam. We dont need all the changes, updates and feature enhancement are bad for both developer and user.



We buy your product for your commitment and your time. If you dont bother to support us by improving the product. Might as well just be a fulltime game developer and tell the user the truth that you are busy developing your games and you dont have time to improve Coppercube anymore.

labu - 22 11 17 - 09:56