Eine Handvoll JAVA – Key Features der einzelnen Versionen

Veröffentlicht am 2026-03-16 von Elmar Dott

Die objektorientierte Programmiersprache Java wurde von James Gosling entworfen. Die erste Version wurde 1995 von der Firma Sun Microsystems veröffentlicht. Nach der Übernahme von Sun Microsystems durch Oracle im Jahr 2010 wurde Java Teil des Oracle Produktportfolios.

zu letzt geändert:

Die Java Serie

Java 21 LTS
Java 20
Java 19
Java 18
Java 17 LTS
Java 16
Java 15
Java 14
Java 13
Java 12
Java 11 LTS
Java 10
Java 9
Java 8
Java 7
Java 6
Java 5 / J5SE
Java 1.4
Java 1.3
Java 1.2 / Java2

Um Java-Programme auf dem Computer ausführen zu können, wird eine sogenannte virtuelle Maschine benötigt. Der Download dieser JVM heißt JRE (Java Runtime Environment). Wer selbst in der Programmiersprache Java entwickeln möchte, benötigt den zugehörigen Compiler, der unter dem allgemeinen Begriff SDK (Software Development Kit) oder etwas spezieller als JDK (Java Development Kit) bekannt ist. Das JDK enthält natürlich auch die dazu passende Laufzeitumgebung (die JVM).

Mit dem Erscheinen des Releases für Java 9 im September 2017 gab Oracle einen 6-monatigen Releasezyklus für künftige Java Versionen bekannt. Somit erscheint jedes Jahr im März und im September eine neue Version der beliebten Programmiersprache. Aber keine Sorge, es ist nicht notwendig, den Lizenzbestimmungen von Oracle zu folgen und in diesem Turnus die eigene Java Version zu aktualisieren. Um Unternehmen genügend Stabilität für die IT‑Infrastruktur zu bieten, erscheint jedes sechste Java Release als sogenanntes LTS (Long Term Support) und hat eine Laufzeit von drei Jahren, ab Erscheinen. Hierzu habe ich bereits einen tieferführenden Artikel veröffentlicht.

Der neue Java-Releasezyklus

Mit dem häufigen Releasezyklus kommen natürlich auch mit jeder neuen Java-Version einige neue Schlüsselfunktionen in den Sprachkern. Hier kann man schnell den Überblick verlieren. Folglich habe ich eine kleine Übersicht zusammengetragen. Wer sich zusätzlich einen Überblick über die einzelnen Java Enterprise Versionen verschaffen möchte, dem sei mein entsprechender Artikel zu Java EE empfohlen.

Java Enterprise in briefly detail

Versionsübersicht

Um uns nicht zu sehr in Details zu verstricken, beginne ich mit der Version 1.2, die auch als JAVA 2 bekannt ist und 1998 veröffentlicht wurde. Die wichtigsten Funktionen von Java2 sind die grafische SWING API und die Vorstellung des Just In Time Compliers (JIT).

Im Jahr 2000 erschien die Version 1.3 mit Funktionen wie JNDI (Java Naming and Directory Interface) sowie JPDA (Java Platform Debugger Architecture).

Gleich zwei Jahre später, im Jahr 2002, erschien die Version 1.4, die, die verfügbare Standardbibliothek um Funktionen wie reguläre Ausdrücke, Logging API, integrierten XML & XSLT Prozessor, Image I/O API und New I/O erweiterte.

Mit der 2004 veröffentlichten Version 1.5 änderte sich auch die Bezeichnung beziehungsweise die Zählweise der Versionen. Java wird als Majorversion hochgezählt, was so viel bedeutet, dass man fortan von JAVA5 spricht. Ganz der Analogie, wie es bereits bei der Version 1.2 der Fall war. Die Java5 Standardedition (SE), oder kurz J5SE bringt eine Menge Änderungen für den Entwickleralltag, Dazu zählen: Autoboxing/ Unboxing, Annotations, Enums und Generics.

Die 2006 erschienene Java6 SE erweiterte die XML Funktionalität mit dem StAX Parser, stellte JAX-WS für Web Services bereit und brachte den Scripting Language Support, der es ermöglichte, Skriptsprachen wie JavaScript auf der JVM auszuführen. Wichtigste Vertreter sind die beiden JVM‑Sprachen Kotlin (2011, JetBrains) und Scala (2004).

Lange fünf Jahre später und erstmalig unter der Regie von Oracle erblickte Java7 SE 2011 das Licht der Welt. In diesem Java Release wurde der Diamond Operator <> eingeführt. Weitere Maßnahmen, die Sprache zu vereinfachen und die Ausdruckstärke zu erhöhen, waren die Vereinfachung der varargs-Methoden-Deklaration und die Möglichkeit, in Switch-Anweisungen Strings zu verwenden. Auch auf die Aussagen, Exceptions seien langsam und sollten sparsam benutzt werden, wurde Rechnung getragen und das Exception-Handling verbessert.

// Diamond Operator
List<String> myList = new ArrayList<>();

// varargs (variable-length arguments)
public void myMethod(String... args);

// Diamond Operator
List<String> myList = new ArrayList<>();

// varargs (variable-length arguments)
public void myMethod(String... args);

Java8 SE machte mit der Erscheinung 2014 wieder einen erheblichen Schritt. In diesem Release spendierte Oracle der Java Community lang ersehnte Features wie Lambdafunktionen und die Stream API, um die wichtigsten Neuerungen herauszugreifen. Zudem wurde die Date & Time API komplett überarbeitet und Änderungen von der bis dahin weitverbreiteten JODA-Time Bibliothek inspiriert.

// ForEach Lambda
myList.forEach(element -> System.out.println(element));

//Stream API
myList.stream()
    .filter(element -> element.startsWith("A"))
    .forEach(System.out.println);

// ForEach Lambda
myList.forEach(element -> System.out.println(element));

//Stream API
myList.stream()
    .filter(element -> element.startsWith("A"))
    .forEach(System.out.println);

Mit dem Release 2017 für Java9 SE kam eine Zäsur. Wegen der Einführung des Modulsystems wurde die gesamte Standardbibliothek umgearbeitet, damit die einzelnen APIs nicht mehr in einer gigantischen JAR zusammengefasst sind. Die dadurch entstandenen Module haben nun weniger Speicher in Anspruch genommen. Die massiven Änderungen erforderten für viele bereits langjährige Projekte enorme Kräfte, auf die neue Java Version zu migrieren. Außerdem wurde mit Java9 die Java Shell, kurz JShell eingeführt. Ein Kommandozeilenwerkzeug, in dem Javafunktionen als Script ausgeführt werden können.

// module-info.java
module com.example.myapp {
  requires java.base;
  exports com.example.myapp;
}

// module-info.java
module com.example.myapp {
  requires java.base;
  exports com.example.myapp;
}

Weitere erhebliche Veränderungen brachte das Release Java10 SE, welches nur wenige Monate nach Java9 in 2018 veröffentlicht wurde und weitere Migrationsaufwände nach sich zog. Hier wurde das Local-Variable-Type Interface mit dem zugehörigen Schlüsselwort var eingeführt. Zudem startet mit dem Release 10 auch das Time-Based Versioning für die Sprache Java. Im Zyklus von 6 Monaten kommt eine neue Major-Version jeweils im März und September. Alle 3 Jahre wird eine LTS-Version veröffentlicht.

// the var KeyWord
public static void main(String[] args) {
  var message = "Hello World, Java10!";
  System.out.println(message);
}

// the var KeyWord
public static void main(String[] args) {
  var message = "Hello World, Java10!";
  System.out.println(message);
}

Bereits im Herbst 2018 wurde die erste Langzeitversion für Java veröffentlicht. Das Release Java11 besitzt den Zusatz LTS und erhält für 3 Jahre Updates. Aufgrund der kurzen Releaszyklen enthält diese Version nur wenige API Änderungen. Vor allem die Klasse String bekam viele neue Methoden spendiert, die den Umgang mit Zeichenketten vereinfachen sollen.

// String FUnctions
String text = new String(" Helle Java 11 LTS world! ");
text.strip();
text.isBlank();
text.lines().count();

// String FUnctions
String text = new String(" Helle Java 11 LTS world! ");
text.strip();
text.isBlank();
text.lines().count();

Die wichtigste Änderung der im Frühjahr 2019 erschienenen Java12 SE Version, ist neben einigen API Erweiterungen die Möglichkeit, in switch Anweisungen Expressions zu nutzen.

// switch expressions
Var day = 1;
String weekday = switch(day) {
    default -> "";
    case 1 -> "Monday";
    case 2 -> "Tuesday";
    ...  
}

// switch expressions
Var day = 1;
String weekday = switch(day) {
    default -> "";
    case 1 -> "Monday";
    case 2 -> "Tuesday";
    ...  
}

Java13 SE erschien planmäßig im Herbst 2019 und verbesserte die Expressions in switch Anweisungen. Zudem wurden Textblöcke eingeführt, die ressourcenfressende String‑Konkatenationen überflüssig machen.

// textblock
String text = """
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim 
ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut 
aliquip ex ea commodo consequat. Duis aute irure dolor in 
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla 
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in 
culpa qui officia deserunt mollit anim id est laborum.
""";

// textblock
String text = """
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim 
ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut 
aliquip ex ea commodo consequat. Duis aute irure dolor in 
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla 
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in 
culpa qui officia deserunt mollit anim id est laborum.
""";

Mit dem Release für Java14 SE im März 2020 wurden Records eingeführt. Diese Datenstrukturen sollen den Code kompakter und lesbarer machen, da Getter und Setter nicht mehr explizit definiert werden müssen.

// records
public record Person (String name, String address) {}

// records
public record Person (String name, String address) {}

Das im Herbst 2020 erschienene Release Java15 SE standardisierte die Textblöcke und führte sealed Klassen ein. Sealed bedeutet so viel wie versiegelt und unterbindet die Möglichkeit, dass eine Klasse vererbt werden kann.

// inheritance protection
public sealed class Shape permits Circle {
    // Class body
}

public final class Circle extends Shape {
    // Class body
}

// inheritance protection
public sealed class Shape permits Circle {
    // Class body
}

public final class Circle extends Shape {
    // Class body
}

2021 standardisierte das Release für Java16 SE verschiedene Funktionen, unter anderem Sealed Classes, Pattern Matching für instanceof und Records.

// Pattern Matching instanceof with auto cast
if (obj instanceof String s) {
    System.out.println(s);
}

// Pattern Matching instanceof with auto cast
if (obj instanceof String s) {
    System.out.println(s);
}

Java17 SE LTS, erschien wieder planmäßig im Herbst 2021 und löste nach drei Jahren Java11 SE LTS ab. In dieser Version wurden die Java Applet API und der Security Manager als deprecated markiert.

Die Version Java18 SE setzte die UTF-8-Codepage als Standard für die JVM. Außerdem wurde die Vector API mit dem Status „experimental“ eingeführt.

// Java Vector API
import jdk.incubator.vector.*;
import java.util.Random;

public class VectorExample {
    // Use preferred vector species for optimal CPU performance
    static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;

    // Vectorized implementation using the Vector API
    static void sqrtsumVector(float[] a, float[] b, float[] c) {
        int i = 0;
        int upperBound = SPECIES.loopBound(a.length); // Efficient loop bound

        // Process data in chunks matching the vector length
        for (; i < upperBound; i += SPECIES.length()) {
            var va = FloatVector.fromArray(SPECIES, a, i);
            var vb = FloatVector.fromArray(SPECIES, b, i);
            var vc = va.mul(va)           // a[i]²
                      .add(vb.mul(vb))    // + b[i]²
                      .neg();             // - (a[i]² + b[i]²)
            vc.intoArray(c, i);           // Store result
        }

        // Handle remaining elements (tail case) with scalar loop
        for (; i < a.length; ++i) {
            c[i] = -(a[i] * a[i] + b[i] * b[i]);
        }
    }
}

// Java Vector API
import jdk.incubator.vector.*;
import java.util.Random;

public class VectorExample {
    // Use preferred vector species for optimal CPU performance
    static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_PREFERRED;

    // Vectorized implementation using the Vector API
    static void sqrtsumVector(float[] a, float[] b, float[] c) {
        int i = 0;
        int upperBound = SPECIES.loopBound(a.length); // Efficient loop bound

        // Process data in chunks matching the vector length
        for (; i < upperBound; i += SPECIES.length()) {
            var va = FloatVector.fromArray(SPECIES, a, i);
            var vb = FloatVector.fromArray(SPECIES, b, i);
            var vc = va.mul(va)           // a[i]²
                      .add(vb.mul(vb))    // + b[i]²
                      .neg();             // - (a[i]² + b[i]²)
            vc.intoArray(c, i);           // Store result
        }

        // Handle remaining elements (tail case) with scalar loop
        for (; i < a.length; ++i) {
            c[i] = -(a[i] * a[i] + b[i] * b[i]);
        }
    }
}

Das Ende 2022 erschienene Release Java19 SE brachte neben einigen Optimierungen und integrierte das Projekt Loom um virtuelle Threads zu ermöglichen. Auch die Foreign Function & Memory API fand ihren Einzug in die JVM.

// Natice C Memory allocation & Slicing in Java 
Arena arena = Arena.ofAuto();
MemorySegment memorySegment = arena.allocate(12);

MemorySegment segment1 = memorySegment.asSlice(0, 4);
MemorySegment segment2 = memorySegment.asSlice(4, 4);
MemorySegment segment3 = memorySegment.asSlice(8, 4);

VarHandle intHandle = ValueLayout.JAVA_INT.varHandle();

intHandle.set(segment1, 0, Integer.MIN_VALUE);
intHandle.set(segment2, 0, 0);
intHandle.set(segment3, 0, Integer.MAX_VALUE);

// Natice C Memory allocation & Slicing in Java 
Arena arena = Arena.ofAuto();
MemorySegment memorySegment = arena.allocate(12);

MemorySegment segment1 = memorySegment.asSlice(0, 4);
MemorySegment segment2 = memorySegment.asSlice(4, 4);
MemorySegment segment3 = memorySegment.asSlice(8, 4);

VarHandle intHandle = ValueLayout.JAVA_INT.varHandle();

intHandle.set(segment1, 0, Integer.MIN_VALUE);
intHandle.set(segment2, 0, 0);
intHandle.set(segment3, 0, Integer.MAX_VALUE);

Java20 SE, das wie gewohnt im Frühjahr erschien, brachte 2023 keine neuen Funktionen, sondern konzentrierte sich darauf, dass bereits eingeführte Features stabilisiert wurden.

Im Herbst 2023 erschien mit Java21 SE LTS wieder eine Long Term Support Version. In diesem Release wurden Virtual Thread finalisiert.

public class VirtualThreadsExample {
  public static void main(String[] args) throws
InterruptedException {
    var executor =
      Executors.newVirtualThreadPerTaskExecutor();
    executor.submit( () ->
      System.out.println("Running in virtual thread"));
    executor.submit( () ->
      System.out.println("Running another virtual thread"));
    Thread.sleep(1000);
    complete
  }
}

public class VirtualThreadsExample {
  public static void main(String[] args) throws
InterruptedException {
    var executor =
      Executors.newVirtualThreadPerTaskExecutor();
    executor.submit( () ->
      System.out.println("Running in virtual thread"));
    executor.submit( () ->
      System.out.println("Running another virtual thread"));
    Thread.sleep(1000);
    complete
  }
}

Abonnement

Validieren von Kreditkartennummern für Online Payments

Elmar Dott Sep. 17, 2024

Artikel

Zähl auf mich – Java Enums

Elmar Dott Dez. 15, 2025

Maven Master Class [DE]

Referenzen & Literatur

Elmar Dott Jan. 18, 2026

Performante Hardware unter Linux für lokale KI Anwendungen

Veröffentlicht am 2026-03-09 von Elmar Dott

Antworten

Wer ein wenig mit lokalen LLM herumspielen möchte, findet rasch die Limitationen heraus. Nicht jeder hat einen massiv aufgerüsteten Desktop Rechner mit 2 TB Arbeitsspeicher und eine CPU, auf der man unter Volllast Spiegeleier braten kann. Eher typisch ist ein Laptop mit 32 GB RAM oder wie bei mir, ein Lenovo P14s mit 64 GB RAM. Trotz dieser üppigen Ausstattung scheitert es oft daran, ein etwas umfangreicheres KI Modell zu laden, denn 128 GB RAM sind für viele dieser Modelle eher Standard. Nun kann man bei aktuellen Laptops auch keinen Arbeitsspeicher nachrüsten, weil die Chips direkt auf der Platine verlötet sind. Das gleiche Problem haben wir natürlich auch mit der Grafikkarte. Deswegen habe ich mir beim Laptopkauf angewöhnt, nahezu die Maximalausstattung zu konfigurieren, und hoffe dann, damit 5–8 Jahre lang meine Ruhe zu haben. Gerade die Qualität der Lenovo ThinkPad Serie hat mich bisher bei diesem Vorhaben nicht enttäuscht. Mein aktuelles System ist circa 2 Jahre alt und läuft so weit zuverlässig.

Als Betriebssystem nutze ich seit Jahren Linux und aktuell habe ich Debian 13 am Laufen. Im Vergleich zu Windows sind Linux- und Unix-Distributionen wesentlich ressourcenschonender und nutzen die Leistung nicht für grafische Animationen und komplexe Farbverläufe, sondern ermöglichen eine leistungsstarke Umgebung für die verwendeten Anwendungen. Daher auch mein dringender Rat, für alle, die lokale LLMs probieren möchten: sich einen leistungsstarken Rechner zu besorgen und diesen mit Linux zu betreiben. Aber der Reihe nach. Schauen wir uns zuerst die einzelnen Hardwarekomponenten etwas genauer an.

Beginnen wir mit der CPU. Für LLMs, CAD Anwendungen und auch Computerspiele gilt, dass diese Berechnungen durchführen, die hervorragend parallel verarbeitet werden können. Bei parallel ausgeführten Berechnungen ist die Anzahl der verfügbaren CPU‑Kerne ein wichtiges Kriterium. Je mehr Kerne, umso mehr parallele Berechnungen können ausgeführt werden.

Natürlich müssen die Prozessoren die Daten für die Berechnung schnell anfragen können. Hier kommt der Arbeitsspeicher (RAM) ins Spiel. Je mehr Arbeitsspeicher vorhanden ist, umso effizienter können die Daten zur Berechnung bereitgestellt werden. Bezahlbare Laptops kann ma bereits mit 32 GB RAM finden. Natürlich steigt der Anschaffungspreis mit mehr RAM exponentiell. Sicher gibt es einige hochgezüchtete Gamer-Geräte im Consumerbereich, die ich allerdings wegen der meist kurzen Lebensdauer und dem dazu vergleichsweise hohen Preis eher nicht empfehlen kann.

Der nächste logische Schritt in der Hardwarekette ist die Festplatte. Einfache SSDs beschleunigen den Transfer zum Arbeitsspeicher enorm, aber es gibt noch Steigerungen. NVMe Karten ab 2 GB Speicherkapazität können in der 4. Generation bis zu 7000 MB/s erreichen.

Bei der Grafikkarte haben wir bei Laptops so unsere Probleme. Aufgrund der Größe und der benötigten Leistung , sind die in Laptops verbauten Grafikkarten eher ein Kompromiss, als ein wirkliches Highlight. Dabei wäre eine gute Grafikkarte ideal für parallele Berechnungen, wie sie bei LLMs durchgeführt werden. Als Lösung können wir den Laptop mit einer externen Grafikkarte verbinden. Dank der Bitcoin Miner aus der Krypto Community wurde hier bereits einiges an Erfahrung gesammelt. Damit man allerdings eine externe Grafikkarte an den Laptop anschließen kann, muss man auch einen Anschluss haben, der diese Datenmenge verarbeiten kann. USB 3 ist für unser Vorhaben viel zu langsam und würde den Vorteil der externen Grafikkarte durch die geringe Datenrate massiv ausbremsen.

Die Lösung für unser Problem lautet Thunderbolt. Äußerlich sehen Thunderbolt-Anschlüsse wie USB-C aus, sind aber um einiges schneller. Thunderbolt erkennt man an dem kleinen Blitz (siehe Abbildung 1) auf den Kabeln, beziehungsweise an den Buchsen. Es sind also nicht die Anschlüsse für die Stromversorgung. Um sicherzustellen, ob man auf dem Computer Thunderbolt zur Verfügung hat, kann man dies mit einem kleinen Linux Shell Befehl nachprüfen.

ed@local: $ lspci | grep -i thunderbolt
00:07.0 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI Express Root Port #0
00:07.2 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI Express Root Port #2
00:0d.0 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 USB Controller
00:0d.2 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI #0
00:0d.3 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI #1

ed@local: $ lspci | grep -i thunderbolt
00:07.0 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI Express Root Port #0
00:07.2 PCI bridge: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI Express Root Port #2
00:0d.0 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 USB Controller
00:0d.2 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI #0
00:0d.3 USB controller: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI #1

In meinem Fall zeigt mir die Ausgabe meines Computers, dass zwei Thunderbolt Anschlüsse in der Version 4 vorhanden sind.

Um nun eine externe Grafikkarte anzuschließen, benötigen wir ein Trägersystem, auf das eine PCI Karte gesteckt werden kann. Hier bietet die Firma ANQUORA mit dem ANQ-L33 eGPU Enclosure eine gute Lösung. Das Board kann eine Grafikkarte mit bis zu drei Slots aufnehmen. Der Kostenpunkt liegt zwischen 130 und 200 Euro. Hinzu kommt noch ein Standard ATX Netzteil, das für die Stromversorgung benötigt wird. Die Leistung des Netzteils ergibt sich aus dem Stromverbrauch der Grafikkarte. Das Netzteil sollte man auch nicht zu günstig einkaufen, da die Geräuschentwicklung den ein oder anderen stören könnte. Die offene Bauform des Boards gibt genügend Freiheiten bei der Auswahl der Grafikkarte.

Die Auswahl der Grafikkarte wiederum ist ein ganz eigenes Thema. Da ich als Betriebssystem Linux verwende, benötige ich auch eine Grafikkarte, die von Linux unterstützt wird. Für die Beschleunigung von LLMs benötigt man eine Grafikkarte mit möglichst vielen GPU Kernen und entsprechend hohem internen Arbeitspeicher. Damit sich die Anschaffung auch lohnt und man wirklich einen Leistungsschub bemerkt, sollte die Karte mit mindestens 8 GB RAM ausgestattet sein. Mehr darf natürlich immer sein, nur steigt dann auch der Preis der Karte schnell exorbitant an. Hier lohnt sich durchaus auch ein Blick in den Gebrauchtmarkt.

Rechnet man alle Kosten zusammen, beläuft sich die Investition für eine externe GPU auf mindestens 500 Euro. Natürlich ist hier nur eine preiswerte Grafikkarte mit berücksichtigt. Hochwertige Grafikkarten können allein bereits problemlos die 500 Euro Priesbremse überschreiten. Wer im Bereich Grafikkarten gern seine Expertise beisteuern möchte, ist gern eingeladen, einen Artikel beizusteuern.

Damit man nun seine Einkaufstour nicht auf Blaue beginnt und dann über das Ergebnis enttäuscht ist, ist es sehr ratsam, sich vorher zu überlegen, was man mit der lokalen LLM machen möchte. Zur Unterstützung bei der Programmierung benötigt man weniger Rechenpower als für die Generierung von Grafiken und Audio. Wer LLMs professionell nutzt, kann durch die Anschaffung einer sehr hochpreisigen Grafikkarte durch selbst gehostete Modelle im Vergleich zu den Kosten für beispielsweise Claud Code erheblich einsparen. Die Spezifikation von LLMs richtet sich nach den verfügbaren Parametern. Hier gilt: Je mehr Parameter, umso genauer ist die Antwort und umso mehr Rechenleistung wird benötigt. Bei der Genauigkeit unterscheidet man zudem:

FP32 (Single-Precision Floating Point): Standardgenauigkeit, benötigt den meisten Speicherplatz. (z.B. 32 Bit pro Parameter)
FP16 (Half-Precision Floating Point): Halbe Genauigkeit, halbiert den Speicherbedarf im Vergleich zu FP32, kann aber die Genauigkeit leicht reduzieren. (z.B. 16 Bit pro Parameter / 4Byte)
BF16 (Brain Floating Point): Eine weitere Option für halbgenaue Berechnungen, oft bevorzugt in Deep Learning aufgrund seiner besseren Leistung bei bestimmten Operationen. (z.B. 16 Bit pro Parameter / 2 Byte)
INT8/INT4 (Integer Quantization): Noch geringere Präzision, reduziert den Speicherbedarf drastisch und beschleunigt die Inferenz, kann aber zu einem größeren Genauigkeitsverlust führen. (z.B. 8 Bit pro Parameter / 1 Byte).

Weitere Einflüsse auf die Hardwareanforderungen für LLM haben die Punkte:

Batch Size: Die Anzahl der Eingabeanfragen, die gleichzeitig verarbeitet werden.
Kontextlänge (Context Length): Die maximale Länge des Textes, den das Modell bei einer Anfrage berücksichtigen kann. Längere Kontextlängen benötigen mehr Speicherplatz, da der gesamte Kontext im Speicher gehalten werden muss.
Modellarchitektur: Verschiedene Architekturen haben unterschiedliche Speicheranforderungen.

Um abzuschätzen, wie hoch der Speicherverbrauch eines Modells wird, kann man folgende Berechnung heranziehen: Parameter * Genauigkeit = Speicherverbrauch für das Modell.

7.000.000.000 Parameter * 2 Bytes/Parameter (BF16) = 14.000.000.000 Bytes = 14 GB

Bei den Hardwareempfehlungen sollte man auf die Dokumentation des Modells Rücksicht nehmen. Diese geben meist nur die minimalen beziehungsweise durchschnittlichen Anforderungen an. Es gibt allerdings allgemeine Richtwerte, an dene man sich orientieren kann.

Kleine Modelle (bis 7 Milliarden Parameter): Eine GPU mit mindestens 8 GB VRAM sollte ausreichen, besonders wenn Sie Quantisierung verwenden.
Mittlere Modelle (7-30 Milliarden Parameter): Eine GPU mit 16 GB bis 24 GB VRAM ist empfehlenswert.
Große Modelle (über 30 Milliarden Parameter): Mehrere GPUs mit jeweils mindestens 24 GB VRAM oder eine GPU mit sehr viel VRAM (z.B. 48 GB, 80 GB) sind erforderlich.
CPU-only: Für kleine Modelle und einfache Experimente kann die CPU ausreichend sein, aber die Inferenz wird deutlich langsamer sein als auf einer GPU. Hier ist ein großer RAM-Bedarf wichtig (mehrere GB / 32+).

Wir sehen, dass die Nutzung lokal laufender LLMs durchaus realistisch sein kann, wenn man die entscheidende Hardware vorrätig hat. Es muss nicht immer gleich ein Supercomputer sein, dennoch sind die meisten Lösungen bei den üblichen Elektronikkaufhausketten von der Stange und nicht wirklich geeignet. Somit habe ich mit diesem Artikel die Grundlagen für eigene Experimente gelegt.

Artikel

Performante Hardware unter Linux für lokale KI Anwendungen

Elmar Dott März 9, 2026

Tutorials

Dokumente mit AnythingLLM und Ollama verarbeiten

Peter Kapherr Sep. 8, 2025

Tutorials

Künstliche Intelligenz GPD4all unter Linux installieren

Peter Kapherr Aug. 25, 2025

Artikel

Der digitale Werkzeugkasten

Elmar Dott Juni 17, 2025

Artikel

Schreckgespenst künstliche Intelligenz

Elmar Dott Juli 27, 2023

Artikel

Vibe Coding – eine neue Plage des Internets?

Elmar Dott Jan. 26, 2026

Risiko Cloud & Serverless

Veröffentlicht am 2026-03-02 von Elmar Dott

Antworten

Die Wolke ist eine der innovativsten Entwicklungen, seit der Jahrtausendwende und ermöglicht uns eine flächendeckende Nutzung neuronaler Netze, die wir im Volksmund als Large Language Models (LLM) bezeichnen. Dieser Technologiesprung ist nur noch durch Quantencomputing zu übertreffen. Aber genug der Buzzwords für die SEO-Optimierung, stattdessen schauen wir einmal hinter die Kulissen. Beginnen wir erst einmal damit, was Cloud überhaupt ist, und legen dafür die ganzen Marketingbegriffe einmal beiseite.

Am besten kann man sich die Wolke als gigantischen Supercomputer vorstellen, der aus vielen kleinen Computern bausteinartig zusammengesetzt wurde. Dadurch hat man theoretisch beliebig viel CPU‑Leistung, Arbeitsspeicher und Festplattenspeicher zusammenschalten. Auf diesem Supercomputer, der in einem Rechenzentrum läuft, können nun wiederum virtuelle Maschinen bereitgestellt werden, die einen echten Computer mit einer freidefinierbaren Hardware simulieren. Auf diese Weise können die physischen Hardwareresourcen optimal auf die bereitgestellten virtuellen Maschinen aufgeteilt werden.

Bei Cloud unterscheiden wir grob drei unterschiedliche Betriebslevel: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service. Die nachfolgende Abbildung gibt eine Vorstellung davon, wie sich diese Ebenen aufteilen.

Vereinfacht kann man sagen, dass bei IaaS durch den Anbieter lediglich die Hardwarespezifikation bereitgestellt wird. Also CPU, RAM, Festplatte und Internetanschluss. Über die Administrationssoftware z. B. Kubernetes kann man nun eigene virtuelle Maschinen/Container erstellen und die entsprechenden Betriebssysteme und Services selbst installieren. Die gesamte Verantwortung der Sicherheit und des Netzwerkrouting liegt hier beim Kunden selbst. PaaS hingegen stellt bereits eine rudimentär eingerichtete virtuelle Maschine inklusive des ausgewählten Betriebssystems bereit. Was man schlussendlich auf diesem System oberhalb der Betriebssystemebene installiert, ist einem selbst überlassen. Aber auch hier ist das Thema Sicherheit zu großen Teilen in den Händen des Kunden. Bei den meisten Hostinganbietern sind typische PaaS-Produkte sogenannte virtuelle Server. Die geringste Freiheit haben Nutzer bei SaaS. Hier hat man meist nur die Berechtigung, durch ein Benutzerkonto eine Software zu nutzen. Sehr typische SaaS Produkte sind E-Mail Konten, aber auch sogenannte Managed Server. Managed Server findet man größtenteils zum Bereitstellen von eigenen Internetseiten. Hier wird die Version der Programmiersprache und der Datenbank durch den Betreiber des Servers vorgegeben.

Gerade die Managed Server haben eine lange Tradition. Sie kamen zur Jahrtausendwende auf um eine sofort benutzbare Umgebung für dynamische PHP Webseiten mit MySQL Datenbankanbindung bereitzustellen. Ähnlich verhält es sich mit den neu in Mode gekommenen Serverless Produkten. Je nach Erfahrungslevel kann man nun bei den Großen Anbietern AWS, Google und Microsoft Azure entsprechende Produkte kaufen.

Der Gedanke ist also, keine eigenen Server mehr für die Dienste zu betreiben und somit den kompletten Aufwand für Hardware, Betrieb und Sicherheit an die Cloudbetreiber auszulagern. Grundsätzlich ist das auch kein schlechter Gedanke, besonders wenn es sich um kleine Unternehmen oder Startups handelt, die einerseits nicht viele finanzielle Mittel zur Verfügung haben oder ihnen einfach das administrative Know-how für Netzwerk, Linux und Serversicherheit fehlt.

Natürlich kommt man mit vollständig extern verwalteten Serverless Angeboten auch schnell an Grenzen. Gerade wenn man die eigene entwickelte Individualsoftware Serverless mit möglichst wenig Aufwand in der Cloud bereitstellen möchte, kommt man an so manchem Stolperstein vorbei. Ein Problem ist oft die flexible Erweiterbarkeit bei wechselnden Anforderungen. Sicher kann man hier aus dem Portfolio der verschiedenen Anbieter Produkte zukaufen und diese wie ein Bausteinset beliebig kombinieren, aber die anfallenden Kosten können sich dabei schnell überschlagen.

Grundsätzlich ist an einem pay per use Modell (also bezahle, was du verwendest) nichts auszusetzen. Für Personen und Organisationen mit kleinem Geldbeutel ist das auf den ersten Blick keine schlechte Lösung. Aber auch hier sind es die kleinen Details, die schnell zu ernsthaften Problemen anwachsen können.

Wenn man sich für einen beliebigen Cloudanbieter entscheidet, ist man gut beraten, möglichst auf dessen proprietäre Management- und Automatisierungsprodukte zu verzichten und stattdessen nach Möglichkeit auf etablierte allgemeine Produkte auszuweichen. Bindet man sich mit allen Konsequenzen an einen Anbieter, so wird es nur unter sehr großem Aufwand möglich sein zu einem anderen Anbieter z wechseln. Änderungen der AGB oder kontinuierlich steigende Kosten sind mögliche Gründe für einen erzwungenen Wechsel. Daher prüfet, wer sich ewig bindet.

Aber auch unbedachte Ressourcennutzung in Cloudsystemen, z. B. durch falsche Konfigurationen oder ungünstige Deploy-Strategien, kann zu einer Kostenexplosion führen. Hier ist man gut beraten, wenn es die Möglichkeit gibt, Limits einzustellen, diese zu aktivieren. sodass man ab einem bestimmten Betrag darauf hingewiesen wird, dass nur noch ein ‚bestimmtes‘ Kontingent zur Verfügung steht. Gerade bei hochverfügbaren Diensten, die plötzlich sprunghaft enorm viele neue Anwender bekommen, können schnell durch solche Limits vom Netz abgestöpselt werden. Daher ist man immer gut beraten, möglichst zwei Lösungen im Bereich Cloud zu nutzen, eine für Entwicklung und eine separate für das Produktivsystem, um das Offlinerisiko zu minimieren.

Ähnlich wie beim Trading an der Börse, kann man auch bei Cloud Services wie AWS Schranken definieren. Die Stops an der Börse sollen verhindern, dass man eine Aktie nicht zu billig verkauft oder zu teuer einkauft. Durch das Pay per Use Modell ist es in der Cloud nicht viel anders. Hier muss man beim Anbieter geeignete Grenzen setzen, die verhindern, dass die Rechnung den Verfügungsrahmen des Kontos sprengt. Auch in der Cloud sind die Grenzen dynamisch. Das heißt, die Rahmenbedingungen verändern sich stetig, was bedeutet, dass die notwendigen Grenzen regelmäßig den Erfordernissen angepasst werden müssen. Um Engpässe rechtzeitig zu erkennen, sollte ein aussagekräftiges Monitoring etabliert sein. Die Mindestanforderung für ein AWS Node wird durch dessen Requests bestimmt. Die obere Schranke der verfügbaren Ressourcen wird durch das Limit bestimmt. Mit Werkzeugen wie Kubecost von IBM lässt sich die Kostenüberwachung in K8 Clustern weitgehend automatisieren.

Für Cloudentwicklungsumgebungen sollte man den eigenen Entwickler‑ und DevOps-Team auch ein wenig auf die Finger schauen. Wenn für eine einfache JavaScript Angular App ein NPM Docker Container von über 2 GB jedes Mal on the fly erstellt wird, sollte man diese Strategie durchaus hinterfragen. Auch wenn die Cloud scheinbar unendlich viele Ressourcen dynamisch allokieren kann, heißt das nicht, dass dies dann auch kostenfrei passiert.

Natürlich ist auch das Thema Sicherheit ein wichtiger Faktor. Natürlich kann man dem Cloudbetreiber so weit vertrauen, wenn er sagt, dass alles verschlüsselt ist und ein Zugriff auf Kundendaten und Geschäftsgeheimnisse nicht möglich ist. Sicher kann man davon ausgehen, dass die Informationen, die bei den meisten Unternehmungen abzugreifen sind, selten einen spannenden oder gar aufregenden Inhalt haben, der für große Cloudbetreiber von Interesse sein könnte. Wer dennoch auf Nummer sicher gehen möchte, sollte das Thema Serverless vollständig abschreiben und eher mit dem Gedanken spielen, seine eigene Cloud zu betreiben. Das geht dank moderner und freier Software mittlerweile leichter als gedacht.

Aus persönlicher Erfahrung habe ich gelernt, dass bei der Komplexität moderner Webanwendungen ein effizientes Monitoring mit Grafana und Prometheus oder anderen Lösungen wie dem ELK Stack oder Slunk unverzichtbar ist. Doch gerade mit der Datenerhebung und der richtigen Auswertung haben so manche DevOps Teams so ihre Schwierigkeiten. Hier sind vor allem die IT-Entscheider gefragt, sich einen technischen Überblick zu verschaffen, um nicht auf die wohlklingenden Marketingfallen bei Cloud und Serverless hereinzufallen.

Artikel

Vibe Coding – eine neue Plage des Internets?

Elmar Dott Jan. 26, 2026

Publikationen

Soviel die Schutern tragen können

Elmar Dott Feb. 25, 2026

Artikel

Beyond Code: Warum Soft Skills für Entwickler in der KI-Ära unersetzlich werden

Elmar Dott Juli 15, 2025

Die Zukunft des Build Managements

Veröffentlicht am 2026-02-16 von Elmar Dott

Antworten

Nicht nur sogenannte Hochsprachen, die den Quelltext in Maschinencode überführen müssen, damit dieser ausführbar ist, benötigen sogenannte Build Werkzeuge. Auch für moderne Scriptsprachen wie Python, Ruby oder PHP sind diese Werkzeuge mittlerweile verfügbar, da deren Verantwortungsbereich stetig wächst. Blickt man in die Anfänge dieser Werkzeugkategorie, stößt man unweigerlich auf make, der erste offizielle Vertreter von dem, was man heute als Build Werkzeug bezeichnet. Die Hauptaufgabe von make war das Erstellen von Maschinencode und das Paketieren der Dateien zu einer Bibliothek oder ausführbaren Datei. Man kann also sagen, das Buildwerkzeuge unter die Kategorie der Automatisierungswerkzeuge fallen. Da liegt es nahe, viele andere immer wiederkehrende Aufgaben, die im Entwickleralltag anfallen, ebenfalls zu übernehmen. So war eine der wichtigsten Innovationen, die für den Erfolg von Maven verantwortlich war, die Verwaltung von Abhängigkeiten zu anderen Programmbibliotheken.

Eine andere Klasse an Automatisierungswerkzeugen, die fast verschwunden ist, sind die sogenannten Installer. Produkte wie Inno SetUp oder Wise Installer wurden verwendet, um den Installationsprozess auf Desktopanwendungen zu automatisieren. Diese Installationsroutinen sind eine spezielle Form des Deployments. Der Deploymentprozess wiederum hängt von verschiedenen Faktoren ab. Zuallererst ist natürlich das verwendete Betriebssystem ein wichtiges Kriterium. Aber auch die Art der Anwendung hat einen erheblichen Einfluss. Handelt es sich etwa um eine Webanwendung, die eine definierte Laufzeitumgebung (Server) benötigt? Wir können hier bereits sehen, dass viele der gestellten Fragen mittlerweile im Themenbereich DevOps angesiedelt sind.

Als Entwickler genügt es nun nicht mehr, nur zu wissen, wie man Programmcode schreibt und Funktionen implementiert. Wer eine Webanwendung bauen möchte, muss zuerst den entsprechenden Server zum Laufen bekommen, auf dem die Applikation ausgeführt wird. Glücklicherweise gibt es mittlerweile viele Lösungen, die das Bereitstellen einer lauffähigen Runtime erheblich vereinfachen. Aber gerade für Anfänger ist es nicht immer so leicht, das ganze Thema zu überblicken. Ich erinnere mich noch an Fragen in einschlägigen Foren, dass man jetzt Java Enterprise heruntergeladen hat, aber nur der Applikationsserver enthalten ist.

Java Enterprise in briefly detail

Wo Anfang der 2000er noch Automatisierungslösungen fehlten, ist heute eher die Herausforderung, das richtige Werkzeug zu wählen. Auch hier gibt es eine Analogie aus dem Java Universum. Als das Build-Werkzeug Gradle auf dem Markt erschien, stiegen viele Projekte von Maven auf Gradle um. Das Argument war, eine höhere Flexibilität zu erhalten. Oft benötigte man die Möglichkeit, orchestrierte Builds zu definieren. Also die Reihenfolge, in der Teilprojekte erstellt werden. Anstatt sich einzugestehen, dass es sich bei dieser Anforderung um einen Architekturmangel handelt und anstatt diesen zu beheben, wurden komplizierte und kaum überschaubare Build Logiken in Gradle gebaut. Das führte wiederum dazu, dass Anpassungen nur schwer umzusetzen waren und viele Projekte zurück nach Maven migriert wurden.

Aus den DevOps Automatisierungen haben sich mittlerweile sogenannte Pipelines etabliert. Pipelines können auch als Prozess verstanden werden und diese Prozesse lassen sich wiederum standardisieren. Das beste Beispiel für einen standardisierten Prozess, ist der in Maven definierte Build Lifecycle, der auch als Default-Lifecycle bezeichnet wird. In diesem Prozess werden 23 sequenzielle Schritte definiert, die im Groben zusammengefasst folgende Aufgaben abarbeiten:

Auflösen und Bereitstellen von Abhängigkeiten
Kompilieren der Quelltexte
Kompilieren und Ausführen von Komponententests
Paketieren der Dateien zu einer Bibliothek oder Anwendung
Lokales Bereitstellen des Artefaktes zur Verwendung in anderen lokalen Entwicklungsprojekten
Ausführen von Integrationstests
Deployen der Artefakte auf einem Remote Repository Server.

Dieser Prozess hat sich über Jahre in unzähligen Javaprojekten bestens bewährt. Führt man diesen Prozess allerdings auf einem CI Server wie Jenkins als Pipeline aus, bekommt man wenig zu sehen. Die einzelnen Schritte des Build Lifecycles bauen aufeinander auf und können nicht einzeln angesteuert werden. Es ist nur möglich, den Lifecycle vorzeitig zu verlassen. Man kann also nach dem Paketieren die nachfolgenden Schritte des lokalen Deployments und das Ausführen der Integrationstests auslassen.

Eine Schwäche des hier beschriebenen Build Prozesses kommt bei der Erstellung von Webapplikationen zutage. Web Frontends enthalten meist CSS und JavaScript Code, der ebenfalls automatisiert optimiert wird. Um in SCSS definierte Variablen in korrektes CSS zu überführen, muss ein SASS Präprozessor verwendet werden. Zudem ist es sehr nützlich, CSS Dateien und JavaScript Dateien möglichst stark zu komprimieren. Dieser Vorgang der Obfuskation optimiert die Ladezeiten von Webanwendungen. Aber auch für CSS und JavaScript gibt es bereits unzählige Bibliotheken, die mit dem Werkzeug NPM verwaltet werden können. NPM wiederum stellt sogenannte Entwicklungsbibliotheken wie Grunt bereit, mit denen wiederum CSS-Prozessierung und -Optimierung möglich sind.

Wir sehen, wie komplex der Buildprozess von modernen Anwendungen werden kann. Das Kompilieren ist nur ein kleiner Teil davon. Ein wichtiges Feature moderner Build Werkzeuge ist das Optimieren des Build Vorgangs. Eine mittlerweile etablierte Lösung dafür ist das Erstellen von inkrementellen Builds. Dies ist eine Variante des Cachings, bei der nur geänderte Dateien kompiliert beziehungsweise prozessiert werden.

Was ist aber bei einem Release zu tun? Ein Prozess, der wiederum nur dann benötigt wird, wenn eine Implementierungsphase beendet ist, um das Artefakt für die Verteilung bereitzustellen. Nun könnte man alle Schritte, die ein Release enthalten, ebenfalls in den Build einbauen, was wiederum zu längeren Buildzeiten führt. Längere lokale Buildzeiten stören wiederum den Arbeitsfluss des Entwicklers, weswegen es sinnvoller ist, hierfür einen eigenen Prozess zu definieren.

Bei einem Release sollte eine wichtige Bedingung sein, dass alle verwendeten Bibliotheken ebenfalls als finale Releaseversion vorliegen. Ist dies nicht der Fall, kann nicht sichergestellt werden, dass erneut erstellte Releases dieser Version identisch sind. Aber auch alle Testfälle müssen korrekt durchlaufen werden und ein Fehlschlagen bricht den Vorgang ab. Zudem sollte ein entsprechendes Tag im Source-Control-Repository auf die Revision gesetzt werden. Die fertigen Artefakte sind zu signieren und auch eine API Dokumentation ist zu erstellen. Natürlich sind die hier beschriebenen Regeln nur eine kleine Auswahl und einige der beschriebenen Aufgaben können sogar parallelisiert werden. Nutzt man zudem noch ein raffiniertes Caching, kann das Erstellen eines Releases auch für umfangreiche Monolithen in kurzer Zeit vonstattengehen.

Für Maven wurde beispielsweise kein kompletter Releaseprozess, ähnlich dem Buildprozess, definiert. Hier wurde durch die Community ein spezielles Plug-in entwickelt, mit dem einfache Aufgaben, die während eines Releases anstehen, semiautomatisiert werden können.

Wenn wir das Thema Dokumentation und Reporting ein wenig genauer betrachten, finden wir auch hier genügend Möglichkeiten, einen vollständigen Prozess zu beschreiben. So wäre das Erstellen der API Dokumentation nur ein untergeordneter Punkt. Wesentlich spannender an einem standardisierten Reporting sind die verschiedenen Codeinspektionen, die teilweise auch parallel durchlaufen werden können.

Natürlich darf auch das Deployment nicht fehlen. Aufgrund der Vielfalt, der möglichen Zielumgebungen ist an dieser Stelle eine andere Strategie angebracht. Ein denkbarer Weg wäre eine breite Unterstützung von Konfigurationswerkzeugen wie Ansible, Chef und Puppet. Aber auch Virtualisierungstechnologien wie Docker und LXC Container gehören in Zeiten der Cloud zum Standard. Hauptaufgabe des Deployments wäre dann vor allem die Provisionierung der Zielumgebung und das Einspielen der Artefakte aus einem Repository Server. Mit einer Fülle verschiedener Deployment Templates würde dies eine erhebliche Vereinfachung darstellen.

Wenn wir die hier getroffenen Annahmen konsequent weiterdenken, kommen wir zu dem Schluss, dass es unterschiedliche Projekttypen geben kann. Das wären klassische Entwicklungsprojekte, aus denen dann Artefakte für Bibliotheken und Anwendungen entstehen, Testprojekte, die wiederum die erstellten Artefakte als Abhängigkeit enthalten, und natürlich Deploymentprojekte zur Bereitstellung der Infrastruktur. Der Bereich des automatisierten Deployments findet sich auch in der Idee Infrastructure as a Code und GitOps wieder,die man an dieser Stelle aufgreifen und weiterentwickeln kann.

Wir sehen, dass bei weitem noch nicht alle Innovationen für sogenannte Build Werkzeuge ausgeschöpft sind. Viele der hier besprochenen Ideen sind bereits existierende Konzepte und erfordern lediglich eine Standardisierung. Durch die formalen Beschreibungen eines Prozesses und die flexible Konfiguration einzelner Komponenten in den Prozessschritten wird eine individuelle Anpassung ermöglicht.

Maven Master Class [DE]

Stichwortverzeichnis & Abkürzungen

Elmar Dott Jan. 18, 2026

Maven Master Class [DE]

Elmar Dott Jan. 18, 2026

Artikel Publikationen

PHP meets Maven

Elmar Dott Mai 9, 2012

Clean Desk – mehr als nur Sicherheit

Veröffentlicht am 2026-02-09 von Elmar Dott

Antworten

Als Kind antwortete ich gern meiner Mutter, dass nur ein Genie das Chaos beherrscht, wenn sie mich anhielt, mein Zimmer aufzuräumen. Eine sehr willkommene Ausrede, mich vor meinen Pflichten zu drücken. Als ich nach dem Schulabschluss eine Lehre im Handwerk begonnen habe, war das Erste, worauf mein Lehrmeister achtete: Ordnung halten. Das Werkzeug hatte nach Benutzung zurück in die Werkzeugtasche gelegt zu werden, angefangene Kartons mit gleichen Arbeitsmaterialien wurden wieder aufgefüllt und natürlich galt es auch, mehrmals am Tag den Dreck aufzukehren. Ich kann gleich vorwegnehmen, dass ich diese Dinge nie als Schikane empfunden habe, auch wenn sie uns lästig erschienen sind. Denn rasch haben wir den Nutzen der Devise „Sauberkeit halten“ erfahren.

Werkzeuge, die immer zurück an ihren Platz gebracht werden, verschaffen uns zügig einen Überblick, ob etwas fehlt. Also kann man sich dann auf die Suche machen und die Wahrscheinlichkeit, dass Dinge gestohlen werden, reduziert sich drastisch. Auch bei den Arbeitsmaterialien behält man einen guten Überblick über Dinge, die verbraucht wurden und neu beschafft werden müssen. Fünf leere Kartons mit nur ein oder zwei Teilen darin verbrauchen nicht bloß Platz, sondern führen auch zu falschen Einschätzungen der verfügbaren Ressourcen. Zu guter Letzt gilt natürlich auch, dass man sich im Dreck weniger wohlfühlt und mit Sauberkeit dem Auftraggeber demonstriert, dass man fokussiert und planvoll vorgeht.

Durch diese Prägung in jungen Jahren, habe ich, als vor einigen Jahren das Thema Clean Desk als Sicherheitskonzept in Unternehmen eingeführt wurde, nicht gleich verstanden, was man von mir wollte. Schließlich ist mir das Prinzip Clean Desk bereits in Fleisch und Blut übergegangen, lange bevor ich mein Studium der Informatik abgeschlossen hatte. Aber der Reihe nach. Schauen wir uns erst einmal an, was Clean Desk eigentlich ist und wie man es umsetzt.

Wer sich tiefgehend mit dem Thema Security beschäftigt, lernt als Erstes, dass die meisten erfolgreichen Angriffe nicht über komplizierte technische Manöver durchgeführt werden. Sie verlaufen viel profaner und kommen üblicherweise nicht von außen, sondern von innen. Treu nach dem Motto: Gelegenheit macht Diebe. Kombiniert man diese Tatsache noch mit den Erkenntnissen des Social Engineerings, das vor allem durch den Hacker Kevin Mitnick geprägt wurde, ergibt sich ein neues Bild. Es müssen nicht immer gleich die eigenen Mitarbeiter unter Generalverdacht gestellt werden. In einem Gebäude gibt es externe Putzkräfte, Sicherheitspersonal oder Handwerker, die meist problemlos Zugang zu sensiblen Räumlichkeiten bekommen. Daher gilt stets die Devise: Vertrauen ist gut, Kontrolle ist besser, weswegen man eine Clean Desk Policy einführt.

Die erste Regel lautet: Wer über einen längeren Zeitraum den Arbeitsplatz verlässt, schaltet seine Geräte aus. Das gilt besonders für den Feierabend. Ansonsten ist zumindest der Desktop zu sperren. Das Konzept dahinter ist recht einfach. Von ausgeschalteten Geräten können keine Sicherheitslücken ausgenutzt werden, um sich von außen in das Firmennetzwerk zu hacken. Zudem verringert es den Stromverbrauch und verhindert Brände durch Kurzschlüsse. Damit die Geräte nicht physisch entwendet werden können, sind diese mit speziellen Schlössern am Schreibtisch fixiert. Ich habe es schon selbst erlebt, dass während der Mittagspause Geräte gestohlen wurden.

Da ich selbst sehr viel in Hotels übernachtet habe, ist die Festplatte meines Computers prinzipiell verschlüsselt. Das gilt auch für alle externen Datenträger wie USB Sticks oder externe SSDs. Wird das Gerät gestohlen, kann zumindest niemand auf die darauf befindlichen Daten zugreifen.

Es ist natürlich selbstverständlich, dass eine sichere Verschlüsselung nur mit einem starken Passwort möglich ist. Viele Unternehmen, haben spezielle Regeln, die die Passwörter der Mitarbeiter erfüllen müssen. Zudem ist es üblich, dass alle 30 bis 90 Tage ein neues Passwort vergeben werden muss, das von den letzten drei verwendeten Passwörtern abweichen muss.

Passwörter, aber sicher?

Oft wird auch darauf hingewiesen, dass die Passwörter nicht auf einem Post-it stehen, der auf dem Monitor klebt. Das habe ich selbst so nie erlebt. Viel typischer ist, dass Passwörter unter der Tastatur oder dem Mauspad notiert werden.

Ein anderer Aspekt sind Aufzeichnungen, die auf Schreibtischen, Wandkalendern und Whiteboards hinterlassen werden. Auch wenn die Information noch so unbedeutend scheint, kann sie durchaus sehr wertvoll sein. Da es recht schwer ist, zu entscheiden, was wirklich schützenswert ist und was nicht, gilt die allgemeine Regel: Alle Aufzeichnungen sind zum Feierabend für Außenstehende unzugänglich zu verstauen. Das klappt natürlich nur dann, wenn auch verschließbarer Stauraum vorhanden ist. In sensiblen Bereichen wie Banken und Versicherungen geht man sogar so weit, dass auf Wandkalendern keine Urlaube der Kollegen eingetragen werden dürfen.

Natürlich ist bei diesen Überlegungen auch der eigene Papierkorb einzubeziehen. Hier ist sicherzustellen, dass die vertraulichen Dokumente in speziell gesicherten Containern entsorgt werden. Denn sonst führt es ja den ganzen Aufwand der Geheimhaltung wieder ad absurdum, wenn man diese nach Feierabend einfach aus dem Papierkorb ziehen kann.

Aber auch der virtuelle Schreibtisch ist Teil der Clean Desk Policy. Ganz besonders in Zeiten der virtuellen Videokonferenzen und Remote Arbeit können Fremde einen Blick auf den eigenen Schreibtisch erhaschen. Das erinnert mich auch an die Zeit der Vorlesungen, als ein Dozent mehrere Verknüpfungen des Papierkorbes auf seinem Desktop hatte. Wir haben immer gescherzt, dass er recycelt. Eigene Papierkörbe für Word, Excel etc. Dateien.

Die Clean Desk Policy hat allerdings auch andere Auswirkungen. Es ist durchaus mehr als nur ein Sicherheitskonzept. Denn Mitarbeiter, die diese Policy konsequent umsetzen, bringen dadurch auch mehr Ordnung in die eigenen Gedanken und können so Thema für Thema konzentriert abarbeiten, was zu einer besseren Performance führt. Meist erfolgt die persönliche Tagesplanung so, das zum Feierabend auch die begonnenen Aufgaben abgeschlossen werden können. Auch hier finden sich Analogien zum Handwerk. Denn der Handwerker versucht ebenfalls, den Auftrag möglichst bis zum Feierabend zu erledigen, um am nächsten Tag nicht noch einmal für kurze Zeit anrücken zu müssen. Denn auch hier wird einiges an Zeit für Vorbereitungen aufgewendet.

Die Umsetzung einer Clean Desk Policy erfolgt nach den drei P (Plan, Protect & Pick). Zu Beginn des Tages wird sich überlegt, welche Aufgaben erledigt werden sollen (Plan), und die entsprechenden Dokumente und benötigten Materialien werden ausgewählt, um darauf Zugriff zu haben. Am Ende des Tages werden die Dinge wieder sicher verstaut. Während der Arbeitszeit ist ebenfalls sicherzustellen, dass zum Beispiel in den Pausen keine unbefugten Personen Zugriff auf die Informationen haben. Diese tägliche, einfach umzusetzende Routine von Vorbereitung und Nachbereitung wird rasch zur Gewohnheit und die dafür aufzuwendened Zeit lässt sich auf wenige Minuten reduzieren, so dass kaum Arbeitszeit vergeudet wird.

Mit einer Clean Desk Policy verschwinden die erdrückenden Papierberge vom Schreibtisch, und durch die Überlegung, welche Aufgaben am Tag erledigt werden sollen, ist man besser auf diese fokussiert, was die Produktivität erheblich verbessert. Am Ende des Tages kann man nun mental auch einige Punkte von der eigenen Aufgabenliste streichen, was zu einer besseren Zufriedenheit führt.

Artikel

RTFM – benutzbare Dokumentationen

Elmar Dott Nov. 17, 2025

Artikel Publikationen

Prozesslandschaften

Elmar Dott Dez. 15, 2022

Artikel

Blockchain – eine Einführung

Elmar Dott Dez. 29, 2025

Frühjahrsputz für Docker

Veröffentlicht am 2026-02-02 von Elmar Dott

Antworten

Wer sich für diesen, eigentlich etwas spezialisierten Artikel interessiert, dem muss man nicht mehr erklären, was Docker ist und wofür das Virtualisierungswerkzeug eingesetzt wird. Daher richtet sich dieser Artikel vornehmlich an Systemadministratoren, DevOps und Cloud-Entwickler. Für alle, die bisher nicht ganz so fit mit der Technologie sind, empfehle ich unseren Docker Kurs: From Zero to Hero.

In einem Szenario, in dem wir regelmäßig neue Docker Images erstellen und verschiedene Container instanzieren, wird unsere Festplatte ordentlich gefordert. Images können je nach Komplexität durchaus problemlos einige hundert Megabyte bis Gigabyte erreichen. Damit das Erstellen neuer Images auch nicht gefühlt, wie ein Download einer drei Minuten langen MP3 mit einem 56k Modem dauert, nutzt Docker einen Build-Cache. Ist im Dockerfile wiederum ein Fehler, kann dieser Build-Cache recht lästig werden. Daher ist es eine gute Idee, den Build-Cache durchaus regelmäßig zu entleeren. Aber auch alte Containerinstanzen, die nicht mehr in Verwendung sind können zu komischen Fehlern führen. Wie hält man seine Dockerumgebung also stubenrein?

Sicher kommt man mit mit docker rm <container-nane> und docker rmi <image-id> schon recht weit. In Buildumgebungen wie Jenkins oder Serverclustern kann diese Strategie allerdings zu einer zeitintensiven und mühsamen Beschäftigung werden. Doch verschaffen wir uns zuerst einmal einen Überblick über die Gesamtsituation. Hier hilft uns der Befehl docker system df weiter.

root:/home# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          15        9         5.07GB    2.626GB (51%)
Containers      9         7         11.05MB   5.683MB (51%)
Local Volumes   226       7         6.258GB   6.129GB (97%)
Build Cache     0         0         0B        0B

root:/home# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          15        9         5.07GB    2.626GB (51%)
Containers      9         7         11.05MB   5.683MB (51%)
Local Volumes   226       7         6.258GB   6.129GB (97%)
Build Cache     0         0         0B        0B

Bevor ich gleich in die Details eintauche, noch ein wichtiger Hinweis. Die vorgestellten Befehle sind sehr effizient und löschen unwiderruflich die entsprechenden Bereiche. Daher wendet diese Befehle erst auf einer Übungsumgebung an, bevor ihr damit Produktivsysteme außer Gefecht setzt. Zudem hat es sich für mich bewährt, auch die Befehle zur Instanzierung von Containern in deiner Textdatei unter Versionsverwaltung zu stellen.

Plattenspieler

Der naheliegendste Schritt bei einem Docker System Cleanup ist das Löschen der nichtbenutzten Container. Im Konkreten bedeute das, dass durch den Löschbefehl alle Instanzen der Docker Container, die nicht laufen (also nicht aktiv sind), unwiederbringlich gelöscht werden. Will man auf einem Jenkins Buildnode vor einem Deployment Tabula Rasa durchführen, kann man zuvor alle auf der Maschine laufenden Container mit einem Befehl beenden.

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Der Parameter -f unterdrückt die Nachfrage, ob man diese Aktion wirklich durchführen möchte. Also die ideale Option für automatisierte Skripte. Durch das Löschen der Container erhalten wir vergleichsweise wenig Festplattenplatz zurück. Die Hauptlast findet sich bei den heruntergeladenen Images. Diese lassen sich ebenfalls mit nur einem Befehl entfernen. Damit Images allerdings gelöscht werden können, muss vorher sichergestellt sein, dass diese nicht durch Container (auch inaktive) in Verwendung sind. Das Entfernen ungenutzter Container hat noch einen ganz anderen praktischen Vorteil. Denn beispielsweise durch Container blockierte Ports werden so wieder freigegeben. Schließlich lässt sich ein Port einer Hostumgebung nur exakt einmal an einen Container binden. Das kann stellenweise schnell zu Fehlermeldungen führen. Also erweitern wir unser Skript um den Eintrag, alle nicht durch Container benutzten Docker Images ebenfalls zu löschen.

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Eine weitere Konsequenz unserer Bemühungen umfasst die Docker Layers. Hier sollte man aus Performancegründen, besonders in CI Umgebungen Abstand nehmen. Docker Volumes hingegen sind hier weniger problematisch. Beim Entfernen der Volumes, werden nur die Referenzen in Docker entfernt. Die in die Container verlinkten Ordner und Dateien bleiben von der Löschung unberührt. Der Parameter -a löscht alle Docker Volumes.

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Ein weiterer Bereich, der von unseren Aufräumarbeiten betroffen ist, ist der Build-Cache. Besonders wenn man gerade ein wenig mit dem Erstellen neuer Dockerfiles experimentiert, kann es durchaus sehr nützlich sein, den Cache hin und wieder manuell zu löschen. Diese Maßnahme verhindert, dass sich falsch erstellte Layer in den Builds erhalten und es später im instanziierten Container zu ungewöhnlichen Fehlern kommt. Der entsprechende Befehl lautet:

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Ganz radikal ist die Möglichkeit, alle nicht genutzten Ressourcen wieder freizugeben. Hierfür gibt es ebenfalls ein explizites Kommando für die Shell.

Abonnement / Subscription

[English] This content is only available to subscribers.

[Deutsch] Diese Inhalte sind nur für Abonnenten verfügbar.

Wir können die gerade vorgestellten Befehle natürlich auch für CI Buildumgebungen wie Jenkins oder GitLab CI nutzen. Allerdings kann es sein, dass dies nicht unbedingt zum gewünschten Ziel führt. Ein bewährter Ansatz für Continuous Integration / Continuous Deployment ist das Aufsetzen einer eigenen Docker-Registry, wohin man selbst erstellte Images deployen kann. Diese Vorgehensweise, ist ein gutes Backup & Chaching System für die genutzten Docker Images. Einmal korrekt erstellte Images lassen sich so bequem über das lokale Netzwerk auf die verschiedenen Serverinstanzen deployen, ohne dass diese ständig lokal neu erstellt werden müssen. Daraus ergibt sich als bewährter Ansatz ein eigens für Docker Images / Container optimierter Buildnode, um die erstellten Images vor der Verwendung optimal zu testen. Auch auf Cloudinstanzen wie Azure und der AWS sollte man auf eine gute Performanz und ressourcenschonendes Arbeiten Wert legen. Schnell können die anfallenden Kosten explodieren und ein stabiles Projekt in massive Schieflage bringen.

In diesem Artikel konnten wir sehen, dass tiefe Kenntnisse der eingesetzten Werkzeuge einige Möglichkeiten zur Kostenersparnis erlauben. Gerade das Motto „Wir machen, weil wir es können“, ist im kommerzeillen Umfeld weniger hilfreich und kann schnell zur teuren Resourcenverschwendung ausarten.

Konferenzen

Grazer Linux Tage 2022

Elmar Dott Apr. 23, 2022

Tutorials

Erste Schritte in Docker mit PostgreSQL

Elmar Dott Nov. 16, 2021

Artikel

Frühjahrsputz für Docker

Elmar Dott Feb. 2, 2026

Vibe Coding – eine neue Plage des Internets?

Veröffentlicht am 2026-01-26 von Elmar Dott

Antworten

Als ich das erste Mal den Begriff Vibe Coding las, dachte ich erst an Kopfhörer, chillige Musik und den Übertritt in den Flow. Der absolute Zustand der Kreativität dem Programmierer hinterherjagen. Ein Rausch der Produktivität. Aber nein, es wurde mir recht schnell klar, es geht um etwas anderes.

Vibe Coding nennt man das, was man einer KI über den Prompt eingibt, um ein benutzbares Programm zu erhalten. Die Ausgabe des Large Language Models (LLM) ist dann noch nicht gleich das ausführbare Programm, sondern nur der entsprechende Quelltext in der Programmiersprache, die der Vibe Coder vorgibt. Daher braucht der Vibe Coder je nachdem, auf welcher Plattform er unterwegs ist, noch die Fähigkeit, das Ganze zum Laufen zu bringen.

Seitdem ich in der IT aktiv bin, gibt es den Traum der Verkäufer: Man bräuchte keine Programmierer mehr, um Anwendungen für den Kunden zu entwickeln. Bisher waren alle Ansätze dieser Art wenig erfolgreich, denn egal was man auch tat, es gab keine Lösung, die vollständig ohne Programmierer ausgekommen ist. Seit der allgemeinen Verfügbarkeit von KI‑Systemen hat sich einiges geändert und es ist nur eine Frage der Zeit, bis man von den LLM-Systemen wie Copilot etc. auch ausführbare Anwendungen geliefert bekommt.

Die Möglichkeiten, die sich durch Vibe Coding eröffnen, sind durchaus beachtlich, wenn man weiß, was man da tut. Gleich aus Goethes Zauberlehrling, der der Geister, die er rief, nicht mehr Herr geworden ist. Werden Programmierer nun obsolet? Auf absehbare Zeit denke ich nicht, dass der Beruf Programmierer aussterben wird. Es wird sich aber einiges verändern und die Anforderungen werden sehr hoch sein.

Ich kann definitiv sagen, dass ich der KI Unterstützung beim Programmieren offen gegenüberstehe. Allerdings haben mich meine bisherigen Erfahrungen gelehrt, sehr vorsichtig zu sein mit dem, was die LLMs so als Lösung vorschlagen. Möglicherweise liegt es daran, dass meine Fragen sehr konkret und für spezifische Fälle waren. Die Antworten waren durchaus hin und wieder ein Fingerzeig in eine mögliche Richtung, die sich als erfolgreich herausgestellt hat. Aber ohne eigenes Fachwissen und Erfahrung wären alle Antworten der KI nicht nutzbar gewesen. Auch Begründungen oder Erläuterungen sind in diesem Kontext mit Vorsicht zu genießen.

Es gibt mittlerweile diverse Angebote, die den Leuten den Umgang mit künstlicher Intelligenz beibringen wollen. Also in Klartext, wie man einen funktionierenden Prompt formuliert. Ich halte solche Offerten für unseriös, denn die LLM wurden ja dafür entwickelt, natürliche (menschliche) Sprache zu verstehen. Was soll man also lernen, vollständige und verständliche Sätze zu formulieren?

Wer eine ganze Anwendung über Vibe Coding erstellt, muss diese ausgiebig testen. Also sich durch die Funktionen klicken und schauen, ob alles so funktioniert, wie es soll. Das kann durchaus zu einer sehr nervenden Beschäftigung ausarten, die mit jedem Durchlauf lästiger wird.

Auch die Verwendung von Programmen, die durch Vibe Coding erstellt wurden, ist unproblematisch, solange diese lokal auf dem eigenen Computer laufen und nicht als kommerzieller Internetservice frei zugänglich sind. Denn genau hier lauert die Gefahr. Die durch Vibe Coding erstellten Programme sind nicht ausreichend gegen Hackerangriffe gesichert, weswegen man sie nur in geschlossenen Umgebungen betreiben sollte. Ich kann mir auch gut vorstellen, dass künftig in sicherheitskritischen Umgebungen wie Behörden oder Banken die Verwendung von Programmen, die Vibe Coded sind, zu verbieten. Sobald die ersten Cyberattacken auf Unternehmensnetzwerke durch Vibe Coding Programme bekannt werden, sind die Verbote gesetzt.

Neben der Frage zur Sicherheit von Vibe-Coding-Anwendungen werden Anpassungen und Erweiterungen nur mit großem Aufwand umzusetzen sein. Dieses Phänomen ist in der Softwareentwicklung gut bekannt und tritt bei sogenannten Legacy Anwendungen regelmäßig auf. Sobald man hört, dass ist historisch gewachsen ist, man auch schon mitten drin. Fehlende Strukturen und sogenannte technische Schulden lassen ein Projekt über die Zeit so erodieren, dass sich die Auswirkungen von Änderungen nur sehr schwer auf die restlichen Funktionen abschätzen lassen. So ist zu vermuten, dass es in Zukunft sehr viele Migrationsprojekte geben wird, die die KI erstellten Codebasen wieder in saubere Struckturen überführen. Deswegen eignet sich Vibe Coding vor allem für die Erstellung von Prototypen, um Konzepte zu testen.

Mittlerweile gibt es auch Beschwerden in Open Source Projekten, dass es hin und wieder zu Contributions kommt, die nahezu die halbe Codebasis umstellen und fehlerhafte Funktionen hinzufügen. Hier helfen natürlich zum einen der gesunde Menschenverstand und die vielen in der Softwareentwicklung etablierten Standards. Es ist ja nicht so, dass man im Open Source nicht schon früher Erfahrung mit schlechten Code Commits gesammelt hätte. Dadurch kam der Diktaturship-Workflow für Werkzeuge wie Git, das von der Codehosting Plattform GitHub in Pull Request umbenannt wurde.

Wie kann man also schnell schlechten Code erkennen? Mein derzeitiges Rezept ist die Überprüfung der Testabdeckung für hinzugefügten Code. Kein Test, kein Codemerge. Natürlich können auch Testfälle Vibe Coded sein oder es fehlen notwendige Assertions, auch das lässt sich mittlerweile gut automatisiert erkennen. In den vielen Jahren in Softwareentwicklungsprojekten habe ich genügend erlebt, dass mir kein Vibe Coder auch nur annähernd Schweißperlen auf die Stirn treiben kann.

Mein Fazit zum Thema Vibe Coding lautet: Es wird in Zukunft einen Mangel an fähigen Programmierern geben, die Unmengen an schlechtem Produktivcode gerade biegen sollen. Also auf absehbare Zeit noch kein aussterbender Beruf. Dem gegenüber werden durchaus ein paar clevere Leute für das eigene Business sich mit einfachen Informatikkenntnissen ein paar leistungsfähige Insellösungen zusammenscripten, die zu Wettbewerbsvorteilen führen werden. Während wir diese Transformation erleben, wird das Internet weiterhin zugemüllt und die Perlen, von denen Weizenbaum einst gesprochen hat, schwerer zu finden sein.

Artikel

Performante Hardware unter Linux für lokale KI Anwendungen

Elmar Dott März 9, 2026

Artikel

Schreckgespenst künstliche Intelligenz

Elmar Dott Juli 27, 2023

Tutorials

Dokumente mit AnythingLLM und Ollama verarbeiten

Peter Kapherr Sep. 8, 2025

Der Goldene Schnitt

Veröffentlicht am 2026-01-19 von Neo Diseno

Antworten

Wenn wir Bilder betrachten, empfinden wir besonders diejenigen als ästhetisch, deren Elemente einem bestimmten Verhältnis von Strecken und Flächen folgen. Diese Harmonielehre nennt sich der „Goldene Schnitt“ und findet viel Anwendung in der Natur.

Nun könnte man meinen: In Zeiten der durch künstliche Intelligenz gerenderten Grafiken, benötigen wir die vielen Grundlagen des Grafikdesigns nicht mehr. Das ist allerdings zu kurz gedacht, denn einerseits müssen wir aus den Vorschlägen der erstellten Bilder die beste Variante auswählen. Um hier gute Entscheidungen zu treffen, sind Kenntnisse über Proportionen und Ästhetik essenziell. Außerdem müssen wir unseren Wunsch auch klar formulieren können, damit wir ein optimales Ergebnis erzielen. Nur die Dinge die wir wirklich vollständig durchdringen können wir auch klar und unmissverständlich formulieren. Deswegen ist ganz besonders im Umgang mit generativer KI ein fundiertes Fachwissen unverzichtbar.

Geometrisch bedeutet der Goldene Schnitt, dass eine Strecke AB in zwei unterschiedlich lange Streckenabschnitte (a und b) geteilt wird. Setzt man nun a durch b gleich der Summe (a+b) / a, so erhält man φ mit dem Wert 1,618. Übrigens entspricht der exakte Wert von φ der Quadratwurzel aus 5 (√5). Die Streckenverhältnisse betragen ungefähr 3:2. Die nachfolgende Grafik verdeutlicht den Zusammenhang.

Um den „Goldenen Schnitt“ auf Flächen anzuwenden, ist es nicht notwendig, im Abitur den Mathematikleistungskurs erfolgreich abgeschlossen zu haben. Wir benötigen lediglich die Zahl φ. Wenn wir ein Rechteck mit einer Kantenlänge von einem Zentimeter haben und 1 * 1,618 multiplizieren, erhalten wir 1,618. Nun können wir ein Rechteck mit der Kantenlänge a = 1 und b = 1,618 zeichnen. Das hier entstandene Verhältnis ist die perfekte Harmonie und wird als „Goldener Schnitt“ bezeichnet.

Wenn wir in dieses Rechteck unser Quadrat mit der Kantenlänge von einem Zentimeter hineinlegen, erhalten wir eine rechteckige Fläche B, die sich nach dem gleichen Muster aufteilen lässt. Wenn wir diesen Vorgang nun ein paar Mal wiederholen, erhalten wir ein gekacheltes Muster. Tragen wir jetzt in jedes entstandene Quadrat einen Kreisbogen mit dem Radius der Kantenlänge ein, erhalten wir eine Spirale. Die Form aus Abbildung 2 dürfte den meisten bereits bekannt sein und nun wisst ihr auch, wie sie entsteht.

Die soeben beschriebene Spirale findet sich auch in der sogenannten Fibonacci Zahlenfolge wieder. Die Fibonacci Folge ist eine einfache rekursive Addition aus den beiden Vorgängern. Abbildung 3 zeigt, wie schnell sich die Fibonacci Folge berechnen lässt. Wir sehen, es ist dazu kein höheres Studium der Mathematik notwendig.

Wo finden wir den Goldenen Schnitt in der Anwendung? Neben Proportionen in Logos und anderen Grafiken nutzt man den Goldenen Schnitt oft in der Typografie. Die Höhenverhältnisse von kleinen zu großen Buchstaben folgen gern dem Abstand 1:1,618.

Ein typisches Szenario für die Anwendung des Goldenen Schnitts ist auch die Position von Objekten innerhalb einer Grafik. Um eine gute Illusion von Tiefe zu erzielen, benötigen die Objekte ein entsprechendes Verhältnis der Höhen zueinander. Aber auch der Bereich, wie Objekte im Abstand zueinander positioniert werden, lässt ein Bild ruhig und harmonisch oder aufgewühlt und unruhig wirken. Wir haben also zwei Möglichkeiten, durch den Goldenen Schnitt eine Stimmung beim Betrachter zu erzeugen. Durch gezielte Verletzung der Proportionen erreichen wir eine gewisse Unruhe, die durchaus ebenfalls gewünscht sein kann. Eine solche invertierte Strategie kann zum Beispiel in der Werbung eingesetzt werden, um sich aus der Masse abzuheben und so beim Betrachter Aufmerksamkeit zu erregen.

Artikel

Marketing mit künstlicher Intelligenz

Neo Diseno Sep. 1, 2025

Artikel

PHP Elegant Testing in Laravel

Elmar Dott Okt. 6, 2025

Abonnement

WordPress REST API ist nicht erreichbar

Elmar Dott Juli 23, 2023

Featureitis

Veröffentlicht am 2026-01-12 von Elmar Dott

Antworten

Man muss nicht gleich Softwareentwickler sein, um ein gutes Anwendungsprogramm erkennen zu können. Doch aus eigener Erfahrung ist es mir oft passiert, dass Programme, die zu Beginn vielversprechend und innovativ waren, ab einer ‚gewissen‘ Nutzerzahl zu unhandlichen Boliden mutiert sind. Da ich diese Beobachtung nun schon einige Jahrzehnte regelmäßig aufs Neue mache, habe ich mich gefragt, woran das wohl liegen kann.

Das Phänomen, dass Softwareprogramme oder Lösungen im Allgemeinen mit Details überladen werden, hat Brooks in seinem Klassiker ‚The Mythical Man-Month‘ als Featuritis bezeichnet. Wenn man überlegt, dass die Erstausgabe des Buches im Jahr 1975 erschienen ist, kann man wohl von einem lange bekannten Problem sprechen. Das wohl bekannteste Beispiel für Featuritis ist das Betriebssystem Windows von Microsoft. Natürlich gibt es noch unzählige andere Beispiele für Verschlimmbesserungen.

Das Neueste wird nicht immer das Beste sein

Windowsnutzer, die bereits Windows XP kannten und dann mit dem tollen Nachfolger Vista konfrontiert wurden, um dann mit Windows 7 wieder besänftigt zu werden, um mit 8 und 8.1 beinahe einen Herzinfarkt erlitten zu haben, sich zu Beginn von Windows 10 wieder beruhigen. Jedenfalls für kurze Zeit, bis der Updatezwang für schnelle Ernüchterung sorgte. Von Windows 11 ganz zu schweigen. Zu Windows hieß es einmal, jede zweite Version ist Schrott, die sollte man überspringen. Nun ja, das stimmt seit Windows 7 schon lange nicht mehr. Für mich war Windows 10 dann der ausschlaggebende Punkt, vollständig auf Microsoft zu verzichten, und ich habe mir wie viele andere auch ein neues Betriebssystem zugelegt. Einige sind zu Apple gewechselt, und wer sich die teure Hardware nicht leisten kann oder will, hat wie ich auf ein Linuxsystem gesetzt. Hier zeigt sich, wie Uneinsichtigkeit schnell zum Verlust signifikante Marktanteile führt. Da Microsoft aus diesen Entwicklungen keine Konsequenzen zieht, scheint dem Unternehmen dieser Umstand weniger wichtig zu sein. Andere Unternehmen wiederum kann so etwas schnell an den Rand der Existenz bringen, und darüber hinaus.

Eine Motivation, immer mehr Funktionen in eine bestehende Anwendung zu bringen, ist der sogenannte Produktlebenszyklus, der durch die BCG Matrix in Abbildung 1 dargestellt wird.

Mit der Einführung ist noch nicht sicher, ob das Produkt vom Markt akzeptiert wird. Wenn es die Nutzer annehmen, steigt es schnell zum Star auf und erreicht seine maximale Marktposition als Cash Cow. Sobald die Sättigung überschritten wurde, degradiert es zum Ladenhüter. Soweit, so gut. Leider herrscht im Management überwiegend die Idee, dass, wenn kein Wachstum zum vorherigen Quartal mehr erzeugt wird, die Sättigung bereits überschritten wurde. So kommt es zu der sinnbefreiten Annahme, den Nutzern müsste jedes Jahr eine aktualisierte Version des Produktes aufgedrängt werden. Die Motivation zu kaufen gelingt natürlich nur, wenn eine dickgefüllte Featureliste an Neuerungen auf die Verpackung gedruckt werden kann.

Da sinnvoll konzipierte Funktionen sich aber nicht wie am Fließband aus dem Ärmel schütteln lassen, kommt auch jedes Mal gleich ein Redesign der grafischen Benutzeroberfläche als Gratis-Schmankerl mit dazu. Schließlich hat man dann das Gefühl, man habe etwas völlig Neues, weil man erst wieder eine Eingewöhnung braucht, um die neue Platzierung alt bekannter Funktionen zu entdecken. Es ist ja nicht so, dass das Redesign in der Benutzung Wege verkürzen würde und die Produktivität erhöht. Die Zusammenstellung der Eingabemasken und Schaltflächen erscheint jedes Mal willkürlich zusammengewürfelt.

Aber keine Sorge, ich will nicht zum Updateboykott aufrufen, sondern einmal darüber sprechen, wie man es besser machen kann. Denn eines sei gewiss: Dank künstlicher Intelligenz wird sich der Markt für Softwareprodukte in wenigen Jahren massiv verändern. Ich erwarte nicht, dass komplexe und spezialisierte Anwendungsprogramme in absehbarer Zeit durch KI-Algorithmen produziert werden. Allerdings erwarte ich, dass in diesen Anwendungsprogrammen genügend KI generierte schlechte Codesequenzen, die der Entwickler nicht versteht, in die Codebasis eingebracht werden, was zu unstabilen Anwendungen führen wird. Diese Überlegung ist für mich ein Grund, wieder über saubere, handgemachte, leitungsfähige und verlässliche Software nachzudenken, denn ich bin mir sicher, dass dafür immer ein Markt bestehen bleiben wird.

Ich möchte einfach keinen Internetbrowser, der zu einer Kommunikationszentrale mutiert ist und neben dem eigentlichen Anzeigen von Internetseiten noch Chat, E-Mail, Kryptobezahlmethoden und was weiß ich noch alles enthält. Ich möchte, dass mein Browser schnell startet, wenn ich irgendetwas klicke, dann schnell reagiert und die Inhalte der Internetseiten korrekt und schnell darstellt. Sollte ich einmal den Wunsch haben, etwas anderes mit meinem Browser zu tun, wäre es nett, wenn ich dies aktiv durch ein Plug-in aktivieren kann.

Nun gibt es zu dieser gerade beschriebenen Problemstellung oft die Argumentation, dass man ja mit den vielen Funktionen einen breiten Nutzerkreis erreichen möchte. Gerade wenn eine Anwendung zu Beginn alle möglichen Optionen auch aktiv eingeschaltet hat, holt das schnell den unkundigen Benutzer ab, der dann nicht erst begreifen muss, wie sein Programm überhaupt funktioniert. Ich kann diese Überlegung durchaus nachvollziehen. Es ist auch völlig in Ordnung, wenn ein Hersteller sich ausschließlich auf unkundige Anwender konzentriert. Es gibt aber einen Mittelweg, der alle Nutzergruppen gleichmäßig berücksichtigt. Diese Lösung ist auch nicht neu und sehr gut bekannt, die sogenannten Produktlinien.

In der Vergangenheit haben Hersteller immer Zielgruppen wie Privatpersonen, Unternehmen und Experten definiert. Diesen Nutzergruppen wurden dann oft Produktbezeichnungen wie Home, Enterprise und Ultimate zugeordnet. Das führte dazu, dass jeder die Ultimate Version wollte. Das Phänomen nennt sich Fear Of Missing Out (FOMO), also etwas zu verpassen. Deswegen sind die Bezeichnungen der Produktgruppen und deren zugeordneten Funktionen psychologisch ungeschickt gewählt. Wie kann man das also besser machen?

Ein Experte konzentriert sich bei seiner Arbeit auf spezielle Basisfunktionen, mit denen er seine Aufgaben schnell und ohne Ablenkung erledigen möchte. Das impliziert für mich Begriffe wie Essentials, Pure oder Core als Produktline.

Wenn das Produkt dann noch im Unternehmen von mehreren Personen verwendet werden soll, benötigt dies oft zusätzliche Funktionen wie zum Beispiel ein externes Benutzermanagement, wie LDAP oder IAM. Diese spezialisierte Produktlinie assoziiert Begriffe wie Enterprise (verbrannt), Company, Business und so weiter.

Das zugemüllte Endergebnis, das eigentlich für NOOPS gedacht ist und alle möglichen Sachen bereits über die Installation aktiviert hat. Wenn den Leuten die Zeit, bis die Anwendung gestartet ist und sie reagiert, egal ist, dann nur zu. Immer in die Vollen. Rein, was rein geht! Hier eignen sich Bezeichnungen wie Ultimate, Full und Maximized Extended als Bezeichnung der Produktlinie. Wichtig ist nur, dass die Profis erkennen, dass es sich um die zugemüllte Variante handelt.

Wer nun geschickt mit diesen Produktlinien spielt und möglichst alle Funktionen über sogenannte Module bereitstellt, die nachinstallierbar sind, ermöglicht eine hohe Flexibilität auch im Expertenmodus, denen durchaus die eine oder andere Zusatzfunktion genehm ist.

Installiert man auf das Modulsystem zuvor noch ein Tracking, um festzustellen, wie professionelle Anwender ihre Version upgraden, dann hat man schon eine gute Idee, was in die neue Version von Essentials hinzugefügt werden könnte. Bei dem Tracking sollte man sich aber nicht auf die Downloads als Entscheidungskriterium stützen. Ich selbst probiere oft Dinge aus und lösche Erweiterungen auch schneller, als der Installationsprozess gedauert hat, wenn ich der Meinung bin, dass diese nutzlos sind.

Ich möchte zu der gerade beschriebenen Problematik ein kleines Beispiel geben, das aus dem DevOps Bereich stammt. Zum einen gibt es das bekannte GitLab, das ursprünglich einmal ein reines Code Repository-Hosting-Projekt gewesen ist. Darauf deutet auch der Name, bis heute. Eine Anwendung, die auf einem Server bereits 8 GB RAM in der Basis-Installation benötigt, um ein Git Repository für andere Entwickler erreichbar zu machen, ist für mich unbrauchbar, denn diese Software wurde über die Zeit zur EierlegendenWollmilchSau. Langsam, unflexibel und mit allem Kram zugemüllt, der über Speziallösungen besser umgesetzt wurde.

GitLab gegenüber steht eine andere Lösung namens SCM-Manager, die weniger bekannt ist und sich ausschließlich auf das Bereitstellen der Code Repositories konzentriert. Ich selbst nutze und empfehle den SCM-Manager, weil er mit der Basis-Installation extrem kompakt ist. Aber dennoch gibt es eine gigantische Funktionsvielfalt, die man über Plug-ins nachrüsten kann.

Für mich sind Lösungen, die eine All In One Solution bereitstellen wollen, eher suspekt. Das ist für mich immer gleich dem Motto: alles und nichts. Es gibt keine EierlegendeWollMilchSau oder wie man in Österreich zu sagen pflegt, keinen Wunderwuzzi!

Wenn ich Programme für meinen Arbeitsprozess auswähle, orientiere ich mich ausschließlich an deren Kernfunktionalität. Sind die Grundeigenschaften, die das Marketing verspricht, wirklich vorhanden und möglichst intuitiv nutzbar? Gibt es eine aussagekräftige Dokumentation, die über ein bloßes ‚Hallo Welt‘ hinausgeht? Konzentriert man sich darauf, die Kernfunktionen stets zu optimieren, und berücksichtigt neue innovative Konzepte? Das sind Fragen, die für mich relevant sind.

Gerade im kommerziellen Umfeld werden oft Programme eingesetzt, die nicht halten, was das Marketing verspricht. Man wählt nicht aus, was man tatsächlich für die Erledigung der Aufgaben benötigt, sondern Anwendungen, deren Beschreibung mit sogenannten Buzzwords vollgestopft ist. Deswegen glaube ich, dass Unternehmen, die sich wieder auf die Kernkompetenzen fokussieren und dazu hoch spezialisierte Anwendungen nutzen, die Gewinner von morgen sind.

Artikel

Marketing mit künstlicher Intelligenz

Neo Diseno Sep. 1, 2025

Artikel

Stabilität in der Krise – business continuity & disaster recovery

Elmar Dott Okt. 21, 2024

Artikel

Clean Desk – mehr als nur Sicherheit

Elmar Dott Feb. 9, 2026

Von Missmanagement und Alpha-Geeks

Veröffentlicht am 2026-01-05 von Elmar Dott

Antworten

Als ich neulich das Buch „The Manager’s Path“ von Camille Fournier in die Hand bekam, war ich recht schnell an Tom DeMarco erinnert. Dieser hat den Klassiker „Peopleware“ geschrieben und Anfang 2000 das Buch „Adrenalin Junkies und Formular Junkies“ veröffentlicht. Eine Liste an Stereotypen, die man in Softwareprojekten antreffen kann, mit Hinweisen, wie man mit ihnen umgeht. Nach einigen Jahrzehnten im Geschäft kann ich jedes einzelne Wort aus eigener Erfahrung bestätigen. Und es ist auch heute noch immer ein Thema, denn Menschen machen nun einmal Projekte und wir alle haben so unsere Eigenheiten.

Damit Projekte erfolgreich verlaufen, müssen nicht nur technische Herausforderungen gemeistert werden. Auch zwischenmenschliche Beziehungen spielen eine wesentliche Rolle für deren Erfolg. Ein wichtiger Faktor in diesem Zusammenhang, der oft wenig Beachtung findet, ist die Projektleitung. Es gibt Regale voller hervorragender Literatur, wie man ein guter Manager werden kann. Das Problem ist leider, dass nur wenige, die diese Position besetzen, diese nicht ausfüllen und noch weniger Interesse besteht, die eigenen Fertigkeiten weiterzuentwickeln. Das Ergebnis von schlechtem Management sind aufgeriebene und gestresste Teams, extremer Druck im Tagesgeschäft und oft auch Verzug von Lieferterminen. Da braucht man sich auch nicht wundern, wenn dies Auswirkungen auf die Qualität des Produktes hat.

Einer der ersten Sprüche, den ich in meinem Berufsleben gelernt habe, war: Wer glaubt, dass ein Projektleiter Projekte leitet, der glaubt auch, dass ein Zitronefalter Zitronen faltet. Es scheint also eine sehr alte Weisheit zu sein. Was ist aber das wirkliche Problem bei schlechtem Management? Jeder, der eine Stelle für einen Manager zu besetzen hat, ist in der Pflicht, dessen Fertigkeiten und charakterliche Eignung auf Herz und Nieren zu prüfen. Hier lässt man sich schnell von inhaltslosen Floskeln und einer Liste großer Namen in der Branche in der Vita beeindrucken, ohne die tatsächliche Leistung zu hinterfragen. In meiner Erfahrung bin ich vornehmlich auf Projektleiter gestoßen, die oft nicht die notwendigen fachlichen Kenntnisse hatten, um wichtige Entscheidungen zu treffen. Nicht selten wurde ich in IT-Projekten von Managern mit den Worten „Ich bin kein Techniker, macht das unter euch aus.“, abgefertigt. Das ist natürlich fatal, wenn die Person, welche die Entscheidungen treffen soll, diese nicht treffen kann, weil das notwendige Wissen fehlt. Ein Manager im IT-Projekt muss natürlich nicht wissen, welcher Algorithmus schneller terminiert. Hierfür gibt es die Möglichkeit von Evaluierungen, als Grundlage von Entscheidungen. Aber ein Grundverständnis der Programmierung sollte vorhanden sein. Wer nicht weiß, was eine API ist und wieso Module, die später zu einer Software zusammengesetzt werden sollen, durch Versionskompatibilitäten nicht zusammenarbeiten, hat keine Berechtigung, sich als Entscheidungsträger aufzuspielen. Ein Grundverständnis über die Prozesse in der Softwareentwicklung und die verwendeten Programmierparadigmen ist auch für Projektleiter, die nicht am Code arbeiten, unumgänglich.

Ich plädiere daher dafür, dass man nicht nur die Entwickler, die man einstellt, auf ihre Fertigkeiten hin prüft, sondern auch die Manager, die in ein Unternehmen aufgenommen werden sollen. Für mich ist ein absolutes No Go bei der Auswahl meiner Projekte, ein externes Projektmanagement. Das führt in aller Regel nur zu Chaos und Frustration bei allen beteiligten Personen, weswegen ich solche Projekte ablehne. Manager, die nicht ins Unternehmen eingebunden sind und deren Leistung nach dem Erfolg von Projekten bewertet wird, liefern erfahrungsgemäß keine saubere Arbeit ab. Zudem können interne Manager, ebenso wie die Entwickler, durch Mentoring, Trainings und Workshops ihre Fertigkeiten entwickeln und weiter ausbauen. Das Ergebnis sind ein gesundes, entspanntes Arbeitsklima und erfolgreiche Projekte.

Der Titel dieses Artikels weist auf toxische Stereotypen im Projekteschäft hin. Ich bin mir sicher, jeder ist auf den ein oder anderen Stereotypen bereits im beruflichen Umfeld getroffen. Es wird viel diskutiert, wie man mit diesen Zeitgenossen umgehen soll. Ich möchte aber anmerken, dass kaum jemand als „Monster“ geboren wurde. Dass Menschen so sind, wie sie sind, ist das Resultat ihrer Erfahrungen. Lernt ein Kollege, dass er, wenn er gestresst ausschaut und immer hektisch wirkt, als guter Arbeiter wahrgenommen wird, perfektioniert er dieses Verhalten über die Zeit.

Camille Fournier hat es mit dem Begriff „The Alpha Geek“ sehr auf den Punkt gebracht. Jemand, der seine Rolle im Projekt unersetzlich gemacht hat und auf alles eine Antwort hat. Meist verächtlich auf die Kollegen herabschaut, aber nie eine Aufgabe wirklich ohne Nacharbeiten anderer sauber zu Ende bringen kann. Unrealistische Abschätzungen für umfangreiche Aufgaben sind ebenso typisch wie die Relativierung komplexer Sachverhalte. Natürlich ist das der Liebling aller Projektleiter, die sich wünschen, das ganze Team würde aus diesen „Alpha Geeks“ bestehen. Ich bin mir sehr sicher, wenn dieser Traum wahr werden könnte, es die optimale Strafe für die Projektleiter wäre, die solche Menschen erst möglich machen.

Damit man sich im eigenen Unternehmen keine „Alpha Geeks“ züchtet, ist es notwendig, keinen Personenkult zu etablieren und die persönlichen Favoriten gegenüber dem restlichen Team zu überhöhen und auf ein Podest zu stellen. Natürlich ist es auch unabdingbar, stets die Arbeitsergebnisse zu hinterfragen. Wer eine Aufgabe als erledigt markiert und diese Nacharbeiten erfordert, sollte diese Nacharbeiten stets erneut zugewiesen bekommen, bis das Ergebnis zufriedenstellend ist.

Ich persönlich habe die selbe Auffassung wie Tom DeMarco, was die Dynamiken eines Projektes betrifft. Die Produktivität kann man zwar über die Menge der erledigten Aufgaben bewerten, dennoch gibt es auch noch weitere Einflüsse, die eine wichtige Rolle spielen. So habe ich durch meine Erfahrung die Auffassung, dass man, wie bereits erwähnt, sehr viel Wert darauf legen sollte, dass Mitarbeiter die begonnenen Aufgaben sauber und vollständig lösen, bevor sie eine neue Aufgabe annehmen. Kollegen, die eine bestimmte Aufgabe „kleinreden“ und zu geringe, unrealistische Einschätzungen abgeben, genau diese Aufgabe übernehmen. Zudem gibt es auch Kollegen, die zwar einen recht geringen Output haben, dafür aber sehr viel für die Harmonie im Team beitragen.

Wenn ich über Menschen spreche, die ein gesundes Team formen, meine ich damit nicht jeden Tag Süßigkeiten hinzustellen. Es geht um die, die durchaus gute Fähigkeiten haben und diese als Mentor anderen Kollegen beibringen. Meist haben diese Personen einen guten Stand im Team und ihnen wird viel Vertrauen entgegengebracht, weswegen sie auch oft als Mediatoren bei Konflikten gute Ergebnisse erzielen. Es sind nicht die Menschen, die durch falsche Versprechen versuchen, everybodys Darling zu sein, sondern die, die zuhören und sich Zeit nehmen, eine Lösung zu finden. Sie sind oft das Mädchen für alles und haben nicht selten ein ruhiges, unscheinbares Auftreten. Da sie Lösungen haben und oft eine helfende Hand reichen, haben sie selbst eine mittelmäßige Bewertung ihrer Leistung in den typischen Prozessmetriken. Ein guter Manager erkennt diese Personen rasch, weil auf sie in aller Regel Verlass ist. Sie sind ausgeglichen und wirken wenig gestresst, weil sie mit Ruhe und Kontinuität vorgehen.

Natürlich kann man über die Stereotypen in einem Softwareprojekt noch viel mehr sagen, aber ich denke, die bereits getroffenen Ausführungen geben ein gutes Grundverständnis über das, was ich zum Ausdruck bringen möchte. Denn ein erfahrener Projektleiter kann viele der beschriebenen Probleme bereits während ihrer Entstehung wieder abstellen. Dazu gehören natürlich auch solides technisches Wissen und etwas Menschenkenntnis.

Es muss uns natürlich auch bewusst sein, dass erfahrene Projektleiter nicht einfach so da sind. Man muss sie genau wie die Mitglieder eines Teams entwickeln und fördern. Dazu gehört durchaus auch die Rotation durch alle technischen Abteilungen wie Entwicklung, Test und Betrieb. Dazu eignen sich Paradigmen wie Pairprogramming hervorragend. Denn es geht nicht darum, aus einem Manager einen Programmierer oder Tester zu machen, sondern ihm oder ihr ein Verständnis der täglichen Abläufe zu verschaffen. Das stärkt auch das Vertrauen in die Fertigkeiten des gesamten Teams, und Mentalitäten wie: Man müsse die faulen und unfähigen Programmierer kontrollieren und antreiben, damit sie einen Finger rühren, kommen gar nicht erst auf. In Projekten, die regelmäßig gute Qualität abliefern und ihre Termine einhalten, kommt selten der Wunsch auf, alle möglichen Prozessmetriken einzuführen.

Artikel