85 kansen en signalen om je softwareontwikkeling nog beter aan te pakken

Als ervaren ontwikkelaar met een brede interesse kom ik bij veel verschillende organisaties om ze te helpen met het professionaliseren van haar softwareteams. In het gratis mini-boekje "85 kansen en signalen om je softwareontwikkeling nog beter aan te pakken" heb ik per onderdeel een lijst van vragen gemaakt die de grootste pijnpunten snel boven water zullen helpen. Daarbij kijk ik onder andere naar de ontwikkelmethodieken, ontwerptechnieken, tools, teamdynamiek en planningsprocessen. Uiteraard zijn er altijd ruim voldoende aandachtspunten, maar het valt me vaak het eerst op hoeveel moeite organisaties hebben om de complexiteit onder controle te houden. Soms is dat omdat de technologie niet aansluit bij de eisen en wensen, maar vaak zijn het ook meer persoonlijke keuzes van individuele ontwikkelaars. Dat dit de voorspelbaarheid niet ten goede komt hoef ik je natuurlijk niet uit te leggen.

Veel organisaties laten kansen liggen

Daarnaast laten organisaties veel kansen liggen om de productiviteit te verhogen. Vaak zijn die pijnpunten heel evident als je met de ontwikkelaars praat, maar om een of andere reden land dit nooit zo lekker bij het management. Een tooltje van 50 euro kan over een jaar duizenden euro's schelen. Maar ook architectuur- en ontwerpkeuzes kunnen voor beperkingen in de productiviteit zorgen. Deze zijn voor een leek een stuk lastiger te detecteren, en komen veelal uit een te dogmatische denkwijze van ontwikkelaars of simpelweg een gebrek aan ervaring. En dat laatste kan ik zeker uit mijn eigen ervaringen beamen.

Belang van testbaarheid 

Testbaarheid is minimaal net zo'n aandachtspunt als de rest. Bijna alle organisaties die de wens hebben om nieuwe functionaliteit sneller in productie te krijgen, lopen tegen de beperkte testbaarheid van haar systemen aan. En dit is niet iets dat je makkelijk oplost. Het vereist een mindset en bepaalde manier van werken om een systeem testbaar te maken (en te houden). Dit gaat vaak om codeerpatronen waarvan de meeste ontwikkelaars niet beseffen hoe ze testbaarheid in de weg kunnen staan.

Interne kwaliteit 

En waar niemand opkijkt van de noodzaak van testbaarheid, ligt de traceerbaarheid een stuk minder op de radar van de gemiddelde ontwikkelaar. Toch zie ik het vastleggen van besluiten, keuzes en afwegingen als één van de fundamenten van wat ik "interne kwaliteit" noem. En ook de historie zoals die terug te vinden is in het onderliggende source code systeem is daar onderdeel van. En dat niet alleen, de vindbaarheid en beschikbaarheid van informatie in de breedste zin van het woord is net zo belangrijk. Sommige teams zijn nog best te porren om wat documentatie te schrijven, maar het is echt niet altijd duidelijk waar die te vinden is, hoe die zich relateert aan de architectuur en hoe actueel deze nog is.

Maar wat zijn nou die specifieke signalen, symptomen en pijnpunten waar je op moet letten? Lees dat in de gratis e-book "85 kansen en signalen om je softwareontwikkeling nog beter aan te pakken".