Software die je bedrijf draaiende houdt, maar die je niet zelf hebt gebouwd: op een dag word je daar verantwoordelijk voor. De ontwikkelaar die het maakte is gestopt, het bureau reageert niet meer, of de freelancer is simpelweg verdwenen. En jij zit met een systeem dat moet blijven werken en eigenlijk ook nog doorontwikkeld moet worden.
Dit is vaker regel dan uitzondering. Software overnemen, weer onder controle krijgen en verder ontwikkelen is precies het soort werk waarvoor je een ontwikkelaar inschakelt. Dit stuk is hoe ik zo’n overname zou aanpakken, en wat je nodig hebt om de overdracht soepel te laten verlopen.
Wanneer overnemen aan de orde is
De situaties lijken op elkaar:
De ontwikkelaar is gestopt. Iemand bouwde jarenlang jouw software en is nu met pensioen, van baan gewisseld of om andere redenen weg. De kennis zat grotendeels in één hoofd.
Het bureau is onbereikbaar of te duur geworden. De software werkt, maar elke wijziging duurt lang, kost veel of blijft liggen. Je wilt naar iemand die sneller schakelt.
De freelancer is verdwenen. Het project is half af, of net opgeleverd, en degene die het bouwde neemt de telefoon niet meer op.
Je erfde het gewoon. Bij een overname, fusie of het vertrek van een collega kreeg je software in je schoot geworpen die niemand meer echt kent.
In al deze gevallen is de vraag dezelfde: kan iemand dit overnemen zonder dat het bedrijf stilvalt?
Wat overnemen echt inhoudt
Het lastige aan overnemen is zelden de programmeertaal of het framework. Dat is te leren. Het lastige is dat je een systeem binnenstapt dat door iemand anders is bedacht, vaak zonder documentatie, en dat je moet begrijpen voordat je het veilig kunt aanpassen.
Concreet komt er meestal dit op tafel:
Toegang. Broncode, servers, domeinnamen, database, externe accounts en API-sleutels. Verrassend vaak is niet alles compleet of ligt het verspreid.
Het weer draaiend krijgen. Software die alleen op de laptop van de vorige ontwikkelaar draaide, moet eerst reproduceerbaar te bouwen en te starten zijn. Zonder dat kun je niets veilig veranderen.
De impliciete kennis. Bedrijfsregels die nergens staan, randgevallen die ooit voor één klant zijn toegevoegd, en gedrag waar mensen onbewust omheen werken. Die kennis moet boven water voordat je die per ongeluk kwijtraakt.
Mijn aanpak
Ik ga niet meteen nieuwe functionaliteit bouwen. De eerste stappen zijn saai, maar cruciaal:
- Reproduceerbaar draaien. Ik zorg dat de software te bouwen en te starten is zonder de oorspronkelijke ontwikkelaar, en leg vast hoe.
- Vastleggen wat er is. Waar welke functionaliteit zit, welke onderdelen met elkaar praten, en welke aannames erin zitten. Waar het kan schrijf ik karakteriseringstests: tests die het huidige gedrag vastpinnen, zodat ik zie wanneer een wijziging iets breekt.
- Kleine, veilige stappen. Pas als het fundament er ligt, begin ik met wijzigen. Klein, getest, en met een werkende versie op elk moment. Geen grote herschrijving waarvan je maanden niets ziet.
- Documenteren onderweg. Wat ik leer, leg ik vast, zodat de kennis dit keer niet weer bij één persoon blijft hangen.
Zo hoef je niet te kiezen tussen blijven hangen in de oude situatie en alles overhoop gooien. De software blijft werken terwijl hij weer van jou wordt.
Wat je nodig hebt om over te dragen
Hoe soepel een overname verloopt, hangt vooral af van wat je kunt aanleveren. Handig om alvast te verzamelen:
- De broncode, of toegang tot de repository (bijvoorbeeld GitHub of GitLab).
- Toegang tot de hosting en servers waar de software draait.
- De domeinnamen en DNS.
- Accounts en sleutels van externe diensten: betaalproviders, mailservices, API’s.
- Eventuele documentatie, ook als het maar een paar losse notities zijn.
- Idealiter een laatste overdrachtsgesprek met de vorige ontwikkelaar.
Heb je niet alles? Dat hoeft geen probleem te zijn. Ontbrekende stukken maken de eerste fase vooral wat meer speurwerk; onmogelijk is het zelden.
Overnemen of opnieuw bouwen?
Niet elke overname is het waard. Soms is de code zo bros of zo vast aan verouderde technologie dat verder bouwen duurder wordt dan opnieuw beginnen. Meestal is dat niet zo: bestaande software vertegenwoordigt jaren aan bedrijfslogica die je niet zomaar weggooit.
Mijn uitgangspunt is doorontwikkelen waar het kan, en pas opnieuw bouwen als het echt niet anders kan. Wat in jouw geval verstandig is, zeg ik pas nadat ik de code heb gezien. Een eerlijk antwoord is soms “dit kun je prima nog jaren doorontwikkelen”, en soms “hier ben je op termijn goedkoper uit met een nieuwe basis”.
Zit jij in deze situatie?
Heb je software die door moet, maar is degene die hem bouwde weg of onbereikbaar? Neem contact op voor een vrijblijvend gesprek. Ik kijk graag eerst mee voordat je ergens aan vastzit.