Baueinteilung

In dem Betrieb wird die Woche am Montag verteilt: Welche Mannschaft fährt auf welche Baustelle, wer ist krank, wer im Urlaub, wo fehlt noch jemand. Vorher hing das an einer Pinnwand-Software, die für den Bildschirm im Büro nie gedacht war — auf dem Fernseher kaum lesbar, und jede Woche wurde alles neu geschoben.

Die Baueinteilung macht daraus eine Seite. Fünf Spalten, eine je Werktag. Jede Karte ist ein Bauvorhaben mit seiner Mannschaft; Namen werden mit der Maus verschoben und rasten in ein Raster ein. Nichts scrollt, nichts klappt weg, und es gibt keine Bedienleiste, die den Blick stiehlt. Wer im Raum sitzt, soll die Woche von seinem Platz aus lesen können — das war die härteste Anforderung, härter als jede technische.

Bedient wird währenddessen live. Verschiebt jemand eine Karte, sehen alle anderen Geräte die Änderung sofort; der Stand wird von selbst gespeichert. Alles läuft auf einem Rechner im Haus des Betriebs — kein fremder Server, keine Cloud, keine Konten bei einem Anbieter.

Die Woche ist nur die Oberfläche. Dahinter liegt, was den Betrieb am Laufen hält: wer dazugehört, welche Bauvorhaben es gibt, welche Leute üblicherweise zusammen fahren — und eine Spur davon, wer wann was geändert hat. An diesen Bereichen wurde am längsten gearbeitet, obwohl man sie im Alltag am seltensten öffnet.

Eine Webseite, die im Firmennetz auf einem kleinen Rechner läuft. Im Browser React mit einer Bibliothek fürs Ziehen und Ablegen, auf der anderen Seite ein eigener Server mit SQLite und einer offenen Verbindung für den Live-Abgleich. Zusammen kommt das mit vier Paketen aus, die im Betrieb mitlaufen — alles Übrige ist Werkzeug für die Entwicklung und bleibt draußen.

Angemeldet wird mit einem Code, ohne Benutzernamen. Das ist bequem — an einem Fernseher im Büro will niemand Namen tippen —, hat aber eine unangenehme Eigenschaft: Wer blind durchprobiert, muss nicht den Code eines bestimmten Menschen treffen, sondern irgendeinen. Jeder zusätzliche Zugang macht die Tür also leichter auf, nicht sicherer. Deshalb steht der Hinweis, sparsam zu sein, im Programm selbst — dort, wo jemand einen Code vergibt, und nicht in einer Anleitung, die niemand liest.

Dieselbe Rechnung hat die Länge der Codes entschieden. Bei vier Ziffern und zehn Zugängen sitzt im Schnitt nach 909 Versuchen einer. Mit der damaligen Bremse — vierzig Versuche je Stunde — wäre ein unbeaufsichtigtes Skript in knapp einem Tag drin gewesen. Mit sechs Ziffern sind es rund 95 Tage bei sonst gleicher Bremse. Es wurde auf sechs umgestellt.

Dazu kam eine Sperre, die mit jedem Mal länger wird: nach zehn Fehlversuchen eine Viertelstunde, beim nächsten Mal eine Stunde, dann vier. Ein Mensch merkt davon nichts — wer sich zweimal vertippt, löst gar keine Sperre aus. Für ein Skript bricht das Tempo dagegen zusammen: Statt tausend Versuchen am Tag bleiben rund vierzig, und aus knapp einem Tag werden rund vier Jahre.

Bei vier Stunden ist die Treppe zu Ende, und das ist Absicht. Längere Stufen bringen nichts, was zählt — vier Jahre und vierzig Jahre heißen beide „kommt nicht rein" —, kosten aber im Ernstfall echte Zeit. Der Ernstfall ist nämlich nicht der Angreifer, sondern der Betrieb selbst: Wer während einer Sperre keinen gültigen Nachweis im Browser hat, kommt nicht herein und erreicht damit auch den Knopf zum Lösen nicht. Eine Tagessperre hieße dann: einen Tag lang keine Baueinteilung.

Die Codes liegen nirgends im Klartext, sondern als nicht umkehrbarer Abdruck mit eigenem Salz, absichtlich langsam gerechnet. Verglichen wird so, dass die gebrauchte Zeit nichts über den Code verrät. Jede Sperre landet im Protokoll — als Urheber steht dort das Programm selbst. Und ein geänderter Code wirft den, der damit angemeldet war, sofort hinaus.

SQLite statt einer Datei mit den Wochendaten. Speichern zwei Leute gleichzeitig und der Server stürzt dabei ab, ist eine halb geschriebene Datei unbrauchbar — und mit ihr die Woche. SQLite schreibt entweder ganz oder gar nicht. Für die Sicherung ändert sich nichts: Es bleibt eine einzelne Datei zum Wegkopieren.

Und ausdrücklich ohne SQLites Schreibprotokoll. Das wäre bei gleichzeitigen Zugriffen schneller, macht aus der Ablage aber drei Dateien statt einer. Wer nur die Hauptdatei wegsichert — und genau das tut ein Dateisicherer —, sichert dann eine leere Datenbank. Der kleine Geschwindigkeitsgewinn ist es nicht wert, dass eine Sicherung im Ernstfall nichts enthält.

Geprüft wird in beide Richtungen. Beim Lesen wie beim Schreiben schaut das Programm nicht nur jedes Feld für sich an, sondern die Woche als Ganzes: niemand an einem Tag an zwei Orten, niemand gleichzeitig eingeteilt und krank gemeldet. Ein Fehler soll auffallen, solange er sich noch beheben lässt.

Eine Sicherung je Tag, dreißig Tage aufbewahrt. Kopiert wird mit SQLites eigenem Befehl dafür, nicht mit einem Dateikopierer: Das liefert eine in sich stimmige Datei, auch wenn gerade jemand schreibt.