Vor ein paar Tagen hat Dan North in seinem Blog geschrieben, dass Software Craftsmanship (Handwerk) zu sehr die Software selbst in den Fokus der Betrachtung stelle. Dabei ginge es doch um den Mehrwert, den die Software bringt.
Kunden interessieren sich in der Tat in erster Linie für den Nutzen der Software – insbesondere wenn sie selbst keine Erfahrung in der Softwareentwicklung haben. Dennoch gilt es – unter anderem durch eine gute Architektur – die Software zukunftssicher zu gestalten und nicht ausschließlich auf den kurzfristigen wirtschaftlichen Nutzen zu achten. Hier ist es die Aufgabe des Softwareentwicklers und -architekten, die Balance zwischen kurzfristigem Nutzen und Zukunftssicherheit der Software zu finden. Letztere führt zu einer langfristigen Wirtschaftlichkeit. Es lohnt sich also in den seltensten Fällen, die Software einfach nur „zurecht zu dengeln“. Auf der anderen Seite gilt: Die beste langfristige Wirtschaftlichkeit nützt nichts, wenn die Software aufgrund zu hoher initialer Kosten nicht entwickelt wird.
In jedem Fall ist die Softwareentwicklung selbst ein kreativer Prozess, der individuelle Produkte hervorbringt, wie z.B. auch der Hausbau – selbst bei Fertighäusern – zu individuellen Resultaten führt. Daher ist eine gewisse Analogie zum Handwerk nicht von der Hand zu weisen.
Die Analogie trägt jedoch nicht mehr, wenn es um Qualitätssicherung, Build- und Release-Management sowie Produktivstellung der Software geht. In diesen Bereichen kann mit Automatisierung sehr effizient und kostengünstig gearbeitet werden, da es sich um wiederkehrende und wenig kreative Tätigkeiten handelt. Hier trägt also eher die Analogie zur Industrie.
Konzepte wie Testautomatisierung, Continuous Integration, automatisierte Buildprozesse oder Produktivstellung auf Knopfdruck erlauben, Kosten und Zeit zu sparen. Entwickler haben so mehr Zeit für ihre eigentliche Arbeit: Entwickeln von Software. Ganz nebenbei verkürzt sich die Zeit vom fertigen Quellcode bis zur produktiven Software. Hierfür braucht es die passenden Technologien und Produkte, aber vor allem ein durchgängiges Gesamtkonzept.
Softwareentwicklung lässt sich meiner Meinung nach nicht eindeutig dem Handwerk oder der Industrie zuordnen. Es gilt, in allen Teilbereichen den richtigen Ansatz zu finden, um ein optimales Endprodukt zu erzeugen.
Stimme voll und ganz überein: Im Endeffekt kann man sich sowohl von der automatisierten Fertigung als auch von guter handwerklicher Arbeit so einiges für die Softwareentwicklung lernen (was ja z. T. auch schon passiert ist). Ob nun die eine oder die andere Analogie besser passt ist eine in meinen Augen ziemlich uninteressante Diskussion.
Oder wie Martin Fowler so schön sagt:
„I’m fundamentally uninterested in whether software development is a craft, an art, a trade, or a dessert topping.“
:D