Wat ging er mis met mijn Software, website, ERP systeem?

Je nieuwe website is eindelijk live! Maar dan...

Na maanden van geduld is het eindelijk zover: je nieuwe website is live. Hoewel het project drie tot zes maanden langer heeft geduurd dan gepland, ben je trots op het eindresultaat. Je droomt alvast van de vele leads die binnen zullen stromen.

Maar in plaats van meer bezoekers te krijgen, merk je al snel dat het verkeer afneemt. Als leek weet je niet precies waar het aan ligt. De firma die je website heeft ontwikkeld, verzekert je dat het even zal duren voordat Google je nieuwe site indexeert. Wat ze echter niet vertellen, is dat ze vergeten zijn om redirects van de oude naar de nieuwe structuur in te stellen.

Zes maanden later...

Na zes maanden en talloze SEO-updates besluit je om de structuur van je website bij te werken. Je hebt een nieuwe service en realiseert je dat de content anders moet. Wanneer je contact opneemt met de firma, zijn ze bereid om te helpen, maar ze waarschuwen dat het een flinke klus zal zijn. Waar jij dacht dat de aanpassingen in een paar uur klaar zouden zijn, blijkt het ineens een werk van meerdere dagen voor twee personen. De rekening begint snel op te lopen.

Wat gaat hier mis?

Als ik een project overneem van een andere firma, stuit ik soms op opmerkelijke zaken die duidelijk maken waarom het zo moeilijk is om de website aan te passen.

Over-engineering en onnodige complexiteit

Sommige projecten zijn simpelweg over-engineered. Er is gewerkt met meerdere mensen en cutting-edge technologieën die niets bijdragen aan het eindresultaat, maar wel voldoen aan de laatste hype in de softwarewereld. Denk bijvoorbeeld aan het onnodig gebruik van frameworks zoals React, Vue of Svelte. Wij hebben ook even met deze hype meegedaan, totdat we beseften dat klanten helemaal geen complexe frontend frameworks met API's nodig hebben. In 99% van de gevallen volstaat HTMX met een beetje vanilla JS of AlpineJS. De overige 1% is gereserveerd voor speciale projecten waar het echt nodig is. Denk aan een applicatie als Google maps.

Herhaling en het negeren van het DRY-principe

Bij andere projecten zie ik vaak dat de code zich constant herhaalt, wat duidt op een negeren van het DRY-principe (Don't Repeat Yourself). In plaats van één keer een functie te schrijven en deze te hergebruiken, wordt dezelfde functie overal expliciet gekopieerd en geplakt. Wil je dan iets veranderen, dan moet je dat op 50 plekken doen. Vergeet je er eentje, dan ontstaat er een bug of erger.

Slimme, maar ondoorzichtige code

Nog andere projecten zijn zo slim in elkaar gezet dat je nauwelijks kunt begrijpen waar iets vandaan komt. Alles is zo ingenieus gestructureerd dat je niet weet wat er gebeurt als je één functie aanpast. Je moet alles dubbelchecken en blijft zitten met een knagend gevoel, vooral als er geen tests zijn geschreven.

Afhankelijkheid van plugins

Sommige projecten steunen op een dozijn plugins, zonder dat er is nagedacht over het onderhoud en de toekomstbestendigheid van deze open-source oplossingen. Als een plugin niet meegroeit met het project, kan dat voor de klant aanzienlijke kosten met zich meebrengen om deze te vervangen.

Gebrek aan beheersing van CSS

Op het gebied van frontend zie ik soms dat CSS niet goed wordt beheerst. CSS beschrijft de opmaak en layout van je website. Vaak leunt men te veel op een framework zoals Tailwind om de layout te maken. In de meeste gevallen is een extern framework echter niet nodig. Zo had ik laatst een sollicitant die als test een pagina moest maken zonder een framework. Ondanks een moedige poging, slaagde deze persoon er niet in.

Hoe kun je als klant de codekwaliteit beoordelen?

Als klant is het lastig om de codekwaliteit te beoordelen, want je bent geen specialist. Maar hoe kun je dit toch aanpakken? Probeer door de buzzwords en marketingpraat heen te prikken door te vragen naar de visie op softwareontwikkeling. Als men dan begint met buzzwords en onbegrijpelijke termen, dan weet je hoe laat het is.

Onze filosofie in software ontwikkeling

Bij ons draait alles om eenvoud. We vermijden onnodige plugins en houden ons aan de kern van de software waarmee we werken. We schrijven liever zelf een doeltreffende oplossing dan dat we een plugin gebruiken die alles kan, maar niets goed. We herhalen onszelf niet in de code; als iets hetzelfde doet op verschillende plaatsen, refactoren we het. We geven nuttige commentaar bij onze code, zodat iedereen (inclusief wijzelf) het later makkelijk kan begrijpen. Onze code heeft een natuurlijke flow, zonder onnodige imports of overdreven engineering. We verbeteren onze code voortdurend, geven functies en klassen duidelijke namen, en zorgen ervoor dat het project met één commando geïnstalleerd kan worden in de ontwikkelingsomgeving. In de frontend denken we ook aan minder validen, die eveneens op het internet surfen. We passen methodologieën zoals BEM en CUBE-CSS toe en structuren onze code logisch.

Als je deze methoden volgt, zal je website, applicatie of ERP-systeem op de lange termijn makkelijker en kosteneffectiever te onderhouden zijn, minder bugs bevatten en gewoonweg vlotter werken. En wie wil dat nou niet?