"Kannst du da nicht einfach noch schnell ein Feld dazunehmen?" Der Satz klingt harmlos, und manchmal ist er das auch. Oft aber nicht. Das Verwirrende daran: Wie gross ein Wunsch für dich aussieht, hat erstaunlich wenig damit zu tun, wie viel Arbeit dahinter steckt. Warum das so ist, lässt sich erklären, ohne dass du eine Zeile Code liest.

Es ist eine der häufigsten Spannungen in einem Projekt, und sie ist völlig verständlich. Du siehst eine Software, die fast genau das tut, was du brauchst. Eine Kleinigkeit fehlt noch. Ein zusätzliches Feld, ein Knopf an einer anderen Stelle, eine Spalte mehr in der Liste. Von aussen wirkt das nach zehn Minuten. Und dann hörst du eine Schätzung, die sich anfühlt wie aus einer anderen Welt. Das ist kein Aufschlag und keine Unlust. Es ist der Unterschied zwischen dem, was du siehst, und dem, was darunterliegt.

Die Grösse des Wunsches sagt nichts über den Aufwand

Wir unterscheiden beim Schätzen nicht danach, wie wichtig oder wie gross eine Änderung für dich klingt. Wir schauen, woran sie hängt. Und da liegen die Überraschungen oft genau andersherum, als man erwartet.

Manchmal ist der grosse, dramatische Wunsch der billige. Eine ganze neue Seite, die für sich steht und mit dem Rest wenig zu tun hat, bauen wir oft schneller, als du denkst, weil sie niemandem ins Gehege kommt. Und manchmal ist die winzige Änderung die teure. Ein einziges Feld, das an einer Stelle auftaucht, aber an fünf anderen Stellen mitgedacht, gespeichert, geprüft und angezeigt werden muss. Das Sichtbare ist in beiden Fällen die Spitze. Entscheidend ist, was darunter zusammenhängt.

Woher kommt das überhaupt?

Nehmen wir das harmlose Beispiel: ein zusätzliches Feld im Formular. Sagen wir, die Telefonnummer eines zweiten Ansprechpartners. Was du siehst, ist eine leere Zeile mehr. Was dahinter passieren muss, ist eine Reihe von Fragen, die alle beantwortet werden wollen.

Wo wird diese Nummer gespeichert? Das heisst, die Datenbank bekommt einen neuen Platz dafür. Was passiert mit den Datensätzen, die es schon gibt und die dieses Feld noch nicht kennen? Darf es leer bleiben, oder ist es Pflicht? Soll geprüft werden, ob da wirklich eine Nummer steht und nicht ein Name? Taucht die Nummer auch in der Übersicht auf, im Export, in der E-Mail, die automatisch rausgeht? Jede dieser Fragen ist für sich klein. Zusammen sind sie der Grund, warum "nur ein Feld" selten nur ein Feld ist.

Eine Änderung zieht an einem Faden

Gute Software ist wie ein Gewebe. Die Teile hängen zusammen, damit das Ganze als eine Einheit funktioniert und nicht als loser Haufen. Genau dieser Zusammenhang, der im Alltag ein Vorteil ist, macht Änderungen aufwendig. Wenn du an einer Stelle ziehst, bewegt sich der Rest mit.

Das ist übrigens kein Zeichen für schlechten Code, sondern eher das Gegenteil. In einem sauber gebauten System ist ziemlich klar, was sich mitbewegt, und genau deshalb lässt es sich sicher ändern. Wenn eine kleine Änderung plötzlich unberechenbar wird und niemand sagen kann, was sonst noch kaputtgeht, ist das ein anderes Problem. Dann ziehen die technischen Schulden die Rechnung hoch, nicht die Änderung an sich.

Ziehst du an einem Faden, bewegt sich das Gewebe

Ziehst du an einem Faden, bewegt sich das Gewebe

Die Teile einer Software hängen zusammen, damit das Ganze als Einheit funktioniert. Genau dieser Zusammenhalt ist im Alltag ein Vorteil und bei Änderungen der Grund für den Aufwand. Eine Anpassung an einer Stelle zieht an allem, was damit verbunden ist. In einem sauberen System ist dieser Zug berechenbar, und genau das macht Änderungen sicher statt riskant.

Der Aufwand einer Änderung steckt selten in dem, was du änderst. Er steckt in allem, was mit dieser einen Stelle verbunden ist und mitbedacht werden muss.

Und das Prüfen zählt auch dazu

Es gibt einen Teil, der von aussen komplett unsichtbar ist und trotzdem echte Zeit kostet: sicherzustellen, dass die Änderung nichts kaputt gemacht hat, das vorher lief. Wir bauen nicht nur das neue Feld, wir prüfen auch, dass die zehn Dinge drumherum noch genauso funktionieren wie vorher.

Dafür haben wir automatische Tests, die genau diese Arbeit zu grossen Teilen übernehmen. Aber auch die wollen angepasst werden, wenn sich etwas ändert. Dieser Schritt lässt sich nicht weglassen, auch wenn er in keiner Schätzung aufregend klingt. Die Alternative wäre, nach jeder Kleinigkeit zu hoffen, dass schon nichts passiert ist. Das ist keine Alternative.

Wann klein wirklich klein ist

Jetzt die faire andere Seite, denn sonst klingt das, als wäre bei uns alles teuer. Das ist es nicht. Viele Änderungen sind genau das, wonach sie aussehen: schnell. Ein Text, der angepasst wird. Eine Farbe. Eine Spalte, die bloss ausgeblendet wird. Wir schlagen da nichts drauf, nur weil es "Entwicklung" heisst.

Und es geht auch andersherum: Manchmal hältst du einen Wunsch für riesig und zögerst, ihn überhaupt anzusprechen, dabei ist er in einer halben Stunde erledigt. Genau deshalb lohnt es sich, einfach zu fragen, statt selber zu schätzen. Du kannst von aussen nicht wissen, was teuer ist und was nicht, und das musst du auch nicht. Das ist unser Teil. Deiner ist, zu sagen, was du brauchst.

Die Faustregel

Nenn uns das Ziel, nicht die technische Lösung. "Ich will beim Kunden eine zweite Nummer hinterlegen können" ist besser als "nimm da ein Feld dazu". Oft gibt es einen Weg zum selben Ziel, der dich einen Bruchteil kostet. Den finden wir aber nur, wenn wir wissen, worum es dir wirklich geht, nicht nur, was du dir als Lösung vorstellst.

Am Ende ist das die eigentliche Botschaft, und sie ist eine gute: Lass dich von der scheinbaren Grösse einer Idee nicht abschrecken und von ihrer scheinbaren Kleinheit nicht täuschen. Frag einfach. Ein Studio, das dir ehrlich sagt, wann etwas zehn Minuten dauert und wann zwei Tage, und warum, ist mehr wert als eines, das zu allem Ja sagt und dich die Überraschung später selber finden lässt. Was so eine ehrliche Schätzung ausmacht, haben wir in Was kostet das? aufgeschrieben.

Du hast so ein "nur schnell noch das" auf dem Herzen und willst wissen, was wirklich dahintersteckt? Frag uns, wir sagen dir ehrlich, ob es zehn Minuten oder zwei Tage sind.

#Engineering#Aufwand#Zusammenarbeit#Ohne Bullshit
Marco

Marco

Co-Founder & Lead Engineer · FlowCode Bern. Schreibt über das, was beim Bauen wirklich passiert.