“Mijn systeem is traag.” Waarom dat zelden het echte probleem is

“We denken dat het systeem te traag is.”

Dat was de opening van een gesprek dat ik onlangs had. En eerlijk gezegd snap ik die opening volkomen. Als iets niet lekker loopt, zoek je het al snel in de techniek.

Een trage server. Een verouderd framework. Een database die opnieuw geïndexeerd moet worden. Iets concreets dat je kunt aanwijzen en repareren.

Alleen, na een uur praten werd duidelijk dat het systeem helemaal niet traag was. Het deed precies wat het moest doen. Wat ontbrak, was iemand die ooit had gezegd: wacht even, klopt dit nog wel als geheel?

In deze blog leg ik uit waarom “trage software” bijna nooit een snelheidsprobleem is. En vooral: wat je in plaats daarvan moet doen voordat je gaat doorbouwen, vervangen of opnieuw beginnen.

Wat is het verschil tussen technisch traag en gevoelsmatig traag?

Er zijn twee soorten traagheid in software. Ze worden vaak door elkaar gehaald, maar ze vragen om een totaal andere oplossing.

Technisch traag

Symptoom API responses van seconden, hangende schermen, processen die uitvallen.

Oorzaak Verouderde infrastructuur, niet-geoptimaliseerde queries, te weinig rekenkracht.

Oplossing Caching, betere queries, meer servercapaciteit.

Investering Eenmalig technisch werk.

Gevoelsmatig traag

Symptoom Software reageert snel, maar werken erin voelt zwaar.

Oorzaak Te veel functies, onlogische workflows, vergeten koppelingen, processen die niet meer kloppen.

Oplossing Architectuur opnieuw bekijken en snoeien.

Investering Eerst denken, dan pas bouwen.

Snellere techniek onder een onlogisch proces is geen oplossing. Dan werken mensen sneller in een systeem dat niet meer klopt. Het wordt er zelfs erger van.

Hoe wordt software ongemerkt zwaar?

Vrijwel elke organisatie die ik spreek heeft hetzelfde patroon doorlopen. Het systeem werd ooit gebouwd voor een duidelijk doel. De eerste versie was strak, overzichtelijk, deed wat het moest doen.

En toen begon het leven.

Een nieuwe klant met een afwijkende workflow. Een verkoopkanaal dat erbij kwam. Een wettelijke wijziging die een extra veld vroeg. Een collega die “even snel” een knop wilde voor een uitzondering die maar één keer per maand voorkomt. Een losse koppeling om een proces te automatiseren waar iedereen achter stond. Een integratie met een tool die inmiddels niet meer gebruikt wordt, maar waarvan de koppeling nog wel actief is.

Stuk voor stuk waren het redelijke beslissingen. Op het moment zelf logisch, soms zelfs noodzakelijk. Maar ze zijn nooit als geheel opnieuw bekeken.

Niemand heeft ooit een dag genomen om te zeggen: jongens, als we dit systeem vandaag opnieuw zouden bouwen, wat zou er dan eigenlijk in horen?

Het resultaat: software die technisch prima draait, maar in gebruik aanvoelt als een kast die al twintig jaar niet is opgeruimd. Je weet dat alles wat je zoekt erin zit. Je weet alleen niet meer waar. Voor veel mkb-bedrijven is dit het moment waarop digitale modernisering ineens op de agenda komt. Niet omdat de techniek het opgeeft, maar omdat het werken erin niet meer te doen is.

Volgens onderzoek van het Consortium for Information & Software Quality kost technical debt de wereldeconomie naar schatting $1,52 biljoen per jaar door verloren productiviteit en vertraagde innovatie. Dat is geen technisch probleem. Dat is een organisatorisch probleem dat zich vermomt als een technisch probleem.

Waarom doorbouwen het probleem meestal vergroot

Op het moment dat een team dit doorheeft, zie ik vaak dezelfde reflex. Er moet iets nieuws komen.

Een nieuwe module, een nieuwe tool, een nieuw platform. Iets fris, iets modern, iets dat het oude eindelijk overbodig maakt.

Maar dan zie je iets gebeuren wat niemand voorzag. Het nieuwe systeem moet integreren met het oude. Mensen moeten beide kennen. Data moet ergens gesynchroniseerd worden.

En binnen een jaar heb je niet één zwaar systeem, maar twee. Met een koppeling ertussen die ook weer onderhoud vraagt.

Daar komt nog iets bij. In de meeste teams die ik tegenkom, begrijpt het grootste deel van de mensen de huidige architectuur niet eens volledig. Niet omdat ze dom zijn. Wel omdat de architectuur in de loop der jaren impliciet is geworden. Hij staat niet meer op papier. Hij zit in de hoofden van een paar mensen en in de code zelf.

Doorbouwen op iets wat je niet helemaal begrijpt is geen ontwikkeling. Het is hopen dat je geluk hebt.

Welke vragen stel je voordat je iets nieuws bouwt?

Het moment waarop ik in een gesprek meestal zeg “laten we even niets bouwen”, is precies hier. Niet omdat ik tegen ontwikkeling ben. Sterker nog, dat is letterlijk wat we doen.

Wat doet een software architect dan precies?

Bij Prikr noemen we onszelf software architect, en dit is precies waarom. Een ontwikkelaar bouwt wat je vraagt. Een goede architect vraagt eerst of je wel het juiste vraagt.

Dat klinkt misschien tegenstrijdig voor een softwarebureau. Wij verdienen geld met bouwen, dus waarom zouden we klanten weghouden van bouwen?

Het antwoord is simpel. Omdat we willen dat wat we bouwen, blijft werken. Voor jaren, niet voor maanden. En dat lukt alleen als de basis klopt.

Het mooie is dat een goede architectuurfase bijna altijd geld bespaart. Niet omdat we minder bouwen, maar omdat we het juiste bouwen. De helft van de feature-aanvragen die we tegenkomen, blijken bij doorvragen niet nodig. Of ze worden overbodig zodra een ander stuk wél goed wordt aangepakt.

Hoe ziet die heroriëntatiefase er bij Prikr uit?

Concreet ziet die fase er bij ons als volgt uit.

We brengen het huidige landschap in kaart. Niet alleen de techniek, maar vooral de processen die erin draaien en de mensen die ermee werken. We praten met de gebruikers, niet alleen met de opdrachtgever. We tekenen de echte werking uit, inclusief de uitzonderingen die niemand meer documenteert.

Daarna brengen we terug naar wat de kern is. Welke processen zijn essentieel, welke zijn historisch, welke kunnen weg. We benoemen waar de echte pijn zit en waar de toekomstige groei vandaan moet komen.

En pas dán praten we over bouwen. Soms is dat een vereenvoudiging van de bestaande website, soms een vervanging door een nieuwe webapplicatie die het werk wél aankan, soms een combinatie van beide. Vaak is het minder werk dan de opdrachtgever vooraf dacht. Bijna altijd is het ander werk dan eerst gevraagd was.

Dat is wat wij bedoelen met “eerst de digitale richting bepalen, voordat er gebouwd wordt”. Niet omdat we vertraging willen, maar omdat het de enige manier is om software op te leveren die over drie jaar nog steeds bij je past. Hoe we dat in de praktijk doen, lees je in detail op onze aanpak-pagina, of zie het terug in onze cases.

Tot slot

Trage software is bijna nooit een techniekprobleem. Het is een verhaal van honderd kleine, redelijke beslissingen die nooit als geheel zijn herzien. De oplossing zit niet in meer bouwen, maar in eerlijk kijken naar wat er nog hoort en wat eruit kan.

Loopt jouw systeem niet meer lekker, en twijfel je tussen vervangen, doorbouwen of toch maar vasthouden? Plan dan een gratis adviesgesprek. We kijken samen waar je nu staat, wat het echte probleem is en welke richting voor jouw situatie het meest oplevert. Geen verkooppraatje, gewoon scherp meedenken.