Weil wir Softwarebugs so schnell nicht loswerden, ist wenigstens das Symbolbild hübsch.atartusi / Shutterstock Physische Produkte zu produzieren, ist meist ein geordneter, wiederholbarer und unter Umständen sogar perfektionierbarer Prozess. Software zu entwickeln, ist hingegen etwas völlig anderes: Jedes Projekt ist – unabhängig von seinem Umfang – einzigartig und wird erstmalig umgesetzt. Wie dabei der optimale Weg zum Ziel aussieht, daran scheiden sich die Geister. Möglicherweise gibt es mit Blick auf die Softwareentwicklung überhaupt keinen „besten Weg“ – der „unknown Unknowns“ sei Dank. Die Kristallkugel im schwarzen Loch Das erschwert es erheblich, einzuschätzen, wie lange ein Softwareprojekt dauern wird. Selbst nach Jahren hat dafür bislang niemand eine zuverlässige Methode gefunden. Und dazu wird es meiner Meinung nach auch nicht mehr kommen. Auch wenn diverse Softwareanbieter vollmundig versprechen, dieses Problem längst gelöst zu haben – sie lügen. Natürlich ist das nichts, was CEOs gerne hören. Einem Kunden zu vermitteln, dass weder feststeht, wann seine Software genau fertig ist, noch, wie oder ob sie funktioniert, ist kein gangbarer Weg. Das wäre zwar im Grunde nur ehrlich – in den meisten Unternehmen traut man sich aber nicht einmal, sich diese Wahrheit selbst einzugestehen. Oder ignoriert sie geflissentlich. Das führt zwangsläufig zu Spannungen zwischen denjenigen, die neue Software und ihre Funktionen entwickeln – und denjenigen, die sie verkaufen wollen. Weil Software formbar ist, treffen viele Kunden ihre Kaufentscheidungen oft auf der Grundlage künftiger Features – den nächsten großen Trend stets im Blick. Das wiederum veranlasst die Verkäufer, mit Funktionen zu werben, die noch gar nicht existieren. Die Kunden wollen selbstverständlich wissen, wann diese verfügbar sein werden – was die Verkäufer dann dazu verleitet, Versprechen abzugeben, die sich nur schwer, respektive nicht, halten lassen. Die Entwickler würden den Business- und Sales-Menschen nur allzu gerne genau sagen, wann die Software oder bestimmte Funktionen ausgeliefert werden. Aber sie können im besten Fall auch nur Vermutungen dazu abgeben. Dennoch lassen sich viele Devs in so einem Setting unter Druck setzen und fühlen sich genötigt, eine konkrete Deadline in den Raum zu werfen. Zwar wird in der Regel viel Aufwand betrieben, um diese vorab zu „ermitteln“. Leider liegen diese Schätzungen aber fast durch die Bank daneben. Der Kompromiss, der keiner ist Um Schlamassel dieser Art zu bewältigen, könnten Softwareentwickler – und ihre Manager – an mehreren Stellschrauben drehen: Alle könnten mehr arbeiten. Allerdings würde das den Druck auf das Dev-Team erhöhen – und damit die Wahrscheinlichkeit, dass Abkürzungen genommen und Fehler gemacht werden. Statt einer pünktlichen Delivery, winken dann meist nur wachsende, technische Schulden. Führungskräfte könnten auch versuchen, mehr Menschen einzustellen, um die geleisteten Arbeitsstunden zu erhöhen. Dann greift allerdings das Brooks`sche Gesetz – und alles wird nur noch schlimmer. Der Funktionsumfang der Software zur Delivery könnte reduziert werden. Das dürfte den Kunden nicht gefallen. Die Qualität könnte heruntergeschraubt werden – etwa durch minimiertes Bugfixing und weniger Aufwand für das User Interface. Die Endbenutzer werden das nicht zu schätzen wissen. Der Zeitplan ließe sich verschieben. Das führt allerdings wieder dazu, dass die zahlenden Kunden vor den Kopf gestoßen werden. In der Praxis führen diese Auswahlmöglichkeiten in der Regel dazu, dass die Qualität auf der Strecke bleibt. Auf fehlerbehaftete Applikationen legt zwar auch niemand wirklich Wert, aber immerhin lassen sich qualitative Mängel ganz gut hinter scheinbar funktionsfähigen Features verstecken. Aus Kundenperspektive ist es inzwischen bereits üblich, eine solche „funktionierende“ Software zu erhalten. Nur um anschließend nach und nach den qualitativen Verfehlungen auf die Schliche zu kommen. Diese werden dann vom Entwicklungsteam mit einem „Point Release“ behoben. Im Grunde ist dieses Vorgehen also nur eine raffiniertere Methode, den Zeitplan anzupassen – indem das Bugfixing auf die Zeit nach der Delivery verschoben wird. Es ist nicht damit zu rechnen, dass dieses Gebaren auf absehbare Zeit abgestellt wird. Software wird also weiterhin Bugs aufweisen – und der schwarze Peter bei den Entwicklern und/oder den QA-Experten landen. (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!
Darum ist Software verbuggt
Weil wir Softwarebugs so schnell nicht loswerden, ist wenigstens das Symbolbild hübsch.atartusi / Shutterstock Physische Produkte zu produzieren, ist meist ein geordneter, wiederholbarer und unter Umständen sogar perfektionierbarer Prozess. Software zu entwickeln, ist hingegen etwas völlig anderes: Jedes Projekt ist – unabhängig von seinem Umfang – einzigartig und wird erstmalig umgesetzt. Wie dabei der optimale Weg zum Ziel aussieht, daran scheiden sich die Geister. Möglicherweise gibt es mit Blick auf die Softwareentwicklung überhaupt keinen „besten Weg“ – der „unknown Unknowns“ sei Dank. Die Kristallkugel im schwarzen Loch Das erschwert es erheblich, einzuschätzen, wie lange ein Softwareprojekt dauern wird. Selbst nach Jahren hat dafür bislang niemand eine zuverlässige Methode gefunden. Und dazu wird es meiner Meinung nach auch nicht mehr kommen. Auch wenn diverse Softwareanbieter vollmundig versprechen, dieses Problem längst gelöst zu haben – sie lügen. Natürlich ist das nichts, was CEOs gerne hören. Einem Kunden zu vermitteln, dass weder feststeht, wann seine Software genau fertig ist, noch, wie oder ob sie funktioniert, ist kein gangbarer Weg. Das wäre zwar im Grunde nur ehrlich – in den meisten Unternehmen traut man sich aber nicht einmal, sich diese Wahrheit selbst einzugestehen. Oder ignoriert sie geflissentlich. Das führt zwangsläufig zu Spannungen zwischen denjenigen, die neue Software und ihre Funktionen entwickeln – und denjenigen, die sie verkaufen wollen. Weil Software formbar ist, treffen viele Kunden ihre Kaufentscheidungen oft auf der Grundlage künftiger Features – den nächsten großen Trend stets im Blick. Das wiederum veranlasst die Verkäufer, mit Funktionen zu werben, die noch gar nicht existieren. Die Kunden wollen selbstverständlich wissen, wann diese verfügbar sein werden – was die Verkäufer dann dazu verleitet, Versprechen abzugeben, die sich nur schwer, respektive nicht, halten lassen. Die Entwickler würden den Business- und Sales-Menschen nur allzu gerne genau sagen, wann die Software oder bestimmte Funktionen ausgeliefert werden. Aber sie können im besten Fall auch nur Vermutungen dazu abgeben. Dennoch lassen sich viele Devs in so einem Setting unter Druck setzen und fühlen sich genötigt, eine konkrete Deadline in den Raum zu werfen. Zwar wird in der Regel viel Aufwand betrieben, um diese vorab zu „ermitteln“. Leider liegen diese Schätzungen aber fast durch die Bank daneben. Der Kompromiss, der keiner ist Um Schlamassel dieser Art zu bewältigen, könnten Softwareentwickler – und ihre Manager – an mehreren Stellschrauben drehen: Alle könnten mehr arbeiten. Allerdings würde das den Druck auf das Dev-Team erhöhen – und damit die Wahrscheinlichkeit, dass Abkürzungen genommen und Fehler gemacht werden. Statt einer pünktlichen Delivery, winken dann meist nur wachsende, technische Schulden. Führungskräfte könnten auch versuchen, mehr Menschen einzustellen, um die geleisteten Arbeitsstunden zu erhöhen. Dann greift allerdings das Brooks`sche Gesetz – und alles wird nur noch schlimmer. Der Funktionsumfang der Software zur Delivery könnte reduziert werden. Das dürfte den Kunden nicht gefallen. Die Qualität könnte heruntergeschraubt werden – etwa durch minimiertes Bugfixing und weniger Aufwand für das User Interface. Die Endbenutzer werden das nicht zu schätzen wissen. Der Zeitplan ließe sich verschieben. Das führt allerdings wieder dazu, dass die zahlenden Kunden vor den Kopf gestoßen werden. In der Praxis führen diese Auswahlmöglichkeiten in der Regel dazu, dass die Qualität auf der Strecke bleibt. Auf fehlerbehaftete Applikationen legt zwar auch niemand wirklich Wert, aber immerhin lassen sich qualitative Mängel ganz gut hinter scheinbar funktionsfähigen Features verstecken. Aus Kundenperspektive ist es inzwischen bereits üblich, eine solche „funktionierende“ Software zu erhalten. Nur um anschließend nach und nach den qualitativen Verfehlungen auf die Schliche zu kommen. Diese werden dann vom Entwicklungsteam mit einem „Point Release“ behoben. Im Grunde ist dieses Vorgehen also nur eine raffiniertere Methode, den Zeitplan anzupassen – indem das Bugfixing auf die Zeit nach der Delivery verschoben wird. Es ist nicht damit zu rechnen, dass dieses Gebaren auf absehbare Zeit abgestellt wird. Software wird also weiterhin Bugs aufweisen – und der schwarze Peter bei den Entwicklern und/oder den QA-Experten landen. (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!
Darum ist Software verbuggt Weil wir Softwarebugs so schnell nicht loswerden, ist wenigstens das Symbolbild hübsch.atartusi / Shutterstock Physische Produkte zu produzieren, ist meist ein geordneter, wiederholbarer und unter Umständen sogar perfektionierbarer Prozess. Software zu entwickeln, ist hingegen etwas völlig anderes: Jedes Projekt ist – unabhängig von seinem Umfang – einzigartig und wird erstmalig umgesetzt. Wie dabei der optimale Weg zum Ziel aussieht, daran scheiden sich die Geister. Möglicherweise gibt es mit Blick auf die Softwareentwicklung überhaupt keinen „besten Weg“ – der „unknown Unknowns“ sei Dank. Die Kristallkugel im schwarzen Loch Das erschwert es erheblich, einzuschätzen, wie lange ein Softwareprojekt dauern wird. Selbst nach Jahren hat dafür bislang niemand eine zuverlässige Methode gefunden. Und dazu wird es meiner Meinung nach auch nicht mehr kommen. Auch wenn diverse Softwareanbieter vollmundig versprechen, dieses Problem längst gelöst zu haben – sie lügen. Natürlich ist das nichts, was CEOs gerne hören. Einem Kunden zu vermitteln, dass weder feststeht, wann seine Software genau fertig ist, noch, wie oder ob sie funktioniert, ist kein gangbarer Weg. Das wäre zwar im Grunde nur ehrlich – in den meisten Unternehmen traut man sich aber nicht einmal, sich diese Wahrheit selbst einzugestehen. Oder ignoriert sie geflissentlich. Das führt zwangsläufig zu Spannungen zwischen denjenigen, die neue Software und ihre Funktionen entwickeln – und denjenigen, die sie verkaufen wollen. Weil Software formbar ist, treffen viele Kunden ihre Kaufentscheidungen oft auf der Grundlage künftiger Features – den nächsten großen Trend stets im Blick. Das wiederum veranlasst die Verkäufer, mit Funktionen zu werben, die noch gar nicht existieren. Die Kunden wollen selbstverständlich wissen, wann diese verfügbar sein werden – was die Verkäufer dann dazu verleitet, Versprechen abzugeben, die sich nur schwer, respektive nicht, halten lassen. Die Entwickler würden den Business- und Sales-Menschen nur allzu gerne genau sagen, wann die Software oder bestimmte Funktionen ausgeliefert werden. Aber sie können im besten Fall auch nur Vermutungen dazu abgeben. Dennoch lassen sich viele Devs in so einem Setting unter Druck setzen und fühlen sich genötigt, eine konkrete Deadline in den Raum zu werfen. Zwar wird in der Regel viel Aufwand betrieben, um diese vorab zu „ermitteln“. Leider liegen diese Schätzungen aber fast durch die Bank daneben. Der Kompromiss, der keiner ist Um Schlamassel dieser Art zu bewältigen, könnten Softwareentwickler – und ihre Manager – an mehreren Stellschrauben drehen: Alle könnten mehr arbeiten. Allerdings würde das den Druck auf das Dev-Team erhöhen – und damit die Wahrscheinlichkeit, dass Abkürzungen genommen und Fehler gemacht werden. Statt einer pünktlichen Delivery, winken dann meist nur wachsende, technische Schulden. Führungskräfte könnten auch versuchen, mehr Menschen einzustellen, um die geleisteten Arbeitsstunden zu erhöhen. Dann greift allerdings das Brooks`sche Gesetz – und alles wird nur noch schlimmer. Der Funktionsumfang der Software zur Delivery könnte reduziert werden. Das dürfte den Kunden nicht gefallen. Die Qualität könnte heruntergeschraubt werden – etwa durch minimiertes Bugfixing und weniger Aufwand für das User Interface. Die Endbenutzer werden das nicht zu schätzen wissen. Der Zeitplan ließe sich verschieben. Das führt allerdings wieder dazu, dass die zahlenden Kunden vor den Kopf gestoßen werden. In der Praxis führen diese Auswahlmöglichkeiten in der Regel dazu, dass die Qualität auf der Strecke bleibt. Auf fehlerbehaftete Applikationen legt zwar auch niemand wirklich Wert, aber immerhin lassen sich qualitative Mängel ganz gut hinter scheinbar funktionsfähigen Features verstecken. Aus Kundenperspektive ist es inzwischen bereits üblich, eine solche „funktionierende“ Software zu erhalten. Nur um anschließend nach und nach den qualitativen Verfehlungen auf die Schliche zu kommen. Diese werden dann vom Entwicklungsteam mit einem „Point Release“ behoben. Im Grunde ist dieses Vorgehen also nur eine raffiniertere Methode, den Zeitplan anzupassen – indem das Bugfixing auf die Zeit nach der Delivery verschoben wird. Es ist nicht damit zu rechnen, dass dieses Gebaren auf absehbare Zeit abgestellt wird. Software wird also weiterhin Bugs aufweisen – und der schwarze Peter bei den Entwicklern und/oder den QA-Experten landen. (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!
