Was sollte man bei der Auswahl von Development Tools beachten?

Development Tools richtig auswählen – einfacher gesagt als getan
Kommentare

Der richtige Werzeugkasten kann durchaus entscheiden, ob ein Projekt gelingt oder vor vornherein zum Scheitern verurteilt ist. Durch unpassende Development Tools türmen sich plötzlich Probleme auf, die mit geschickt gewählter Software überhaupt nicht vorhanden wären. Nur: Development Tools gibt es mittlerweile wie Sand am Meer, Fehlgriffe werden dadurch wahrscheinlicher. Gibt es Mittel und Wege, schlechte Tool-Entscheidungen zu vermeiden? Wir haben uns schlau gemacht.

2012 erstellt der Online-Entwickler Louis Lazaris eine Webseite, um sich über die schiere Anzahl an verfügbaren Development Tools wie Frameworks und Libraries lustig zu machen. Witzig, alle haben gelacht. Zwei Jahre später schreibt Lazaris einen neuen Artikel, in dem er argumentiert, dass die Situation in 2014 noch schlimmer sei. Jetzt haben wir 2016 und es scheint sich immer noch nicht wesentlich etwas geändert zu haben.

Antti Kirmanen jedenfalls beklagt in einem Beitrag für den Deveo-Blog eine regelrechte Flut an kontinuierlichen Neuerscheinungen. Ein Bild, das wir auf entwickler.de auch schon bemüht haben. Anstelle allgemeiner Strategien zum Umgang mit der Masse an Innovationen möchten wir diesmal mit Kirmanen der Frage nachgehen, wie man die für den Kontext des eigenen Projekts wirklich effizienten Tools identifiziert. Wir orientieren uns im Folgenden grob an seiner Einteilung der Thematik.

Bedürfnisse für Development Tools identifizieren

Die Ansprüche und Wünsche bezüglich eines neuen Development Tools zu formulieren, heißt zunächst einmal, die Probleme zu identifizieren, die ich mit meinem aktuellen Workflow habe: Wo gibt es Engpässe, wo hakt es, wo greifen unterschiedliche Schritte des Entwicklungsprozesses schlecht ineinander? Es versteht sich, dass heute, wo Software-Entwicklung meist in Teamarbeit stattfindet, die Schwächen des Toolsets in der Gruppe diskutiert werden sollten.

Weil es häufig nicht so selbstverständlich ist, wie es sich anhört, sei außerdem daran erinnert, dass natürlich diejenigen über die Neuanschaffung eines Development Tools (mit-)entscheiden sollten, die damit arbeiten, also die Programmierer. Entscheidungen aus dem Sphären des Managements herab sollten tunlichst vermieden werden. Ob neue Technologien adaptiert werden, ergibt sich aus dem Entwicklungsprozess, nicht aus den Gesetzen der Hype-Ökonomie oder ähnlichem. Nicht zuletzt, weil einzelne Development Tools keine Wunderwaffen für jedes Problem sein können, sollte man sich dann daran machen, die Ansprüche zu konkretisieren.

  • Welche Wünsche stehen im Raum, welche Fähigkeiten sollte das neue Development Tool haben? Und welche dieser Wünsche sind wirklich essentiell?
  • Wollen wir das Tool selbst unterhalten oder auf (wohlmöglich kostenintensiven) Support zurückgreifen?
  • Proprietäre oder Open-Source-Software und ist das relevant?
  • Mehrere Development Tools oder eine ganzheitliche Lösung?
  • Welche Informationen müssen/wollen wir verarbeitet?
  • Welche Aufgaben müssen erledigt werden und wer erledigt die Aufgaben mit welchen Rollen?

Die passende Development-Tool-Lösung finden

Logischerweise steht die Funktionalität des Tools im Mittelpunkt der Entscheidung. Adressiert es wirklich die Probleme oder bietet es nur nette, aber überflüssige Spielereien? In seinem Listicle über Fehler bei der Tool-Auswahl warnt Justin James außerdem davor, sich auf angebliche Komplettpakete zu verlassen. Ein gutes Tool mit einigen Plugins reicht vielleicht auch.

Äußerst wichtig bei der Auswahl einer neuen Software-Lösung ist, sie mit dem existenten System abzugleichen. Oftmals binden sich hohe Anforderungen daran, die Lösung in die alte Entwicklungsumgebung zu integrieren. Nicht nur durch die Initiierung des Tools ins System können Kosten entstehen, sondern auch weil die Entwicklung unterbrochen und neue Lernprozesse angestoßen werden. Ob sich der Mehraufwand langfristig rechnet, sollte unbedingt vorher kalkuliert werden. Das betrifft nicht nur das Budget, sondern auch Training, Instandhaltung und Support sowie rechtliche Fragen.

In diesem Kontext gilt es, Programmierparadigmen und Unternehmensstandards zu beachten. Tools, die die agile Softwarepproduktion begünstigen, bereiten einem aufs Wasserfallmodell spezialisierten Team wahrscheinlich Probleme. Sollten im Team erste Erfahrungen mit dem Tool vorhanden sein: umso besser. Auch Firmenstandards gilt es zu berücksichtigen. Gerade größere Unternehmen kommen nicht umhin, einvernehmliche Standards hinsichtlich der Entwicklungs-Policy zu formulieren, um die durchgehende Qualität ihrer Produkte und den effizienten Einsatz ihres Personals zu gewährleisten.

Zuletzt ist es durchaus ratsam, sich den Tool-Hersteller genau anzusehen. Natürlich sollte man sich vorher online umhören, aber auch Demos sowie Informationen speziell zu den eigenen Bedürfnissen anzufragen, ist ein probates Mittel. Justin James hat in seinem oben erwähnten Beitrag einen empfehlenswerten Kriterienkatalog zusammengestellt. Er schaut sich bspw. die Qualität des (Community-)Supports an, checkt die Lizenz- und Preiskonditionen sowie ob diese transparent und gut verständlich sind und ob Industrie- sowie proprietäre Standards eingehalten werden.

Testläufe durchführen und evaluieren

Für fast jedes Programm gibt es heute Trial-Versionen, die auszunutzen sich unbedingt lohnt. So bekommt man einen ersten, intensiveren Eindruck von einer Software, der dann sorgfältig evaluiert werden kann. Wer über die nötigen Ressourcen verfügt, kann Leute für ein Pilotprojekt abstellen, wo der Erfolgsdruck weitgehend herausgenommen ist. Dort sieht man, ob ein Development Tool den Praxistest besteht oder eben nicht.

Mal ganz abgesehen davon, ob das Tool den ihm zugeschriebenen Job vernünftig erledigt, konzentriert man sich Antti Kirmanen zufolge bei der Evaluation am Besten auf vier Bereiche:

  1. Verwendbarkeit: Hohe Komplexität ist häufig ein Nachteil. Wenn die Entwickler länger damit beschäftigt sind, ihre Tools einzustellen und zu warten, läuft etwas falsch. Effizienter Einsatz und ein gutes User Interface gehen meist Hand in Hand.
  2. Erweiterbarkeit: Die neue Development-Lösung wird nicht alle bisher verwendeten Programme überflüssig machen und in Zukunft ebenfalls der ein oder anderen Ergänzung bedürfen. Daran, wie sie sich mit der alten Entwicklungsumgebung verträgt, kann man diesen Faktor schon in etwa erahnen.
  3. Skalierbarkeit: Was man bei Pilotprojekten im Hinterkopf haben sollte, ist, dass „ernsthaftere“ Projekte mit Userzahlen arbeiten, die sich sowohl in einer anderen Dimension bewegen als auch erheblich variieren können. Geben die Testläufe also Aufschluss über diesen Aspekt?
  4. Veränderbarkeit: Schlussendlich lässt sich während des Tests auch ein Überblick darüber gewinnen, wie sehr das Tool ins gesamte Ökosystem ausgreift. Das kann Schwierigkeiten verursachen, wenn man späterhin einen Tool-Wechsel vornehmen will. Dass man zu abhängig von einem Development Tool wird, sollte vermieden werden.

Fazit

Das richtige Development Tool kann ein Projekt schneller und effizienter an sein Ziel bringen. Dafür muss es aber zunächst einmal gefunden und seine Vorteile erkannt werden. In großen, komplexen Projekten kann das mitunter schwierig sein. Es wird darum immer wichtiger, bewusste und gut informierte Entscheidungen zu fällen, bevor man sich dazu entscheidet, ein Development Tool in eine Entwicklungsroutine aufzunehmen.

Aufmacherbild: Tool renovation on grunge wood von Shutterstock / Urheberrecht: Isara Kaenla

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -