Wie der Blogger John Sonmez meint, verstehen selbst die besten Chefs häufig nicht wirklich, was man in der Softwareentwicklung tun und was man besser lassen sollte. Kommt Ihnen das bekannt vor?

1. Technische Schulden bremsen Projekte ungemein aus

Wie Sonmez anmerkt, verstehen Manager und andere nicht-technische Mitarbeiter oft einfach nicht, dass mit einem Drang nach höherer Produktivität meist unweigerlich ein Absinken der Qualität einhergeht, sprich technische Schulden angehäuft werden. Will man also nicht sozusagen die Gans töten, die die goldenen Eier legt, muss man stets ein Auge darauf werfen, dass sich – nach Steven R. Covey – Produktion und Produktionsfähigkeit die Waage halten.

2. Schätzungen taugen nichts

Die Frage nach Sinn oder Unsinn von Aufwandsschätzungen war auch auf JAXenter schon häufiger ein Thema. So auch bei Sonmez: Ihm zufolge sind sogar Schätzungen, die weiter als 2 Stunden in die Zukunft reichen, wertlos. Den Grund hierfür sieht Sonmez schlicht und ergreifend darin, dass, da fast jedes Projekt quasi Neuland darstellt, ständig Unvorhergesehenes geschehen kann – ein Umstand, der nicht zu beseitigen ist. Falls Vorgesetzte dennoch auf Schätzungen bestehen, sollte man Sonmez zufolge entweder versuchen, sie von deren Unsinnigkeit zu überzeugen oder darauf bestehen, die anstehenden Aufgaben derart herunterzubrechen, dass die Schätzungen jeweils nur kurze Zeiträume umfassen.

3. Man kann es schnell oder richtig machen

Für Sonmez eine Selbstverständlichkeit, für zahlreiche Führungspersönlichkeiten offenbar nicht: Hetzt man einen Entwickler, ist er zwar schneller fertig. Das Ergebnis ist allerdings, zwar nicht mit absoluter Sicherheit, jedoch ziemlich hoher Wahrscheinlichkeit, Mist. Denn viele Programmierer nehmen in stressigen Situationen Abkürzungen, die der Qualität abträglich sind. Ein Dorn im Auge sind Sonmez auch die sog. „Cowboy Coder“, die ihre Arbeit zwar immer in atemberaubender Geschwindigkeit erledigen, dabei jedoch eine große Sauerei aka. technische Schulden für alle anderen hinterlassen.

Ein Tipp von Sonmez für all jene, die mit Chefs zu tun haben, die für den Satz „Man kann es schnell oder richtig machen“ taub sind: Statistiken aufstellen, die zeigen, dass das Ausbügeln eines Bugs deutlich kostspieliger ist, als seine Verhinderung.

4. Manche Entwickler liefern weniger als Null ab

Mache Entwickler, so Sonmez, schaden einem Team mehr als Sie helfen, sprich: Jede Codezeile, die sie produzieren, schafft Probleme, anstatt sie zu lösen. Doch wer möchte, trotz Unfähigkeit und/oder Faulheit, schon einen Mitarbeiter anschwärzen? Sonmez ist sich dieses Problems zwar bewusst, besteht jedoch darauf, dass dies den einzigen Ausweg darstellt, wenn ein Mitarbeiter das gesamte Team herunterzieht. Vielmehr, so Sonmez, mache man sich gar zum Komplizen, wenn man die Füße still hält.

5. Besseres Equipment ist mit die günstigste Investition in Produktivität

5 Jahre alte Rechner, kein zweiter Bildschirm … Sonmez kennt sie alle, die Geschichten über Produktivitätskiller, die dem Geiz der Vorgesetzten zugeschrieben werden können. Eingedenk des meist überdurchschnittlichen Gehalts eines Programmierers stellt neues Equipment laut Sonmez eigentlich einen zu vernachlässigenden Kostenpunkt dar – vielmehr ist es sogar eine Investition, die sich schnell bezahlt macht: Selbst wenn ein Entwickler durch besseres Equipment nur eine halbe Stunde Arbeitszeit pro Tag einspart, hat sich die Hardware schnell amortisiert. Leider, so Sonmez, kann man bei uneinsichtigen Chefs in der Regel nicht viel mehr tun als entweder seine eigenen Peripheriegeräte mitbringen – oder sich einen anderen Job mit schlaueren Vorgesetzten suchen.

6. Neue Technologien sind meist weniger risikoreich als gedacht

In früheren Zeiten war es, so Sonmez, eine berechtigte Furcht der Führungsebene, dass ein Framework zu selten Updates erfährt und, da der Quellcode nicht Open Source war, man nach Ende des offiziellen Supports in der Luft hing. In der heutigen Zeit, da Frameworks teils gar täglich gepatcht werden und viele von ihnen quelloffen sind, ist diese Furcht für ihn jedoch vergleichsweise irrational. Im Gegenteil: Heute kann es seiner Ansicht nach sogar deutlich gefährlicher sein, an einer alten Version eines Frameworks oder einer Bibliothek festzuhalten, anstatt auf eine neue umzusteigen.

7. Business Analysten und Projektmanager tun … gar nichts

Eine steile These, doch Sonmez ist der Ansicht, dass sich beide Positionen überlebt haben, mehr noch: Nutzlos sind. So seien erstere überflüssig, da der direkte Kontakt zwischen Kunde und Entwickler für beide Seiten deutlich erhellender sei. Und letztere seien in Zeiten der agilen Softwareentwicklung meist einfach nur im Weg. Wie den Chef auf diesen Umstand aufmerksam machen? Sonmez Antwort: Durch vorgelebte Agilität.

Fallen Ihnen noch weitere Kardinalsünden der Chefetage ein? Lassen Sie es uns in den Kommentaren wissen!

Aufmacherbild: angry boss concept von Shutterstock / Urheberrecht: Mr-Vector7