Wenn diese Nachricht nicht korrekt angezeigt wird, klicken Sie bitte hier.
Kurz und prägnant: Praxis-relevante Themen für IT-Manager und Java-Experten.
Sehr geehrte Leserin, sehr geehrter Leser,
in der aktuellen Ausgabe unseres Newsletters bieten wir Ihnen wieder interessante Denkanstöße unser expeso-Eperten. Heute haben wir den Schwerpunkt im Themenbereich agile Software-Entwicklung.
Oft hört man in der Software-Entwicklung die Aussage "wir entwickeln agil". Wenn man genauer hinschaut, erkennt man, dass hinter dieser Aussage die unterschiedlichsten Wahrheiten verborgen sind. Es werden einzelne Aspekte der agilen Prinzipien überbetont, andere werden vernachlässigt. Hier hilft nur eine stetige Weiterentwicklung des eigenen agilen Entwicklungsprozesses, sich immer weiter dem Idealbild der agilen Software-Entwicklung anzunähern. Ulf Krum beleuchtet daher exemplarisch ein Prinzip der agilen Software-Entwicklung im ersten Artikel Sind wir Agil?.
Heiko Seebach ist einer der Gründer der LessCode-Initiative. Diese Initiative hat sich die Vereinfachung von Software-Systemen auf die Fahne geschrieben. Im Artikel Mensch vor Maschine stellt er uns eines der Prinzipien der LessCode-Initiative vor und plädiert für Optimierung mit gesundem Menschenverstand.
Wir freuen uns über Ihre Rückmeldung und Ihre Erfahrungen.
Herzliche Grüße
Markus Roth
expeso GmbH - Experten für erfolgreiche Software-Projekte
Sind wir Agil?
Kent Beck, Ward Cunningham, Martin Fowler und weitere IT-Größen haben 2001 wesentliche Aspekte agiler Software-Entwicklung definiert. Das Ergebnis waren zwölf Prinzipien, das "Agile Manifest" (http://agilemanifesto.org/).
Agile Software-Entwicklung und agiles Projekt-Management sind moderne und erfolgreiche Methoden. Halten Sie einen Moment inne. Lesen Sie die zwölf Prinzipien in Ruhe durch und fragen Sie sich: „Entwickeln wir wirklich auf diese Weise Software?“
Exemplarisch möchte ich ein Prinzip heraus greifen:
„The best architectures, requirements, and designs emerge from self-organizing teams.“
Die besten Problemlösungen resultieren aus der Summe der beteiligten Köpfe. Wenn Sie nur Problemlösungen als fertige Arbeitspakete an Ihre Entwickler weiter geben, werden Sie also nie die beste Lösung erhalten. Beteiligen Sie dagegen das Team am Lösungsprozess, erhalten Sie einen beträchtlichen Mehrwert!
Zur Selbstorganisation eines Teams gehört auch die Aufwandsschätzung. Ein selbst gesetztes Ziel zu erreichen, motiviert Entwicklerteams ungemein. Das Inverse Scotty-Prinzip halte ich für kontraproduktiv: Der Manager verhandelt mit dem Kunden sechs Wochen, gibt dem Entwickler aber nur drei. Hier fühlt sich jeder Entwickler hintergangen.
Durch das Team geschätzte Aufwände sollten dementsprechend auch akzeptiert werden. Jede Aufwandsschätzung muss später dann mit dem tatsächlich benötigten Aufwand verglichen werden. Ohne diese Rückkoppelung und Anpassung des Workloads an die Leistungsfähigkeit des Teams ist jede Schätzung wertlos und gefährlich: Der Manager lügt sich seine optimale Welt in die Tasche. Risikomanagement wird unmöglich.
An diesen zwei Beispielen sieht man, dass „Agile“ heute eine komplette Umkehr zu alten, klassischen Methoden darstellt. Gerade agile Methoden erfordern Mut und Disziplin in der Umsetzung. Insbesondere vom Management. Ein Code-and-Fix-Ansatz, sowie wenig bis keine Dokumentation anzufertigen, hat hingegen nichts mit agiler Software-Entwicklung zu tun.
Software-Entwicklung heißt heute, ein gemeinsames Ziel zu erreichen. Mit allen Beteiligten: Kunden, Entwicklern und Management.
Quellen:
http://agilemanifesto.org/ Manifesto for Agile Software Development
http://www.ambysoft.com/essays/agileManifesto.html
LessCode ist eine vor kurzem gegründete Initiative zur Vereinfachung von Softwaresystemen und zur Förderungen von agilen Technologien. LessCode.de dient dabei sowohl als Kommunikationsplattform für Interessierte und als Sammlung von Prinzipien, die zeigen, wie man mit weniger Code mehr erreichen kann. Über mehrere Ausgaben des expeso-Newsletters sollen einige dieser Prinzipien vorgestellt werden.
Prinzip "Mensch vor Maschine"
Dieses Prinzip besagt, dass Programmcode in der Regel so geschrieben werden soll, dass er in erster Linie für Menschen gut lesbar ist.
Es ist zwischen zwei Kategorien von falschem Eifer zu unterscheiden:
Zu frühe Resourcen-Optimierung
Erst nachdem sich in der Praxis die wirklich optimierungsbedürftigen Stellen (Hotspots) zeigen, werden diese Stück für Stück optimiert; aber auch hier eher zaghaft als voller Tatendrang.
Wenn ein Entwickler im “Flow” ist, sich völlig eins fühlt mit dem fachlichen Problem, die technische Umgebung komplett verstanden und unter Kontrolle hat, dann ist nicht selten zu beobachten, dass hervorragender, “genialer” Code entsteht: Code, der besonders performant und Resourcen-schonend funktioniert und das letzte Quäntchen aus der Maschine herauskitzelt. Es wird massiv gecached, externe Bibliotheken gepatcht, mit dem Interpreter/Compiler getrickst, auf eine spezielle Zielplattform optimiert, SQL-Hints eingebaut, …
Aber irgendwann folgt die Ernüchterung: Einerseits ist dieser Code bei weitem nicht so Performance-relevant wie anfangs gedacht, andererseits versteht ihn kaum noch jemand. Eine fachliche Änderung bereitet nun viel mehr Aufwand als wenn der Code einfach nur so geschrieben worden wäre wie es sich der Otto Normalentwickler vorstellt, dass er ablaufen müsste.
Der LessCoder hakt den Task früher ab. Dafür hat er später die Zeit übrig, wenn die Praxis zeigt, dass es auch wirklich notwendig ist, sich um dessen Optimierung zu kümmern.
Nicht an dem Anwender orientiertes API-Design
Insbesondere beim Design von APIs wird gerne vergessen, dass die Zeit der Entwickler, die sich mit der API später beschäftigen müssen/dürfen, meist das wertvollere Gut ist, als einige weitere vom API-Designer entwickelte Komfort-Funktionen.
Die beste API ist, wenn ein Zugriff mit relativ einfachen, aber vielen Grundfunktionen möglich ist, und alternativ mit zusätzlichen weitere Funktionen auf höherem Niveau, die die typischen Usecases mit sinnvoll vorbelegten Werten aufrufen lassen.
Die beste API ist die, bei der ein Zugriff mit einfachen, dafür zahlreichen Grundfunktionen möglich ist, und alternativ mit weiteren Funktionen auf höherem Niveau, die die typischen Usecases mit sinnvoll vorbelegten Werten aufrufen lassen.
Wer in Java einen String aus einer Textdatei einlesen möchte, schafft das mit reinen JDK-Methoden kaum in weniger als 10 Zeilen Code und nur unter Zuhilfenahme von 4 oder 5 verschiedenen nicht gerade einfachen Klassen wie FileInputStream usw. Natürlich gibt es dafür externe Bibliotheken wie die Commons IO API, aber man fragt sich trotzdem, warum einiger dieser immer wieder gebrauchten Standardfunktionen nicht von vornherein im JDK seinen Platz fanden?