Menu
In mijn praktijk als deskundige wordt die vraag nog al eens gesteld. En dan meestal niet in die vragende vorm, maar in een conflictsituatie in een stellende, kwalificerende vorm: “De software is van slechte kwaliteit“, meestal als onderdeel van een groter dispuut.
In voorgaande blog heb ik geschreven over de technische kwaliteit van de programmatuur, met onderscheid in de verschillende lagen van software (database, databenadering, business logica, schermopbouw en -afhandeling).
In deze blog ga ik in op het productieproces van de applicatie.
Dat programmatuur gemaakt wordt is één ding, maar de levensduur van een applicatie is veel langer dan het pure productieproces (het maken van) de programmatuur zelf. Een beetje applicatie gaat 5 jaar mee, maar een levensduur van meer dan 10 jaar is meer regel dan uitzondering. En in die 10 jaar wordt er nog het nodige aan de programmatuur gesleuteld, niet alleen voor oplossen van bugs, ook voor het verrichten van adaptief onderhoud, het maken aanpassingen en het aanbrengen van uitbreidingen. En dan niet alleen voor de programmacode zelf, maar voor alle onderdelen van de applicatie, dus ook bijvoorbeeld de database structuur
Gedegen beheer van alle programmatuur bouwstenen is noodzakelijk en daarvoor bestaan broncodebeheer hulpmiddelen, zoals Team Foundation Server, GitHub, SVN, en meer. IT Professionals kunnen niet zonder deze gereedschappen. Ontbreekt source code management bij de ontwikkeling, dan is dat voor mij een teken van een minder professionele aanpak en wellicht een indicatie voor de kwaliteit van de uiteindelijke programmatuur
Goed gereedschap is het halve werk
Een oud gezegde, maar nog steeds waar voor het ontwikkelen van programmatuur. Is een goed broncodebeheersysteem een hulpmiddel voor het bewaren van applicatie onderdelen tijdens de levensduur van de applicatie, ook binnen het ontwikkelproces. Er zijn uitstekende hulpmiddelen beschikbaar die de productiviteit van een IT-professional vergroten.
En niet alleen de productiviteit, ook de kwaliteit van het gerealiseerde, denk bijvoorbeeld aan het automatisch genereren van unit testen als onderdeel van de applicatieontwikkeling, het structureren van de broncode, het herordenen (refactoren) van onderdelen van de programmacode, het genereren van data testgevallen enz.
Ontbreken dit soort gereedschappen tijdens het ontwikkelen van de programmatuur, dan plaats ik extra vraagtekens bij de kwaliteit van de ontwikkeling.
A fool with a tool is still a fool
Maar aan de andere kant, zelfs als dit soort hulpmiddelen aanwezig zijn, wil dat niet zeggen dat de developers er effectief mee om weten te gaan. Goed gereedschap vergt vaardigheid om maximaal voordeel te hebben.
Programmacode wordt niet vanzelf een werkende applicatie, er komen bewerkingen aan te pas om de programmacode om te zetten naar een programma: compileren en/of builden, de database moet worden aangemaakt, een omgeving voor testen moet beschikbaar worden gemaakt, testgegevens moeten worden aangeleverd, testen moeten worden uitgevoerd.
Al dit soort taken kunnen geautomatiseerd worden. Er bestaan gereedschappen voor het automatisch builden, testomgeving samenstellen, testengegevens aanmaken, testen runnen, testresultaten verzamelen.
Kortom: don’t work harder work smarter
Wanneer deze procedurele gereedschappen ingericht zijn en het proces soepel loopt, dan is dat voor mij geen garantie dat er geen fouten worden gemaakt of programmatuur van mindere kwaliteit, maar wel een indicatie dat er professionals aan het werk zijn.
Wordt de programmatuur eenmaal gebruikt, dan duiken er gewenste en ongewenste effecten op. Gewenst zijn de opmerkingen en suggesties van gebruikers, ongewenst de bugs (resterende fouten) die naar voren komen.
Een bug is niet erg
Een bug is vervelend, maar pas een probleem als deze niet wordt opgelost. Een goede development omgeving kent een issue tracking systeem waarmee fouten, vragen, opmerkingen en suggesties worden vastgelegd, beoordeeld, nagespeeld, van prioriteit voorzien en uiteindelijk afgerond.
Wat ik in de praktijk (te) vaak zie is het gebruik van Excel voor het vastleggen van dit soort issues, vooral tijdens de testfase in het ontwikkelproces. Positief voor het gebruik van Excel is het feit de melding in ieder geval wordt vastgelegd, maar verder is er weinig voordeel mee te behalen.
Een goed issue tracking systeem biedt ondersteuning voor automatiseerder en gebruiker, kent een centraal systeem, kan overzichten maken, prioriteiten vastleggen, schermafdrukken en voorbeelden opslaan, communicatie tussen betrokkenen ondersteunen en meer.
Er zijn vele soorten issue tracking systemen, bekende oplossingen zijn Jira, Trello, Zendesk en sommige daarvan hebben zelfs een gratis startvariant. Vergeet Excel hier, gebruik een issue tracking applicatie.
In de praktijk zijn er meer elementen die de kwaliteit van software beïnvloeden. Een goed ingericht proces en gebruik van goede gereedschappen maken het werk lichter, maar uiteindelijk zijn het de mensen zelf die het moeten doen. Toch zijn beschikbare gereedschappen voor mij een extra indicatie van de kwaliteit van de uiteindelijke software. Een goede vakman toont zich ook in de keuze van zijn gereedschappen.