Wer sich zu schnell festlegt, verpasst möglicherweise etwas Besseres.fran_kie / Shutterstock Manchmal geschehen aus dem Nichts Dinge, die einem die Augen öffnen. Letzte Woche zum Beispiel ist mir – einfach so – aufgefallen, dass wirklich gutes Softwaredesign davon lebt, sich so lange wie möglich alle Optionen offenzuhalten – und sämtliche Entscheidungen bis zur letzten Minute aufzuschieben. Das liest sich für die meisten Entwickler allerdings eher nach No-Go. Ein Softwareprojekt anzugehen, ohne über jedes erdenkliche Detail sinniert zu haben, ist für nicht wenige Devs ein absolut unerträglicher Gedanke. Was, wenn es zu Überraschungen kommt? Dass Welten aufeinanderprallen, wenn sich diese beiden Philosophien im Arbeitsalltag begegnen, ist abzusehen: Engineering Director: „Wie läuft die Planung für’s neue Projekt?“ Development Lead: „Super, wir sind ready.“ Engineering Director: „Welche Datenbank nutzen wir?“ Development Lead: „Schauen wir noch.“ Engineering Director: „Wie sieht’s mit Authentifizierung aus?“ Development Lead: „Same.“ Engineering Director: „🤯?“ Dabei sollte der technische Leiter diese Antworten eigentlich begrüßen. In Abstraktionen denken Denn sich frühzeitig auf etwas festzulegen, führt zu Lock-In-Situationen: Wer sich zum Projektstart für eine relationale Datenbank entscheidet, dann aber im Laufe des Projekts merkt, dass eine NoSQL-Datenbank die bessere Option wäre, hat ein Problem. So kommt es, dass Lösungen über die Implementierung bestimmen und Abstraktionen in weite Ferne rücken. Das ist meiner Meinung nach der falsche Weg: Stattdessen sollten sich Entwickler fragen, welche Abstraktionen sie für ihre Lösungen benötigen. Wenn man in Abstraktionen denkt, lassen sich Implementierungsentscheidungen aufschieben – und das sollte man sogar tun. Denn je länger diese Entscheidung aufgeschoben wird, umso unwahrscheinlicher ist es, dass Entwickler dadurch eingeschränkt oder in eine bestimmte Richtung gedrängt werden. Deshalb sollte das Ziel sein, sich (erst einmal) nicht darum zu kümmern, welche Datenbank oder Authentifizierungslösung zum Einsatz kommt. Letztendlich ist es wesentlich einfacher und effektiver, Implementierungen an Abstraktionen anzupassen als umgekehrt. Das trägt darüber hinaus auch wesentlich dazu bei, eines der größten „Schreckgespenster“ der Softwareentwicklung zu vertreiben – die unbekannte Unbekannte: Solange Sie nicht auf eine Implementierung festgelegt sind, können Sie sich flexibel an sämtliche unvorhergesehenen Hürden anpassen, die im Verlauf der Entwicklungsarbeit auftauchen. Es geht dabei jedoch nicht darum, Entscheidungen zu meiden. Vielmehr gilt es, sie zum richtigen Zeitpunkt und mit den richtigen Informationen zu treffen. Je länger Sie Grundlagenentscheidungen zur Implementierung aufschieben, desto sauberer und entkoppelter wird Ihre Lösung ausfallen – und entsprechend flexibel und einfach zu warten sein. (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!
Hier lohnt sich Aufschieberitis
Wer sich zu schnell festlegt, verpasst möglicherweise etwas Besseres.fran_kie / Shutterstock Manchmal geschehen aus dem Nichts Dinge, die einem die Augen öffnen. Letzte Woche zum Beispiel ist mir – einfach so – aufgefallen, dass wirklich gutes Softwaredesign davon lebt, sich so lange wie möglich alle Optionen offenzuhalten – und sämtliche Entscheidungen bis zur letzten Minute aufzuschieben. Das liest sich für die meisten Entwickler allerdings eher nach No-Go. Ein Softwareprojekt anzugehen, ohne über jedes erdenkliche Detail sinniert zu haben, ist für nicht wenige Devs ein absolut unerträglicher Gedanke. Was, wenn es zu Überraschungen kommt? Dass Welten aufeinanderprallen, wenn sich diese beiden Philosophien im Arbeitsalltag begegnen, ist abzusehen: Engineering Director: „Wie läuft die Planung für’s neue Projekt?“ Development Lead: „Super, wir sind ready.“ Engineering Director: „Welche Datenbank nutzen wir?“ Development Lead: „Schauen wir noch.“ Engineering Director: „Wie sieht’s mit Authentifizierung aus?“ Development Lead: „Same.“ Engineering Director: „🤯?“ Dabei sollte der technische Leiter diese Antworten eigentlich begrüßen. In Abstraktionen denken Denn sich frühzeitig auf etwas festzulegen, führt zu Lock-In-Situationen: Wer sich zum Projektstart für eine relationale Datenbank entscheidet, dann aber im Laufe des Projekts merkt, dass eine NoSQL-Datenbank die bessere Option wäre, hat ein Problem. So kommt es, dass Lösungen über die Implementierung bestimmen und Abstraktionen in weite Ferne rücken. Das ist meiner Meinung nach der falsche Weg: Stattdessen sollten sich Entwickler fragen, welche Abstraktionen sie für ihre Lösungen benötigen. Wenn man in Abstraktionen denkt, lassen sich Implementierungsentscheidungen aufschieben – und das sollte man sogar tun. Denn je länger diese Entscheidung aufgeschoben wird, umso unwahrscheinlicher ist es, dass Entwickler dadurch eingeschränkt oder in eine bestimmte Richtung gedrängt werden. Deshalb sollte das Ziel sein, sich (erst einmal) nicht darum zu kümmern, welche Datenbank oder Authentifizierungslösung zum Einsatz kommt. Letztendlich ist es wesentlich einfacher und effektiver, Implementierungen an Abstraktionen anzupassen als umgekehrt. Das trägt darüber hinaus auch wesentlich dazu bei, eines der größten „Schreckgespenster“ der Softwareentwicklung zu vertreiben – die unbekannte Unbekannte: Solange Sie nicht auf eine Implementierung festgelegt sind, können Sie sich flexibel an sämtliche unvorhergesehenen Hürden anpassen, die im Verlauf der Entwicklungsarbeit auftauchen. Es geht dabei jedoch nicht darum, Entscheidungen zu meiden. Vielmehr gilt es, sie zum richtigen Zeitpunkt und mit den richtigen Informationen zu treffen. Je länger Sie Grundlagenentscheidungen zur Implementierung aufschieben, desto sauberer und entkoppelter wird Ihre Lösung ausfallen – und entsprechend flexibel und einfach zu warten sein. (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!
Hier lohnt sich Aufschieberitis Wer sich zu schnell festlegt, verpasst möglicherweise etwas Besseres.fran_kie / Shutterstock Manchmal geschehen aus dem Nichts Dinge, die einem die Augen öffnen. Letzte Woche zum Beispiel ist mir – einfach so – aufgefallen, dass wirklich gutes Softwaredesign davon lebt, sich so lange wie möglich alle Optionen offenzuhalten – und sämtliche Entscheidungen bis zur letzten Minute aufzuschieben. Das liest sich für die meisten Entwickler allerdings eher nach No-Go. Ein Softwareprojekt anzugehen, ohne über jedes erdenkliche Detail sinniert zu haben, ist für nicht wenige Devs ein absolut unerträglicher Gedanke. Was, wenn es zu Überraschungen kommt? Dass Welten aufeinanderprallen, wenn sich diese beiden Philosophien im Arbeitsalltag begegnen, ist abzusehen: Engineering Director: „Wie läuft die Planung für’s neue Projekt?“ Development Lead: „Super, wir sind ready.“ Engineering Director: „Welche Datenbank nutzen wir?“ Development Lead: „Schauen wir noch.“ Engineering Director: „Wie sieht’s mit Authentifizierung aus?“ Development Lead: „Same.“ Engineering Director: „🤯?“ Dabei sollte der technische Leiter diese Antworten eigentlich begrüßen. In Abstraktionen denken Denn sich frühzeitig auf etwas festzulegen, führt zu Lock-In-Situationen: Wer sich zum Projektstart für eine relationale Datenbank entscheidet, dann aber im Laufe des Projekts merkt, dass eine NoSQL-Datenbank die bessere Option wäre, hat ein Problem. So kommt es, dass Lösungen über die Implementierung bestimmen und Abstraktionen in weite Ferne rücken. Das ist meiner Meinung nach der falsche Weg: Stattdessen sollten sich Entwickler fragen, welche Abstraktionen sie für ihre Lösungen benötigen. Wenn man in Abstraktionen denkt, lassen sich Implementierungsentscheidungen aufschieben – und das sollte man sogar tun. Denn je länger diese Entscheidung aufgeschoben wird, umso unwahrscheinlicher ist es, dass Entwickler dadurch eingeschränkt oder in eine bestimmte Richtung gedrängt werden. Deshalb sollte das Ziel sein, sich (erst einmal) nicht darum zu kümmern, welche Datenbank oder Authentifizierungslösung zum Einsatz kommt. Letztendlich ist es wesentlich einfacher und effektiver, Implementierungen an Abstraktionen anzupassen als umgekehrt. Das trägt darüber hinaus auch wesentlich dazu bei, eines der größten „Schreckgespenster“ der Softwareentwicklung zu vertreiben – die unbekannte Unbekannte: Solange Sie nicht auf eine Implementierung festgelegt sind, können Sie sich flexibel an sämtliche unvorhergesehenen Hürden anpassen, die im Verlauf der Entwicklungsarbeit auftauchen. Es geht dabei jedoch nicht darum, Entscheidungen zu meiden. Vielmehr gilt es, sie zum richtigen Zeitpunkt und mit den richtigen Informationen zu treffen. Je länger Sie Grundlagenentscheidungen zur Implementierung aufschieben, desto sauberer und entkoppelter wird Ihre Lösung ausfallen – und entsprechend flexibel und einfach zu warten sein. (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!