Dieses Bild trudelte grad über Google+ rein:

Im ersten Moment dachte ich: Hihihihi. Leider stellt es die Realität dar.

So ein typischer Software-Entwickler will Dinge bauen und er will sie geil bauen und vor allem: Richtig. Und er fängt auch richtig an, nimmt sich viel Zeit für die Grundmauern. Doch dann kommt die Realität.

Diese Realität sieht oft so aus, dass das geplante Featureset zwar toll ist, aber leider nicht ausreicht, da jeder Mensch die eierlegende Wollmilchsau möchte. Das ist auch ganz normal, denn bei einem Auto möchte man ja auch nicht immer nur von A nach B kommen, sondern die Fahrt dann gerne auch mit Klimaanlage in wohliger Atmosphäre oder bei lauter Musik mit einer tollen Soundanlage genießen.

Nur so ein Auto wird meist über viele Jahre hinweg geplant. Software nicht. Heutzutage sind viele Softwareprojekte gern „agil“. Agilität ist eine super Sache - man braucht nicht weit zu denken, sondern klatscht in kleinen Schritten Dinge außen an das Grundgerüst dran. Auch dieses dranklatschen ist keine so verkehrte Sache, denn man kann bei der Softwareentwicklung tatsächlich eingreifen, wenn ein Projekt in die falsche Richtung läuft.

Was fehlt: Zeit zum Aufräumen (Refactoring)

Nehmen wir eine normale Website als Beispiel. So eine einfache Website mit einem Impressum (ohne Templates o.ä.). Jetzt will der Kunde eine „Über mich“ Seite, die genauso aussieht wie die Impressum-Seite mit anderen Texten. Was passiert? Man kopiert das Impressum und tauscht den Text aus. Will man jetzt einen Tag im Header ändern, muss man schon zwei Dateien anpassen, damit es bei beiden Dateien gleich ist. Das wäre so, als würde ein Tanklaster an einer Tankstelle jede Zapfsäule einzeln beladen. Dieses System skaliert nicht.

Wie aber macht man jetzt dem Kunden klar, dass man hier lieber Refactoring betreiben sollte, damit zukünftige Arbeiten nicht doppelt passieren müssen?

Frühzeitige Erkenntnis wecken. Wenn ursprünglich die Website nur als Impressum diente und jetzt plötzlich doch mehr Inhalte kommen, muss man dem Kunden gleich klarmachen, dass noch weitere Änderungen kommen werden, auch wenn er es selbst noch nicht weiß.

Man rechnet ihm vor, was zukünftige kleine Änderungen kosten werden, im Gegensatz zu einer einmaligen (nicht unwesentlich größeren) Änderung, die jetzt gleich und richtig gemacht wird. Wenn er es trotzdem nicht möchte, hat man ja glücklicherweise die E-Mail mit der Belehrung als Beweis, dass man ihn nicht über den Tisch ziehen will 🙂