Paradoxe Erlebnisse sind für Softwareentwickler Alltag.Rosemarie Mosteller | shutterstock.com Vergleicht man den Bau von Brücken mit der Softwareentwicklung, zeigen sich bedeutende Unterschiede: Denn auch wenn keine Brücke – ähnlich wie ein Softwareprojekt – der anderen bis aufs „Haar“ gleicht, werden sie aus bekannten Materialien mit bekannten Eigenschaften geschaffen. Im Gegensatz dazu beinhaltet der Softwareentwicklungsprozess wesentlich mehr „unknown Unknowns“. Was dazu führt, dass er jede Menge Paradoxa beinhaltet, mit denen Developer teilweise nur schwer umgehen können. Wichtig ist aber vor allem, sich ihre Existenz bewusst zu machen – nur so lassen sich die daraus entstehenden Fallstricke umgehen. Insbesondere, wenn es dabei um die folgenden vier Paradoxa geht. 1. Ohne Plan, aber mit Deadline Zielführend einzuschätzen, wie lange ein Softwareprojekt dauern wird, ist wahrscheinlich die größte Herausforderung für Softwareentwickler überhaupt. Denn darüber lässt sich keine abschließende, verbindliche Aussage treffen. Sicher, man kann den ungefähren Aufwand schätzen – das geht im Regelfall allerdings daneben. Meistens wird der zeitliche Aufwand drastisch unterschätzt. Wird die gesetzte Deadline dann verpasst, ärgern sich vor allem die Kunden. Sie stecken nicht in der Haut der Devs und durchblicken die Abläufe und möglichen Hindernisse (im Regelfall) nicht. Also sind sie frustriert, weil ihre Software nicht zum vereinbarten Zeitpunkt ausgeliefert wird. Auch sämtliche Versuche, mit schicken, agilen Methoden wie Story Points oder Planing Poker zielführender vorhersagen zu wollen, wann ein Softwareprojekt abgeschlossen wird, bringen nichts wenig. Wir scheinen einfach nicht in der Lage, Hofstadters Gesetz (der Verzögerung) zu überwinden. 2. Mehr Mannstärke, mehr Verzug Stellt ein Manager einer Fabrik fest, dass die monatliche Quote für abgefüllte Zahnpastatuben in Gefahr ist, setzt er mehr Arbeiter ein, um die Vorgabe zu erfüllen. Ähnlich verhält es sich beim Hausbau: Wenn Sie doppelt so viele Häuser wie im Vorjahr bauen wollen, hilft es in der Regel, die Vorleistungen – Arbeit und Material – zu verdoppeln. Im Fall der Softwareentwicklung verhält sich das völlig anders, wie Frederick Brooks bereits 1975 in seinem Buch „Vom Mythos des Mann-Monats“ herausgearbeitet hat. Demnach hilft es wenig, verzögerte Softwareprojekte mit zusätzlicher Mannstärke retten zu wollen. Im Gegenteil: Gemäß dem Brooks’schen Gesetz verzögert das das Projekt nur noch zusätzlich. Schließlich können neu hinzukommende Teammitglieder nicht sofort zum Projekt beitragen. Sie benötigen Zeit, um sich in den Kontext komplexer Systeme einzuarbeiten, was oft auch zusätzliche Kommunikationsmaßnahmen nach sich zieht. Am Ende verzögert sich dann nicht nur alles noch weiter – es kostet auch mehr. 3. Mehr Skills, weniger Programmier-Tasks Als Softwareentwickler umfassende Expertise aufzubauen und sämtliche erforderlichen Regeln und Feinheiten zu verinnerlichen, um wartbaren, sauberen Code zu schreiben, nimmt etliche Jahre in Anspruch. Dabei erscheint es auch relativ paradox, dass die Programmieraufgaben mit steigender Erfahrung eher weniger werden: Statt zu programmieren, sitzen leitende Entwickler vor allem in Design-Meetings, überprüfen den Code anderer und übernehmen weitere Führungsaufgaben. Das heißt zwar nicht, dass Senior Developer einen kleineren Beitrag leisten. Schließlich sorgen sie in Führungspositionen dafür, dass zeitgemäß und zielführend gearbeitet wird und tragen so wesentlich zum Team- und Unternehmenserfolg bei. Aber am Ende schreiben sie dennoch weniger Code. 4. Bessere Tools, keine Zeitvorteile Vergleicht man die Webentwicklung von heute mit performanten Tools wie React, Astro und Next.js mit dem Gebaren von vor 30 Jahren (Stichwort Common Gateway Interface), wird klar, dass wir uns seitdem um Lichtjahre weiterentwickelt haben. Doch obwohl unsere Tools immer besser und die Prozessoren immer schneller werden, scheinen sich Softwareprojekte insgesamt nicht zu beschleunigen. Das wirft Fragen auf: Unsere Websites sehen zwar immer besser aus, aber sind wir wirklich produktiver? Laufen unsere Websites schneller und verarbeiten sie Daten besser? Natürlich abstrahieren die Frameworks und Bibliotheken von heute viele Komplexitäten. Sie führen aber auch zu neuen Problemen. Zum Beispiel langen Build-Pipelines, Konfigurationsalbträumen oder Abhängigkeitsproblemen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Die größten Paradoxa der Softwareentwicklung
Paradoxe Erlebnisse sind für Softwareentwickler Alltag.Rosemarie Mosteller | shutterstock.com Vergleicht man den Bau von Brücken mit der Softwareentwicklung, zeigen sich bedeutende Unterschiede: Denn auch wenn keine Brücke – ähnlich wie ein Softwareprojekt – der anderen bis aufs „Haar“ gleicht, werden sie aus bekannten Materialien mit bekannten Eigenschaften geschaffen. Im Gegensatz dazu beinhaltet der Softwareentwicklungsprozess wesentlich mehr „unknown Unknowns“. Was dazu führt, dass er jede Menge Paradoxa beinhaltet, mit denen Developer teilweise nur schwer umgehen können. Wichtig ist aber vor allem, sich ihre Existenz bewusst zu machen – nur so lassen sich die daraus entstehenden Fallstricke umgehen. Insbesondere, wenn es dabei um die folgenden vier Paradoxa geht. 1. Ohne Plan, aber mit Deadline Zielführend einzuschätzen, wie lange ein Softwareprojekt dauern wird, ist wahrscheinlich die größte Herausforderung für Softwareentwickler überhaupt. Denn darüber lässt sich keine abschließende, verbindliche Aussage treffen. Sicher, man kann den ungefähren Aufwand schätzen – das geht im Regelfall allerdings daneben. Meistens wird der zeitliche Aufwand drastisch unterschätzt. Wird die gesetzte Deadline dann verpasst, ärgern sich vor allem die Kunden. Sie stecken nicht in der Haut der Devs und durchblicken die Abläufe und möglichen Hindernisse (im Regelfall) nicht. Also sind sie frustriert, weil ihre Software nicht zum vereinbarten Zeitpunkt ausgeliefert wird. Auch sämtliche Versuche, mit schicken, agilen Methoden wie Story Points oder Planing Poker zielführender vorhersagen zu wollen, wann ein Softwareprojekt abgeschlossen wird, bringen nichts wenig. Wir scheinen einfach nicht in der Lage, Hofstadters Gesetz (der Verzögerung) zu überwinden. 2. Mehr Mannstärke, mehr Verzug Stellt ein Manager einer Fabrik fest, dass die monatliche Quote für abgefüllte Zahnpastatuben in Gefahr ist, setzt er mehr Arbeiter ein, um die Vorgabe zu erfüllen. Ähnlich verhält es sich beim Hausbau: Wenn Sie doppelt so viele Häuser wie im Vorjahr bauen wollen, hilft es in der Regel, die Vorleistungen – Arbeit und Material – zu verdoppeln. Im Fall der Softwareentwicklung verhält sich das völlig anders, wie Frederick Brooks bereits 1975 in seinem Buch „Vom Mythos des Mann-Monats“ herausgearbeitet hat. Demnach hilft es wenig, verzögerte Softwareprojekte mit zusätzlicher Mannstärke retten zu wollen. Im Gegenteil: Gemäß dem Brooks’schen Gesetz verzögert das das Projekt nur noch zusätzlich. Schließlich können neu hinzukommende Teammitglieder nicht sofort zum Projekt beitragen. Sie benötigen Zeit, um sich in den Kontext komplexer Systeme einzuarbeiten, was oft auch zusätzliche Kommunikationsmaßnahmen nach sich zieht. Am Ende verzögert sich dann nicht nur alles noch weiter – es kostet auch mehr. 3. Mehr Skills, weniger Programmier-Tasks Als Softwareentwickler umfassende Expertise aufzubauen und sämtliche erforderlichen Regeln und Feinheiten zu verinnerlichen, um wartbaren, sauberen Code zu schreiben, nimmt etliche Jahre in Anspruch. Dabei erscheint es auch relativ paradox, dass die Programmieraufgaben mit steigender Erfahrung eher weniger werden: Statt zu programmieren, sitzen leitende Entwickler vor allem in Design-Meetings, überprüfen den Code anderer und übernehmen weitere Führungsaufgaben. Das heißt zwar nicht, dass Senior Developer einen kleineren Beitrag leisten. Schließlich sorgen sie in Führungspositionen dafür, dass zeitgemäß und zielführend gearbeitet wird und tragen so wesentlich zum Team- und Unternehmenserfolg bei. Aber am Ende schreiben sie dennoch weniger Code. 4. Bessere Tools, keine Zeitvorteile Vergleicht man die Webentwicklung von heute mit performanten Tools wie React, Astro und Next.js mit dem Gebaren von vor 30 Jahren (Stichwort Common Gateway Interface), wird klar, dass wir uns seitdem um Lichtjahre weiterentwickelt haben. Doch obwohl unsere Tools immer besser und die Prozessoren immer schneller werden, scheinen sich Softwareprojekte insgesamt nicht zu beschleunigen. Das wirft Fragen auf: Unsere Websites sehen zwar immer besser aus, aber sind wir wirklich produktiver? Laufen unsere Websites schneller und verarbeiten sie Daten besser? Natürlich abstrahieren die Frameworks und Bibliotheken von heute viele Komplexitäten. Sie führen aber auch zu neuen Problemen. Zum Beispiel langen Build-Pipelines, Konfigurationsalbträumen oder Abhängigkeitsproblemen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Die größten Paradoxa der Softwareentwicklung Paradoxe Erlebnisse sind für Softwareentwickler Alltag.Rosemarie Mosteller | shutterstock.com Vergleicht man den Bau von Brücken mit der Softwareentwicklung, zeigen sich bedeutende Unterschiede: Denn auch wenn keine Brücke – ähnlich wie ein Softwareprojekt – der anderen bis aufs „Haar“ gleicht, werden sie aus bekannten Materialien mit bekannten Eigenschaften geschaffen. Im Gegensatz dazu beinhaltet der Softwareentwicklungsprozess wesentlich mehr „unknown Unknowns“. Was dazu führt, dass er jede Menge Paradoxa beinhaltet, mit denen Developer teilweise nur schwer umgehen können. Wichtig ist aber vor allem, sich ihre Existenz bewusst zu machen – nur so lassen sich die daraus entstehenden Fallstricke umgehen. Insbesondere, wenn es dabei um die folgenden vier Paradoxa geht. 1. Ohne Plan, aber mit Deadline Zielführend einzuschätzen, wie lange ein Softwareprojekt dauern wird, ist wahrscheinlich die größte Herausforderung für Softwareentwickler überhaupt. Denn darüber lässt sich keine abschließende, verbindliche Aussage treffen. Sicher, man kann den ungefähren Aufwand schätzen – das geht im Regelfall allerdings daneben. Meistens wird der zeitliche Aufwand drastisch unterschätzt. Wird die gesetzte Deadline dann verpasst, ärgern sich vor allem die Kunden. Sie stecken nicht in der Haut der Devs und durchblicken die Abläufe und möglichen Hindernisse (im Regelfall) nicht. Also sind sie frustriert, weil ihre Software nicht zum vereinbarten Zeitpunkt ausgeliefert wird. Auch sämtliche Versuche, mit schicken, agilen Methoden wie Story Points oder Planing Poker zielführender vorhersagen zu wollen, wann ein Softwareprojekt abgeschlossen wird, bringen nichts wenig. Wir scheinen einfach nicht in der Lage, Hofstadters Gesetz (der Verzögerung) zu überwinden. 2. Mehr Mannstärke, mehr Verzug Stellt ein Manager einer Fabrik fest, dass die monatliche Quote für abgefüllte Zahnpastatuben in Gefahr ist, setzt er mehr Arbeiter ein, um die Vorgabe zu erfüllen. Ähnlich verhält es sich beim Hausbau: Wenn Sie doppelt so viele Häuser wie im Vorjahr bauen wollen, hilft es in der Regel, die Vorleistungen – Arbeit und Material – zu verdoppeln. Im Fall der Softwareentwicklung verhält sich das völlig anders, wie Frederick Brooks bereits 1975 in seinem Buch „Vom Mythos des Mann-Monats“ herausgearbeitet hat. Demnach hilft es wenig, verzögerte Softwareprojekte mit zusätzlicher Mannstärke retten zu wollen. Im Gegenteil: Gemäß dem Brooks’schen Gesetz verzögert das das Projekt nur noch zusätzlich. Schließlich können neu hinzukommende Teammitglieder nicht sofort zum Projekt beitragen. Sie benötigen Zeit, um sich in den Kontext komplexer Systeme einzuarbeiten, was oft auch zusätzliche Kommunikationsmaßnahmen nach sich zieht. Am Ende verzögert sich dann nicht nur alles noch weiter – es kostet auch mehr. 3. Mehr Skills, weniger Programmier-Tasks Als Softwareentwickler umfassende Expertise aufzubauen und sämtliche erforderlichen Regeln und Feinheiten zu verinnerlichen, um wartbaren, sauberen Code zu schreiben, nimmt etliche Jahre in Anspruch. Dabei erscheint es auch relativ paradox, dass die Programmieraufgaben mit steigender Erfahrung eher weniger werden: Statt zu programmieren, sitzen leitende Entwickler vor allem in Design-Meetings, überprüfen den Code anderer und übernehmen weitere Führungsaufgaben. Das heißt zwar nicht, dass Senior Developer einen kleineren Beitrag leisten. Schließlich sorgen sie in Führungspositionen dafür, dass zeitgemäß und zielführend gearbeitet wird und tragen so wesentlich zum Team- und Unternehmenserfolg bei. Aber am Ende schreiben sie dennoch weniger Code. 4. Bessere Tools, keine Zeitvorteile Vergleicht man die Webentwicklung von heute mit performanten Tools wie React, Astro und Next.js mit dem Gebaren von vor 30 Jahren (Stichwort Common Gateway Interface), wird klar, dass wir uns seitdem um Lichtjahre weiterentwickelt haben. Doch obwohl unsere Tools immer besser und die Prozessoren immer schneller werden, scheinen sich Softwareprojekte insgesamt nicht zu beschleunigen. Das wirft Fragen auf: Unsere Websites sehen zwar immer besser aus, aber sind wir wirklich produktiver? Laufen unsere Websites schneller und verarbeiten sie Daten besser? Natürlich abstrahieren die Frameworks und Bibliotheken von heute viele Komplexitäten. Sie führen aber auch zu neuen Problemen. Zum Beispiel langen Build-Pipelines, Konfigurationsalbträumen oder Abhängigkeitsproblemen. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!