RE: Delaying Patches is Problematic

SSC Guru

Points: 734522

January 17, 2017 at 8:47 am

#1923196

roger.plowman - Tuesday, January 17, 2017 6:48 AM
The problem with automatic patching over the long term is cruft. It also means bloat and all that jazz.
MS is perhaps king of backward compatibility--I have successfully run GWBasic from MS-DOS 3.1 on Vista (haven't tried it since then...) but that's some SERIOUS backward compatibility.
Unfortunately, many developers don't follow the published guidelines and things like SQL Server are constantly deprecating features.
Patching implies correcting errors in 1 version of the software and that's all well and good, MS's automatic approach is the correct one for Windows and .Net--but the sheer size of both makes guaranteeing a patch works on ALL hardware combinations and ALL drivers impossible. Most of the patching stories we hear about affect a small percentage of users. But a small percentage of a billion+ users adds up quick!
Personally I think the answer is vanilla development, but vanilla does not the vast crowd enthuse.
KISS, in other words. Avoid third party libraries and controls. Avoid the latest whiz-bang features that may not be around in a month's time, much less 5 years. Avoid long chains of services, especially third-party ones. Demand API contracts that WILL NOT CHANGE.
Of course that makes for some pretty tame software :unsure: but it *works*. Call it the "AK-47 design philosophy". Crude, plain, but capable of absorbing punishment that would leave other software a smoking ruin.
Then at least you have a chance of keeping it patched and operating. :laugh:

Certainly there can be bloat here. Not much to do here, but patching helps.
I'm not sure I agree with avoiding third parties. While not every small library might be worth updating, plenty of popular ones are updated, and more importantly, they get additional screening and patches from the security standpoint over time. Managing that, and ensuring you have good security, is tough from a individual standpoint. There are no shortage of stories from people that assumed their code was secure, or well written, and it wasn't. Also, developing patches for your libraries can be harder than just applying patches from a well known source. There's the time to develop, as well as the expertise to get the patch built.
That being said, I don't want to say buy everything instead of build it. You have to make choices, not be afraid to change if necessary, and do what's best for your organization.