Latest won’t always be greatest

For more than a decade, it has been widely accepted that computer systems should be kept up to date. Those who regularly install updates reduce the risk of having security gaps on their computer that could be misused. Always in the hope that manufacturers of software always fix in their updates also security flaws. Microsoft, for example, has imposed an update requirement on its users since the introduction of Windows 10. Basically, the idea was well-founded. Because unpatched operating systems allow hackers easy access. So the thought: ‘Latest is greatest’ prevailed a very long time ago.

Windows users had little leeway here. But even on mobile devices like smartphones and tablets, automatic updates are activated in the factory settings. If you host an open source project on GitHub, you will receive regular emails about new versions for the libraries used. So at first glance, this is a good thing. However, if you delve a bit deeper into the topic, you will quickly come to the conclusion that latest is not always the best.

The best-known example of this is Windows 10 and the update cycles enforced by Microsoft. It is undisputed that systems must be regularly checked for security problems and available updates must be installed. That the maintenance of computer systems also takes time is also understandable. However, it is problematic when updates installed by the manufacturer paralyze the entire system and a new installation becomes necessary because the update was not sufficiently tested. But also in the context of security updates unasked function changes to the user to bring in I consider unreasonable. Especially with Windows, there are a lot of additional programs installed, which can quickly become a security risk due to lack of further development. That means with all consequence forced Windows updates do not make a computer safe, since here the additionally installed software is not examined for weak points.

If we take a look at Android systems, the situation is much better. However, there are enough points of criticism here as well. The applications are updated regularly, so the security is actually improved significantly. But also with Android, every update usually means functional changes. A simple example is the very popular Google StreetMaps service. With every update, the map usage becomes more confusing for me, as a lot of unwanted additional information is displayed, which considerably reduces the already limited screen.

As a user, it has fortunately not yet happened to me that application updates on Android have paralyzed the entire phone. Which also proves that it is quite possible to test updates extensively before rolling them out to users. However, this does not mean that every update was unproblematic. Problems that can be observed here regularly are things like an excessively increased battery consumption.

Pure Android system updates, on the other hand, regularly cause the hardware to become so slow after almost two years that you often decide to buy a new smartphone. Although the old phone is still in good condition and could be used much longer. I have noticed that many experienced users turn off their Android updates after about a year, before the phone is sent into obsolescence by the manufacturer.

How do you get an update muffler to keep his systems up to date and secure? My approach as a developer and configuration manager is quite simple. I distinguish between feature update and security patch. If you follow the semantic versioning in the release process and use a branch by release model for SCM systems like Git, such a distinction can be easily implemented.

But I also dedicated myself to the question of a versionable configuration setting for software applications. For this, there is a reference implementation in the project TP-CORE on GitHub, which is described in detail in the two-part article Treasue Chest. After all, it must be clear to us that if we reset the entire configuration made by the user to factory settings during an update, as is quite often the case with Windows 10, quite unique security vulnerabilities can arise.

This also brings us to the point of programming and how GitHub motivates developers through emails to include new versions of the libraries used in their applications. Because if such an update is a major API change, the problem is the high migration effort for the developers. This is where an also fairly simple strategy has worked for me. Instead of being impressed by the notifications about updates from GitHub, I regularly check via OWASP whether my libraries contain known risks. Because if a problem is detected by OWASP, it doesn’t matter how costly an update can be. The update and the associated migration must be implemented promptly. This also applies to all releases that are still in production

However, one rule of thumb applies to avoid update hell from the start: Only install or use what you really need. The fewer programs are installed under Windows and the fewer apps there are on the smartphone, the fewer security risks there are. This also applies to program libraries. Less is more from a security perspective. Apart from that, we get a free performance measurement by dispensing with unnecessary programs.

Certainly, for many private users the question of system updates is hardly relevant. Only new unwanted functions in existing programs, performance degradations or now and then shot operating systems cause more or less strong displeasure. In the commercial surrounding field quite fast substantial costs can develop, which can affect also the straight implementing projects negatively. Companies and people who develop software can improve user satisfaction considerably if they differentiate between security patches and feature updates in their release publications. And a feature update should then also contain all known security updates.

Softwarewartung – Projekte zukunftssicher gestalten

October 25 @ 08:00 October 26 @ 17:00

Schulung / Training / Kurs / Seminar – 2 Tage remote

Die hohen Investitionskosten für Unternehmen zur Entwicklung von Individualsoftware implizieren eine sehr lange Nutzungszeit. Das bedeutet aber auch das die Notwendigkeit gegeben sein muss, das die Anwendung stetig neuen Anforderungen angepasst werden kann. Ein klassisches Beispiel hierfür sind Onlineshops, die permanent die vom Gesetzgeber beschlossenen Forderungen innerhalb einer festgesetzten Frist umsetzen müssen.
Die meisten Aufwendungen im Budget eines Softwareprojekts entfallen auf den Punkt Wartung. Dabei wird der geringste Teil der Kosten für Korrekturen verwendet. In diesem Kurs lernen Sie wie Sie ihre Software Projekte zukunftssicher gestalten können um auf künftige Änderungen vorbereitet zu sein.

Durchführungs-Garantie: der Kurs wird auch bei nur einem Teilenmenden durchgeführt

Kurs buchen:

Jeder Teilenmende erhält eine gedruckte Ausgabe des Buches: Marco Schulz, CI mit Jenkins, Rheinwerk, 2021

Sollten Sie zu den angebotenen Terminen nicht können, beziehungsweise für Ihr Team einen individuellen Termin wünschen, um beispielsweise in einer geschlossenen Runde auf konkrete Problemstellungen eingehen zu können, besteht die Möglichkeit zusätzliche außerplanmäßige Termine zu vereinbaren. Nutzen Sie bitte hierzu mein Kontaktformular unter der Angabe welchen Kurs Sie wünschen, mit Terminvorschlägen und der zu erwartenden Teilnehmerzahl.

Weitere Termine:

  • 26.02 – 27.02.2024
  • 20.05 – 21.05.2024
  • 13.05 -14.06.2024

JCON 2020

October 30, 2020 All day

Hysterisch gewachsen – Wege zu einer stabilen API

Enterprise Software hat erfahrungsgemäß eine lange Lebenszeit, weswegen die Wartbarkeit ein wichtiger Aspekt während der Entwicklung ist. Wie aber vermeidet man das Chaos in Projekten, welches lang läufig als historisch gewachsen bezeichnet wird? Mit leicht nachvollziehbaren Beispielen, zeige ich wie man mit einer Schichtenarchitektur eine stabile API entwickeln kann. Dabei werden Fragen geklärt wie:

  • Qualität und Wartbarkeit
  • Architektur und Design Pattern für APIs
  • API Dokumentation und Versionierung
  • automatisierte Architekturtests

(Tools/Techniques: Maven, Docker, Rest, apiguardian, Swagger, ArchUnit, JUnit)

JCON 2021

July 10, 2021 All day

Rolling Stones – vom Release überrollt

Jeder macht es, manche sogar mehrmals täglich. Aber nur wenige kennen die komplexen ineinander greifenden Mechanismen, die ein vollständiges Software Release ausmachen. Deshalb kommt es hin und wieder vor, das sich ein Paket in der automatisierten Verarbeitungskette querstellt.

Mit ein wenig Theorie und einem typischen Beispiele aus dem Java Universum zeige ich, wie man ein wenig Druck aus dem Softwareentwicklungsprozess nehmen kann, um zu schlanken leicht automatisierten Prozessen gelangt.

{j}DD Poland 2021

November 10, 2021 All day

Refactoring Disasters: A Story how I failed

For my small Open Source project TP-CORE, you can find it on GitHub, I had the gorgeous Idea to replace the iText library for OpenPDF. After I made a plan how I could reach my goal I started all necessary activities. But in real life the things never that easy like we have originally in mind. I failed with my idea and in this talk I will let you know what happened exactly. I talk about my motivation why I wanted the replacements and how was my plan to success all activities. You will get to know how it was when I reached the point, I realized I will not make it. I give a brief explanation what I did that this short adventure did not affect the rest of the project.

BarCamp República Dominicana 2021

November 20, 2021 All day

API4Future: A journey how to create a stable API

By experience, enterprise applications have a long lifetime period. This is one oft the  reasons why we need to pay a lot of attention for maintenance. But how we are able to avoid chaos in the project? With some Code Examples in Java I will demonstrate how a stable API get developed. Some questions I will answer in this talk:

  • Quality and Maintenance
  • Architecture & Design Pattern for APIs
  • API Documentation & Versioning

JCON 2022

September 20, 2022 All day

Der grüne Punkt – Mythos Wiederverwendung

Als mir im Studium die Vorzüge der OOP mit Java schmackhaft gemacht wurden, war ein sehr beliebtes Argument die Wiederverwendung. Das der Grundsatz write once use everywhere – in der Praxis dann doch nicht so leicht umzusetzen ist, wie es die Theorie suggeriert, haben die meisten Entwickler am eigene Leib erfahren. Woran liegt es also, das die Idee der Wiederverwendung in realen Projekten so schwer umzusetzen ist? Machen wir also einen gemeinsamen Streifzug durch die Welt der Informatik und betracten verschiedene Vorhaben aus einer sicheren Distanz.

IT-Tage 2022 remote

December 13, 2022 All day

Refactoring – Eine kurze Geschichte des Scheiterns

Für mein kleines Open Source-Projekt TP-CORE, das Sie auf GitHub finden können, hatte ich die großartige Idee, die iText-Bibliothek für OpenPDF zu ersetzen. Nachdem ich einen Plan gemacht hatte, wie ich mein Ziel erreichen könnte, startete ich alle notwendigen Aktivitäten. Aber im wirklichen Leben sind die Dinge nie so einfach, wie wir es uns ursprünglich vorgestellt haben. In diesem Vortrag erfahren Sie was genau passiert ist. Ich spreche über meine Motivation, warum ich die Änderung wollte und wie mein Plan war, alle Aktivitäten zum Erfolg zu führen. Sie werden erfahren wie es war, als ich den Punkt erreichte bei dem mir klar wurde, dass ich so nicht zum Ziel gelange. Ich erkläre kurz, was ich getan habe, dass dieses kurze Abenteuer den Rest des Projekts nicht beeinflusst hat.