Het is toch genoeg als de software gewoon goed werkt?
Zeker niet! En ik leg je graag uit waarom jij – als opdrachtgever voor het bouwen van software – wel degelijk zou moeten willen weten welke programmeertechnieken wij gebruiken. En welke programmeertaal. En welke tools. En zeker ook wat wij doen om de code optimaal te structureren. En hoe wij alles documenteren.
Ik begrijp best dat je eerste reactie is:
“Bespaar me al die technische details, zeg!”
Nou, ik kan je garanderen dat als je er op die manier in staat, dat het risico dat het je veel geld gaat kosten groot is. En ik ga je nu vertellen waarom dat zo is.
De grootte van het project
Natuurlijk speelt de grootte van het project een rol. Want bij kleine, overzichtelijke opdrachten zijn de extra kosten te overzien als achteraf zaken alsnog anders moeten worden opgezet. Maar zodra een project wat groter van omvang wordt, kan de pijn snel toenemen: wij kennen voorbeelden van projecten van een paar honderd uur, die van scratch af aan volledig opnieuw moesten worden opgezet, omdat er vooraf onhandige keuzes waren gemaakt.
Programmeertaal
Er bestaan heel veel verschillende programmeertalen. Blijf om te beginnen weg van al die exotische (lees: weinig gebruikte) talen, want als jouw opdrachtnemer of programmeurs wegvallen, kan vervanging vinden een probleem blijken te zijn. En wie garandeert dat zo’n weinig gebruikte taal een toekomst heeft? En dat die onderhouden blijft worden tot in lengte van jaren, in een doorlopend proces van verbeteren maar zeker ook van beveiligen?
Daarnaast hebben alle programmeertalen hun voor- en nadelen en past niet iedere taal goed bij ieder project; laat je goed adviseren door iemand die je kan vertrouwen. Iemand die ervaring heeft. En iemand die niet vanuit zijn eigen belang spreekt, maar jou werkelijk wil helpen aan de beste oplossing. Die mensen bestaan echt! Maar soms moet je even zoeken.
Topulus werkt met PHP (voor kleine projecten) en .NET (voor middelgrote en grote projecten). Dat daarmee nog lang niet alles is gezegd en besproken, zal blijken uit het volgende:
Structuur aanbrengen en documenteren
Programmeurs dienen optimale structuur aan te brengen in hun programmeercode. En ze dienen zowel in de code zelf als erbuiten een goede documentatie bij te houden.
De mate waarin programmeurs op de juiste wijze structuur aanbrengen, is van enorme invloed op de kwaliteit van de uiteindelijke code die wordt opgeleverd. En dus voor de onderhoudbaarheid en de uitbreidbaarheid in de toekomst. En misschien verwacht je het niet, maar programmeurs worden continu verleid om chaotisch te werken. Om even snel tussendoor een wijziging aan te brengen, iets ‘slordig’ te programmeren. En het bijwerken van de documentatie – al dan niet met opzet – te vergeten. Want dat scheelt tijd. En er is altijd die druk van efficiënt en in zo min mogelijk tijd opleveren wat de klant vraagt. En het werkt toch ook als je het ‘slordig’ programmeert, en zonder te documenteren? Sterker, de klant merkt daar niets van. Maar als later de code vol blijkt te zitten met al die ‘eventjes een kleine lokale wijziging’, dan zijn de rapen gaar. Neem dat van mij aan.
En daarom zijn er tools en technieken om de programmeur min of meer te dwingen gestructureerd te werken. Daarover straks meer.
Maar waarom is die structuur in de code zo belangrijk?
Nou, als de code ongestructureerd is, waarvan de informele duiding ‘spaghetti-code’ is, dan is later werken aan de code lastig. En soms zelfs bijna niet te doen. Als je dan een kleine fout (een bug) in de software wilt herstellen, dan blijken er diverse onverwachte, onlogische ‘afhankelijkheden’ te zijn, die maken dat jouw logische wijzigingen gevolgen hebben elders in de code, elders in de software, die je niet kon voorzien. De werking van de software verandert dan onverwachts op andere plekken, op een onlogische manier. Er duiken dan gewoon fouten op. Dingen die ineens anders en verkeerd of helemaal niet meer werken. En dan moet je uitzoeken hoe je dat herstelt. Daarvoor breng je wijzigingen aan. Met eventueel weer nieuwe onverwachte gevolgen. We hebben het nu over de ‘onderhoudbaarheid’ van de code. En het grote belang daarvan.
Een voorwaarde en tevens graadmeter van goed programmeren is altijd dat een andere programmeur die de code voor het eerst ziet, er bijna zonder inwerktijd mee verder kan. Jouw garantie dat je product een toekomst heeft.
Onderhoudbaarheid
Waarom zou je later nog aan de code van je software willen laten werken?
Nou, dat is noodzakelijk om de boel veilig te kunnen houden bijvoorbeeld. Maar ook om fouten op te lossen. Of extra functionaliteit in te bouwen.
Software laten bouwen is eigenlijk nooit een eenmalig iets; je kunt het beter zien als een doorlopend proces, waarbij in ieder geval op regelmatige basis onderhoud gepleegd moet worden.
En daar komt die structuur om de hoek kijken. Want alleen als de structuur goed is, is de ‘onderhoudbaarheid’ voor elkaar en kunnen programmeurs efficiënt werken.
Voorbeeld: Onlangs hebben we het beheer van software overgenomen, waaraan in de loop van de voorbije jaren verschillende programmeurs hadden gewerkt. Die software werkte prima; alle eindgebruikers dweepten ermee. Maar als wij er iets aan gingen veranderen, bleken zaken die normaliter op één logische plek in de code zijn gedefinieerd, soms wel op 6 of 7 plekken (echt waar!) in de code voor te komen. Met als gevolg dat onze wijziging weliswaar iets verbeterde, maar op vele andere plekken ongewenste en onverwachte gevolgen had. En al die gevolgen moesten wij dan nalopen en herstellen. Maar ook elke ‘herstel-actie’ leverde eenzelfde risico op, dus voor je het weet is het einde zoek.
Uiteindelijk is alles wel op te lossen, maar in situaties als deze kost dat ongelooflijk veel extra tijd op niets af. De code heeft dan geen ‘toekomst’, want als je echt grote wijzigingen zou wensen, is de goedkoopste oplossing: opnieuw beginnen. En bij projecten waar al een paar honderd uur in zit, heb je het dan over serieuze desinvesteringen. En toch is dat precies waar we bij dit project voor hebben gekozen: we zijn volledig opnieuw begonnen en gooiden daarmee een project van 500 uur weg. En het zure is natuurlijk – ook al is het achteraf gemakkelijk praten, ik durf dit toch te zeggen – dat als dit project vanaf de basis goed was opgezet, dan was deze desinvestering niet nodig geweest.
In het belang van
Bij al ons ontwikkelwerk zijn wij ons erg bewust van alle risico’s die wij in deze blog hebben beschreven. Met de keuzes die wij daarin maken, en de transparantie daarover zoals in deze blog, denken wij altijd te werken in dat ene belang, dat belang dat altijd voorop moet staan: het belang van de klant.