Die Softwareentwicklung - wie sie Heute ist - hat sich im Grunde schon lange nicht mehr verändert. Nach wie vor wird ein Texteditor (oder eben eine bunte IDE) benutzt, um stundenlang Code hinein zu hacken. Von der prozeduralen Art und Weise gab es den Sprung zur objektorientierten Programmierung, den jedoch immer noch viele Entwickler nicht mitgegangen sind. Immer noch werden zahlreiche Anwendungen in Sprachen á la Visual Basic 6 und Co. verfasst. Aber auch die objektorientierte Programmierung ist nicht das Gelbe vom Ei. Ursprünglich davon ausgegangen, dass man mit OOP alle realen "Objekte" abbilden kann, stellt man fest, dass dies in manchen Fällen dann doch nicht so einfach (wenn überhaupt) möglich ist. Probleme aus der Steinzeit der Entwicklung kehren immer wieder zurück und Entwickler müssen sich die selben Gedanken machen wie vor 20 Jahren.
Zahlreiche neue Frameworks tummeln sich und versprechen Leistungsvorteile, schnelleres Entwickeln. Altes wird neu verpackt (Beispiel AJAX) und auf den Markt gebracht. Die Entwicklungszeiten werden dadurch meist nicht verkürzt. Patterns hier, Application Blocks dort, einfache oder komplizierte Template-Techniken (siehe Visual Studio 2005) und weitere lustige Spielerein. Kaum jemand kann sich wirklich ausschlieÃlich auf seine Businesslogik konzentrieren. Immer noch muss der meiste Code per Hand eingegeben werden. Für alltägliche Funktionalitäten - was eigentlich nicht sein müsste.
Techniken wie aspektorientierte Programmierung, agile Softwareentwicklung, Extreme Programming versprechen Leistungssteigerungen und Qualitätsverbesserungen. Fakt ist, dass die Softwareentwicklung immer noch zu lange dauert, zu teuer ist und jeder sein Auto sofort verschrotten lassen würde, würde die Qualität der der Softwareentwicklung entsprechen.
Aber woran liegt das? Zum einen liegt es mitunter am Softwareentwickler selbst. In kaum einen Unternehmen wird qualitativ hochwertige Software entwickelt. Dabei gibt es zahlreiche Hilfsmittel, die hier eine eindeutige Verbesserung verschaffen: Unit Testing, Code Coverage usw. Vielfach wird der Grund hierfür in der zusätzlich notwendigen Zeit gesehen. Dass die für beispielsweise Unit Testing aufgewendete Zeit, jedoch vielfach wieder eingespart wird (die Amortisationszeit im Fehlerfalle ist sehr gering), wird von der Hand gewiesen. Weiters sehe ich Gründe darin, dass viele Entwickler lieber die Techniken verwenden, die sie bereits jahrelang anwenden und somit absolut den neuen Techniken hinterher programmieren. Anstatt sich komplette Bestandteile der Software durch entsprechende Tools automatisch generieren zu lassen, wird weiterhin jede einzelne Zeile Code per Hand erfasst.
Was jedoch auch fehlt, sind notwendige Tools um die Entwicklungszeit zu verkürzen. Immer wieder hört man von diversen Projekten, die sich dessen annehmen, wirklich gute Produkte sind mir jedoch bis dato noch nicht vor die FüÃe gefallen. Langsam aber sicher bewegt sich jedoch die Softwareentwicklung in die einzig richtige Richtung: Paradigmenwechsel.
Was versteht man unter einem Paradigmenwechsel? Ein Paradigma stellt dar, wie eine bestimmte Angelegenheit erledigt wird. Lange Zeit war es beispielsweise ein Paradigma, Consolen-Anwendungen zu schreiben, bis es dann die ersten grafischen Oberflächen gab und man erkannte, dass dies die Anwendung erleichtert und somit einen Mehrwert bietet. Ein Paradigmenwechsel findet dann statt, wenn sich zum aktuellen Paradigma Anomalien ergeben. Dies sind Missstände, die sich nicht lösen lassen und daher eine Erneuerung geschehen muss. Ein Paradigmenwechsel bringt also Neuerung und meist auch Verbesserung.
In der heutigen Softwareentwicklung ergeben sich einige Anomalien. Darunter finden sich - wie bereits oben angesprochen - eine Menge "groÃer" Punkte (Kosten, Zeit, Qualität). Hier muss angesetzt werden und wird es teilweise auch. Bis entsprechende Produkte auf den Markt kommen wird durchaus noch Zeit vergehen, aber im Kleinen sollte jeder daran arbeiten, sich selbst und vor allem seine Produkte zu verbessern und zu optimieren.
Previous Topic
