Onderstaande tekst is geanonimiseerd. De exacte namen van mensen en bedrijven zijn niet relevant. De blog is geschreven om lessons learned te delen. De telefoon gaat. Het is eind september 2022. Ik neem op en ik hoor de stem van een oude bekende. Laten we hem Jan noemen. Na het gebruikelijk “he, hoe gaat het nu met jou?” wordt duidelijk waarom Jan belt. Hij heeft voor zijn bedrijf een IT platform laten ontwikkelen door “een vriend met vier Indiërs in India”. Er is inmiddels enorme ruzie ontstaan tussen de partijen en mogelijk dat het een rechtszaak wordt. Ondertussen dreigt die “vriend” om de stekker eruit trekken terwijl het platform de life line van het bedrijf van Jan is. “Jij hebt toch een IT bedrijf? Kun jij het dan overnemen?” Waarbij gezegd dient te worden dat het platform wel al live was maar vele hiccups had en er nog een enorme lijst aan functionele wijzigingen, kleine en hele grote, klaar lag.

Dat vind ik nou leuk he! Iemand in nood, en dan ook nog een oude bekende, helpen. En iets doen waar veel bedrijven huiverig voor zijn: een door een ander gebouwd platform overnemen, zonder ook nog maar iets te weten van de kwaliteit van die code, van de aanwezige documentatie, van de ingebouwde logging en de geïmplementeerde monitoring. Yes, DAT is een gave uitdaging!

Spoiler alert: de code (Python/Django, vue.js, JavaScript, CSS, HTML) bleek van een erbarmelijk spaghettiniveau te zijn, er was geen documentatie, er was geen ingebouwde logging, er was geen monitoring en Jan’s bedrijf was niet ervaren in life cycle management van een maatwerkplatform. Maar dat mocht de pret niet drukken natuurlijk 🙂

Wij gingen aan de slag. Aanvankelijk stiekem nog, want de ruzie met de “vriend” van Jan liep nog volop en die mocht van niks weten. Die zou in zijn woede dan wel eens kunnen besluiten echt de knop on te draaien, de boel uit te zetten. We moesten voorlopig nog “onder de radar” acteren.

Onze eerste uitdaging was om het team samen te stellen dat de klus ging klaren. Het was nou niet dat we een hele trits aan Python/Django, vue.js en JavaScript programmeurs op de bank hadden zitten dus we moesten mensen vrij gaan spelen. Herschikken van taken en verantwoordelijkheden, nog eens goed naar de planning kijken, met mensen overleggen over overwerk, etc. The usual stuff, absoluut, maar niet iets wat in vijf minuten geregeld is.

Het team hebben we opgezet volgens het devops principe zodat we, zodra we de code onder de knie zouden hebben, zowel het operationeel beheer van het platform konden uitvoeren als ook verbeteringen en nieuwe functionaliteit aan het platform konden toevoegen.

Natuurlijk hadden we de logingegevens nodig voor AWS, waar alles draaide. Jan had die niet en moest ‘m opvragen bij zijn “vriend”. Ook wilden we, natuurlijk, de broncode hebben. Die had Jan ook niet. Weer opgevraagd, en met wat horten en stoten kwam die beschikbaar. Stukje bij beetje konden we ons invreten.

Al snel hadden we door dat de code niet helemaal voldeed aan ons kwaliteitsniveau. En dan druk ik me erg voorzichtig uit. Het zij zo. We moesten het er toch mee doen. We zagen op diverse plekken dat het qua beveiliging van API calls e.d. niet goed geregeld was, Dat gingen we sowieso meteen repareren. Ook ontdekten we hier en daar wat backdoors. Stukjes code die naar onze mening niet waren ingebouwd omdat het functioneel of technisch nodig was maar die wellicht waren ingebouwd om in het geval van een ruzie ergens toch nog bij te kunnen. Hopsakee, die stukken code moesten eruit. Best boeiend om dan in andermans spaghetti te beginnen te snijden, en proefondervindelijk te gaan ondervinden waar de slierten allemaal heen lopen …

Het moet gezegd: Jan had begrip voor het feit dat we tijd nodig hadden. Okee, initieel zei hij “dat kost jullie twee weken toch?” Logisch, niets menselijks was Jan vreemd J Maar nadat ik van de tafel gerold was van het schuddebuikende lachen had Jan door dat het eerder twee maanden zou zijn. Die tijd kregen we. Wat Jan er overigens niet van weerhield wekelijks aan te geven dat er nog zoveel functionele wijzigingen gedaan moesten worden, dat er haast bij was, en … Afijn, een enthousiaste opdrachtgever, wat wil je nog meer?

Al heel snel besloten we om alles vanaf scratch af aan opnieuw op te bouwen. Althans, niet dat we complete code gingen herschrijven want dat was onbegonnen werk. Maar we zijn wel de broncode regel voor regel door gaan lopen, en soms wat aan gaan passen. Wat structuur in de spaghetti aanbrengen kon geen kwaad. En we wilden er wel zeker van zijn dat we het platform van A tot Z zouden begrijpen voordat we het in beheer namen en de doorontwikkeling ter hand zouden gaan nemen. Door het reverse engineeren kwamen we er achter dat de “vriend” niet alle code aan Jan had overgedragen. Grom! De ontbrekende code werd alsnog aangeleverd.

We hebben de AWS omgeving waar het platform op draaide helemaal opnieuw opgezet. Zo konden we er zeker van te zijn dat alles secure was, dat er in de infrastructuur geen back doors ingebouwd waren en dat er niet nog ergens een verborgen procesje zou draaien dat …

Ter voorbereiding van de go-live van de enigszins opgeschoonde code op de door ons beheerde AWS infrastructuur hebben we een gedetailleerd cut-over plan opgesteld om de hele omgeving gecontroleerd te migreren met minimale outage. Tussen Kerst en Oudjaar 2022 was het zover. Het platform draaide, met alles erop en eraan, in een nieuwe AWS omgeving, met de bestaande data die gemigrered was uit de oude database. Toch even een klein momentje van vreugde en dan … hopsakee: aan de slag met de change requests. Een lijst van meer dan tachtig items. Maar how about de prioriteiten in die lijst? Die waren niet duidelijk, dus daar moesten we wat aan doen.

Hoe dat verder liep? Daar komt volgende week een nieuwe blog over.