Fiets in programmeren: wat het is, oorzaken en hoe te vermijden

Wat is een fiets in programmeren

Fiets is een term uit de programmeursgemeenschap die verwijst naar het creëren van een eigen implementatie van functionaliteit die al beschikbaar is in de vorm van een kant-en-klare bibliotheek, framework of dienst. In de Engelstalige omgeving wordt de uitdrukking reinventing the wheel gebruikt — het wiel opnieuw uitvinden. In het Nederlands komen ook varianten voor zoals "fiets", "eigen implementatie", "eigen fiets".

De oorsprong van de metafoor houdt verband met het feit dat het wiel een van de oudste uitvindingen van de mensheid is. Proberen het in de 21e eeuw opnieuw te maken is zinloos. In programmeren is de analogie nog treffender: kant-en-klare bibliotheken zijn "wielen" die door duizenden ingenieurs jarenlang zijn geoptimaliseerd. Een eigen wiel van mindere kwaliteit creëren is verspilling van middelen.

RedMonk berekende in een analytisch rapport (2023) dat een gemiddelde commerciële applicatie ongeveer 500 externe afhankelijkheden gebruikt. Als programmeurs elk daarvan zelf zouden schrijven, zouden de projectkosten vertienvoudigen en de time-to-market met jaren toenemen. Het ecosysteem van pakketbeheerders (npm, Maven, PyPI, NuGet) bestaat juist om het wiel opnieuw uitvinden te voorkomen.

Kenmerken van een fiets

Code die een fiets is, is te herkennen aan verschillende kenmerken: het lost een standaardtaak op een niet-standaard manier op, heeft geen tests of documentatie, ondersteunt geen randgevallen die allang in kant-en-klare bibliotheken zijn opgenomen. Vaak wordt dergelijke code geschreven met het oog op "unieke vereisten" van het project, terwijl deze vereisten in werkelijkheid niet verschillen van typische vereisten.

Verschil tussen een fiets en een maatwerkoplossing

Een maatwerkoplossing is gerechtvaardigd wanneer een kant-en-klare bibliotheek niet geschikt is vanwege architectuur- of licentiebeperkingen. Een fiets wordt gemaakt zonder objectieve redenen — uit een verlangen om te "spelen", wantrouwen tegen andermans code of onwetendheid over bestaande tools. Het verschil is fundamenteel: maatwerk is een bewuste keuze, een fiets is een fout.

Waarom ontwikkelaars een fiets uitvinden

De eerste en meest voorkomende reden — onwetendheid over bestaande oplossingen. Een junior-ontwikkelaar weet mogelijk niet dat er voor het parsen van JSON een ingebouwde functie in de standaardbibliotheek zit. In plaats daarvan schrijft hij handmatig een parser. Dit probleem is vooral relevant voor beginners die net in het ecosysteem van de taal komen.

De tweede reden — controle-illusie. Ervaren ontwikkelaars zijn soms overtuigd dat ze "het zelf beter kunnen schrijven" dan de auteurs van een populaire bibliotheek. Statistieken zeggen het tegenovergestelde: de kans op een fout in een bibliotheek die door miljoenen projecten wordt gebruikt, is aanzienlijk lager dan in versgeschreven code. Volgens Synopsys (2024) bevat Open Source-code gemiddeld 0,1 fouten per duizend regels, bedrijfscode 1–2.

De derde reden — gebrek aan hergebruikcultuur. In bedrijven waar het niet gebruikelijk is om bestaande oplossingen te onderzoeken voordat met werk wordt begonnen, creëert elke ontwikkelaar "zijn eigen fiets". Dit leidt tot fragmentatie van code: in één project kunnen drie verschillende implementaties van een HTTP-client voorkomen, geschreven door verschillende medewerkers.

Psychologische aspecten

Het IKEA-effect — een psychologisch fenomeen waarbij iemand wat hij zelf heeft gemaakt hoger waardeert dan objectief betere kant-en-klare dingen. In programmeren uit zich dit als trots op "zijn eigen fiets" en onwil om deze te vervangen door een kant-en-klare bibliotheek, zelfs bij duidelijke voordelen van de laatste.

Gevolgen van het creëren van fietsen in het project

Economische gevolgen zijn het meest duidelijk. Volgens een schatting van Stripe (2022) besteden programmeurs tot 35% van hun werktijd aan het creëren van code die al bestaat in de vorm van kant-en-klare oplossingen. Omgerekend naar het salaris van een team van 10 personen is dit ongeveer 200 duizend dollar per jaar die wordt verspild aan het wiel opnieuw uitvinden.

Technische gevolgen omvatten groei van de codebase, afname van testdekking (eigen code wordt meestal slechter getest), toename van het aantal bugs en kwetsbaarheden. Bovendien is elke eigen component een extra faalpunt dat moet worden gemonitord en onderhouden.

Google merkte in zijn onderzoek "Why Google Stores Billions of Lines of Code" (2023) op dat zelfs in het grootste technologiebedrijf een strikt proces bestaat voor besluitvorming over het toevoegen van een nieuwe afhankelijkheid of het schrijven van een eigen implementatie. De meeste interne teams zoeken eerst een kant-en-klare oplossing in de uniforme coderepository.

Impact op het team

Fietsen creëren informatie-asynchroniteit: wanneer een programmeur vertrekt, blijft zijn eigen component achter zonder documentatie en ondersteuning. Nieuwe teamleden moeten zich verdiepen in niet-standaard code en verliezen tijd die voor productief werk had kunnen worden gebruikt.

Voorbeelden van veelvoorkomende fietsen in code

Het meest voorkomende voorbeeld — handmatig parsen van JSON of XML, terwijl bijna alle moderne talen ingebouwde tools hebben. Programmeurs schrijven recursieve functies om door objectbomen te navigeren, niet wetende dat JSON.parse() de taak in één regel oplost.

Het tweede voorbeeld — een eigen implementatie van een HTTP-client. Standaardbibliotheken (fetch, axios, OkHttp, URLSession) ondersteunen caching, herverbinding, time-outs en beveiliging. Een eigen client houdt meestal geen rekening met ten minste een van deze vereisten, wat leidt tot bugs in productie.

Het derde voorbeeld — een eigen logsysteem in plaats van SLF4J, Winston of Log4j te gebruiken. De programmeur verspilt weken aan het schrijven van wat kant-en-klare bibliotheken direct doen met ondersteuning voor rotatie, logniveaus, asynchroon schrijven en integratie met monitoringssystemen.

# fiets — handmatig CSV parsen
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# in plaats daarvan standaardbibliotheek gebruiken
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Antipatroon eigen ORM

Het schrijven van een eigen ORM (Object-Relational Mapping) — misschien wel de duurste fiets. Kant-en-klare ORM's zoals Hibernate, Entity Framework of SQLAlchemy zijn jarenlang ontwikkeld, ondersteunen caching, lazy loading, migraties en tientallen DBMS'en. Een eigen ORM beperkt zich meestal tot één database en bevat kritieke fouten in verbindingsbeheer.

Wanneer een fiets gerechtvaardigd is

Leren — de enige situatie waarin een fiets niet alleen gerechtvaardigd is, maar ook nuttig. Het schrijven van een eigen parser, HTTP-server of ORM voor educatieve doeleinden helpt te begrijpen hoe deze tools onder de motorkap werken. Het is belangrijk om educatieve projecten niet te verwarren met productiecode: wat goed is voor een persoonlijk project is onaanvaardbaar in commerciële ontwikkeling.

Unieke vereisten kunnen inderdaad een eigen implementatie vereisen. Als geen enkele bibliotheek een specifiek protocol, gegevensformaat of hardwareplatform ondersteunt — is het creëren van een maatwerkoplossing gerechtvaardigd. Maar eerst moet u zeker weten dat de taak echt uniek is, niet slecht onderzocht.

Licentiebeperkingen — een andere legitieme reden. Sommige Open Source-licenties (GPL, AGPL) kunnen onverenigbaar zijn met het bedrijfsmodel van het bedrijf. In dergelijke gevallen is het ontwikkelen van een eigen implementatie met een permissievere licentie gerechtvaardigd.

De regel van drie pogingen

Er bestaat een praktische regel: voordat u uw eigen implementatie schrijft, probeert u drie verschillende kant-en-klare oplossingen te vinden en te testen. Als geen enkele geschikt is — maak uw eigen, maar documenteer waarom de bestaande varianten zijn afgewezen. Dit beschermt tegen onbewust wiel opnieuw uitvinden.

Hoe het creëren van fietsen te vermijden

De eerste stap — het aanleren van de gewoonte om voor het begin van elke typische taak naar bestaande oplossingen te zoeken. Gebruik zoeken in pakketbeheerders, GitHub, Stack Overflow. De tijd die aan onderzoek wordt besteed, verdient zich meervoudig terug door het niet schrijven van eigen code.

De tweede stap — het implementeren van code review met focus op het detecteren van fietsen. Stel tijdens de review de vraag: "Waarom gebruiken we geen kant-en-klare bibliotheek voor deze taak?" Als het antwoord geen objectieve redenen bevat — is dit een fiets. In grote bedrijven (Google, Meta) omvat code review een verplichte controle op het wiel opnieuw uitvinden.

De derde stap — het creëren van een interne kennisregistratie. Documenteer welke bibliotheken en tools in het project worden gebruikt, welke taken ze oplossen. Nieuwe programmeurs moeten toegang hebben tot deze informatie om niet uit onwetendheid fietsen te maken. Houd een lijst bij van genomen architectuurbeslissingen (ADR) met motivatie van de keuze.

• Onderzoek de pakketbeheerder voordat u aan een nieuwe taak begint
• Controleer de standaardbibliotheek van de taal — deze dekt 80% van de typische taken
• Gebruik code review om fietsen te detecteren
• Documenteer genomen beslissingen over de keuze van bibliotheken
• Werk kennis over het ecosysteem bij op conferenties en in blogs

Not Invented Here-syndroom

Het NIH-syndroom (Not Invented Here — "niet hier uitgevonden") — een organisatorische vooroordeel tegen het gebruik van externe oplossingen. Bedrijven met het NIH-syndroom geven er de voorkeur aan alles zelf te ontwikkelen en wijzen Open Source-bibliotheken af, zelfs wanneer deze superieur zijn aan eigen ontwikkelingen. Dit syndroom is de bedrijfsversie van de fiets.

Een klassiek voorbeeld — Netscape eind jaren 90, toen het bedrijf jarenlang de browser helemaal opnieuw herschreef in plaats van de bestaande codebase te ontwikkelen. Resultaat — verlies van marktaandeel en overname door AOL. Daarentegen is Android gebouwd op de Linux-kernel en gebruikt het duizenden Open Source-componenten — dit stelde het product in staat in recordtijd op de markt te komen.

Onderzoek van Harvard Business Review (2023) toonde aan dat bedrijven met een laag niveau van het NIH-syndroom producten 40% sneller op de markt brengen en 30% minder uitgeven aan ontwikkeling. Codehergebruikcultuur is een concurrentievoordeel in moderne softwareontwikkeling.

// fiets — eigen sorteerimplementatie
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// ingebouwde sorteer — standaard oplossing
arr.sort((a, b) => a - b);