Wieder neigt sich ein Jahr dem Ende zu und damit ist auch, zum dritten Mal, die SEROM in Vechta vorbei. Ein großes Lob an Stefan für die Organisation!
Ich durfte auf der Konferenz den Joel Test (a.D. 2000) vorstellen und erläutern, wie ich den Test, 18 Jahre nach seiner Veröffentlichung, bewerte und aus heutiger Sicht anpassen würde.
TL;DR;
- Do you do continuous integration?
- Do you use an issue tracker?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet and healthy working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Are you doing code reviews?
- Do new candidates write code during their interview?
- Are new hires onboarded efficiently?
- Do you have UX specialists?
Ich spare mir an dieser Stelle das original zu zitieren und steige direkt mit meinen Änderungsvorschlägen ein.
Do you use source control? [removed]
Die Frage habe ich gestrichen, weil laut der meisten Umfragen um die 95% VCS im Einsatz haben (z.B. Stackoverflow Developer Survery 3.7% I don’t use version control). Ich selber habe in den letzten Jahren niemanden getroffen, der das nicht hat (d.h. ich kenne einen(!) Fall vom Hörensagen). Wenn es um Versioncontrol geht, dann eher darum ob (noch) SVN oder Git eingesetzt wird .
Also nehme ich an, dass die Zahlen etwa hinkommen, setze das als Standard vorraus und wage zu behaupten, dass man wahrscheinlich ganz andere Probleme hat, wenn man das Thema in den letzten >10 Jahren verschlafen hat.
Außerdem ist source control die Vorraussetzung für die neue erste Frage:
1. Do you do continuous integration? [update]
Zusammenfassung der Fragen
2. Can you make a build in one step?
3. Do you make daily builds?
Wenn man daily builds macht, wäre es Zeitverschwendung wenn man dafür mehr als einen Schritt benötigt. Wenn ich das täglich kann, warum dann nicht mit jedem Push in die Versionskontrolle?
Sollte Standard sein, ist es leider aber nicht: In Umfragen geben um die 40%-50% an, CI zu betreiben. Dass nur etwa jedes 2. Team CI betreibt würde ich mit Bezug auf meine echo chamber sogar bestätigen.
Ich habe überlegt, an dieser Stelle nach Continuous Deployment zu fragen, denke aber, dass das zu spziell ist. Bei Webservices durchaus sinnvoll, hat nicht jedes Produkt die Anforderung, dass jeder Build beim Kunden landen muss. Sei es technisch bedingt, weil z.B. embedded Software entwickelt wird und das garnicht so einfach bzw. continuously möglich ist, oder weil der Vertriebsweg das quasi unterbindet.
Trotzdem tendiere ich natürlich dazu, so nah wie möglich dort ranzukommen. Die Frage: “Are you, or would you be doing continuous delivery if …” finde ich aber ungeeignet.
2. Do you use an issue tracker? [update]
Bug tracker sind heute issue tracker. Einfache Listen waren gestern, also warum sollen wir nicht in den Genuss kommen, den uns Tools wie bspw. JIRA, Redmine, TFS, usw. bereits out of the box bieten? Außerdem tracken wir nicht nur Fehler, sondern auch Features.
Die Tools verhindern bisher leider keine unqualifizierten Einträge. Das ist besonders bei Fehlern ärgerlich: Wenn einem der Titel wage mitteilt, dass etwas nicht geht und die Beschreibung dann auch nicht viel mehr Informationen liefert.
Aber selbst dann, wenn ein Fehler einigermaßen ausführlich beschrieben wurde, können wichtige Details fehlen. Z.B., wenn eine Maske über mehrere Stellen in der Software aufgerufen werden kann, dies aber nur an einem Punkt zum Fehler führt.
Darum müssen wir beim Verfassen von Issues (insbesondere Bugs) festhalten:
- Welche Schritte notwendig sind, um sie zu reproduzieren
- Welches Verhalten man erwartet
- Wie sich die Software stattdessen verhält
3. Do you fix bugs before writing new code?
Solange es Fehler in Software gibt, bleibt es wichtig sie zu beheben, bevor neuer Code darauf aufbaut. Es hat sich nichts daran geändert, dass man weniger Features auf den Markt bringen kann, wenn man sich mit Korrekturen aufhalten muss die man nicht sofort beseitigt hat.
4. Do you have an up-to-date schedule?
Ebenso bleibt es notwendig, permanent über den Etnwicklungsstand auf dem laufenden zu sein, damit wir einerseits über den Projektfortschritt informiert sind, aber auch um Probleme rechtzeitig zu erkennen und darauf reagieren zu können.
Dass das wichtig ist, bestätigen z.B. agile Methoden wie Scrum, wo (nach Lehrbuch) tägliche Standup Meetings angesetzt werden und eben dieser Fortschritt sichtbar gemacht wird, indem man beantwortet:
- Was habe ich seit gestern erledigt?
- Was möchte ich heute erledigen?
- Was steht mir dabei im Weg?
5. Do you have a spec?
Specs bleiben ebenfalls unabdingbar. Hier können wir wieder den Schwenk zur agilen Softwareentwicklung machen: Dort haben wir z.B. Reviews und sind offen für Änderungen. Das darf aber nicht heißen, dass wir Ziellos entwickeln und abwarten, was der ‘Kunde’ nach zwei Wochen bemängelt.
Auch wenn agil vorgegangen wird (oder gerade dann) sollte genügend Arbeit vor der eigentlichen Umsetzung in (irgendeine Form von) Spezifikationen fließen um Schwierigkeiten schon vorher auszumerzen. Dass dafür programmiert wird (Prototyping) ist ja nicht ausgeschlossen.
Außerdem muss die Funktionalität im Nachhinein überprüfbar sein um feststellen zu können, ob sie den Anforderungen entsprechend oder fehlerhaft ist. Ohne Specs wird das schwierig.
6. Do programmers have quiet and healthy working conditions? [update]
Wie Spolsky denke ich, dass Entwickler ein ruhiges Arbeitsumfeld brauchen damit sie sich konzentrieren können. Ob eigene Büros der Königsweg sind, bezweifle ich aber. Beides, räumlich zusammen oder getrennt zu arbeiten, hat Vor- und Nachteile.
In Großraumbüros kann es reichen, dass man Regeln definiert, die ruhiges Arbeiten fördern. Mit Kopfhörern kann man z.B. seinen Kollegen signalisieren, dass man nicht gestört werden möchte (ohne sich selbst mit lauter Musik noch mehr abzulenken).
Wenn man echte Ruhe benötigt, sollte man sich natürlich immer noch in einen Besprechungsraum o.ä. zurückziehen können oder andere Mittel finden um fokussiertes arbeiten zu ermöglichen, wie z.B. Arbeiten von Remote/Homeoffice oder Focustime.
Darüber hinaus ist es sinnvoll, aktiv auf die Konzentrationsfähigkeit zu wirken, indem man dafür sorgt, dass Entwickler (und alle anderen Kollegen), Gesund sind.
Abgesehen von ergonomischer Hardware wie Stehtische, können etwas Bewegung an der frischen Luft und frisches Obst einiges dazu Beitragen. Das kann heute schon immer häufiger u.a. durch Zuschüsse zum Fitnesstudio, Jobrad und Obstbars gefördert werden.
7. Do you use the best tools money can buy?
Teams, die gute Werkzeuge haben, unterscheiden sich von denen, die sie nicht haben.
Das hat sich in 18 Jahren kaum geändert und ist kein Phänomen, dass sich auf die Softwareentwicklung beschränkt. Dass am falschen Ende gespart wird, erleben z.B. auch im Handwerk.
Wer billig kauft, kauft zweimal.
Wer gutes Werkzeug und Material benutzt ist in der Regel schneller oder spart Arbeitsschritte. Das bestätigt jeder, der schon einmal, bzw. mehrmals ;), ein Zimmer mit der günstigen Farbe gestrichen hat.
Also sowohl in Hardware (z.B. SSDs) investieren, als auch in Software: Oft lohnt sich die Anschaffung von Software die einem Arbeit abnimmt (oder natürlich die Eigenentwicklung wenn es tatsächlich keine fertige Lösung gibt). Das gilt gleichermaßen für Schulungen oder Weiterbildung darin.
8. Do you have testers?
Tester zu haben, ist nach wie vor nicht unwichtig. Allerdings aus dem Grund, weil (meine Erfahrung) Entwickler ungern testen. Das sollten also Experten machen, die darauf spezialisiert und vor allem motiviert sind.
Das soll nicht bedeuten, dass Entwickler ihren Code nicht testen sollen. Sie können aber ihre Kompetenz ausspielen indem sie bspw. Unit Tests schreiben (das sollten sie sowieso), oder eng mit Testern zusammenarbeiten und Lösungen entwickeln, die das Testen vereinfachen können.
9. Are you doing code reviews? [add]
Statt, Software zu testen, sollten wir die Zeit nutzen um Code Reviews durchzuführen und so unseren Teil zur Qualitätssicherung beitragen.
Ich würde garnicht festlegen, in welcher Form man das macht, also ob durch Pair-Programming oder später bei Pull-Requests, solange wenigstens ein zweiter Entwickler den Code rezensiert.
Nicht allein, um mögliche Fehler zu finden, sondern vor allem um die Code-Qualität zu verbessern und Wissensinseln zu vermeiden bzw. reduzieren.
10. Do new candidates write code during their interview?
Die Zeit für ein ordentliches Kennenlernen ist während des Bewerbungsprozesses in der Regel recht knapp. Da Coden ist, neben dem Zweck einer “Arbeitsprobe”, auch sehr gut dazu geeignet, um etwas mehr über Bewerber zu erfahren: Wie sie kommunizieren, Probleme angehen und ob sie ins Team passen.
11. Are new hires onboarded efficiently? [add]
Fast noch wichtiger als ein solides Recruiting, finde ich, muss das Onboarding sein. Denn es nützt nichts wenn man die besten Kollegen anheuert, aber nicht dabei unterstützt, so schnell wie möglich produktiv mitarbeiten zu können.
Wenn neue Kollegen das Büro betreten muss der Arbeitsplatz startklar sein. Außerdem sollten sie Einweisungen in die Strukturen und verwendeten Tools bekommen. Auch wenn die Tools beherscht werden, ist oft die Arbeitsweise eine ganz andere. Und; man wird immer noch was neues lernen.
12. Do you have UX specialists? [update]
In den letzten zwei Jahrzehnten haben wir, durch verschiedenste Devices und viele neue Benutzer, eine Menge über Usability bzw. User Experience gelernt.
Das Thema ist so umfangreich und wichtig (geworden), dass sich dafür ein eigenes Berufsbild herausgebildet hat. Also sollte man diese Aufgaben, wie auch beim Testen, an Experten delegieren.
Sie können dann dafür verantwortlich sein, hallway usability tests durchzuführen. Idealerweise bringen sie jedenfalls ihr Know-How schon ein, bevor entwickelt wird.