Wim Hendriksen was softwaremanager bij ASML en lector bij Fontys Hogeschool ICT. Nu beziet hij de ontwikkelingen vanachter de geraniums.
Softwareontwikkelaars vergelijken zichzelf graag met bouwkundig architecten en bouwvakkers: mooie nieuwe gebouwen verzinnen en realiseren. Daar schreef ik al over in de vorige Bits&Chips: ‘Schaam je voor legacy’. Slechts weinig softwareontwikkelaars krijgen echter de kans om iets van de grond af te bouwen; de meeste moeten voortborduren op het nobele werk van hun voorgangers.
Misschien is daarom de overeenkomst met stedenbouwkundigen beter. Die moeten ook altijd rekening houden met wat er al staat. Zowel bij de herinrichting van een stuk stad als bij een grote ombouwactie in de software leidt het inpassen van het nieuwe in het oude tot hoge kosten en veel frustratie. In dit stuk wil ik vooral een hart onder de riem steken bij ‘die andere softwareontwikkelaars’, de helden die het oude in leven en bij de tijd houden.
Stel je voor dat Prorail he-le-maal klaar is met het sporenplan zoals dat nu in Nederland ligt en roept dat het na 180 jaar aanmodderen helemaal opnieuw moet. De Prorail-architect verzint een aantal verdiept aangelegde parallelle sporen evenwijdig aan de Noordzeekust, wat dichter bij elkaar in de Randstad, wat minder in het oosten van het land. Dwars daarop een aantal parallelle oost-westsporen, wat meer in het midden van het land, wat minder in het noorden en zuiden. Alle kruisingen natuurlijk ongelijkvloers.
De voordelen van die nieuwe architectuur zijn immens: nieuwe dienstregelingen maken is nu een fluitje van een cent geworden, de verkeersleiding is een stuk gemakkelijker, er zijn geen storingsgevoelige wissels onderweg, materieel slijt een stuk minder omdat er geen bochten meer zijn en stations liggen niet meer onhandig midden in de binnenstad. Kortom: morgen beginnen!
Device lifecycle management for fleets of IoT devices
Microchip gives insight on device management, what exactly is it, how to implement it and how to roll over the device management during the roll out phase when the products are in the field. Read more. .
Iedereen ziet dat het onbegonnen werk is om de spoorinfrastructuur volledig op de schop te nemen, maar in de softwarewereld zijn dit soort verregaande ideeën vrij geaccepteerd. Daar vinden we dat softwaresystemen na een paar jaar versleten zijn en dat het helemaal opnieuw moet. Kunnen we meteen voldoen aan de laatste mode op software-engineeringgebied.
Misschien moeten we dat gewoon maar vergeten en accepteren dat we oude code met oudere architecturen willen blijven gebruiken in nieuwe toepassingen met nieuwe architecturen en nieuwe code. We moeten dan wel goed nadenken over hoe dat samen moet werken met nieuwe methodes en technieken. Oude software even inkapselen in een nieuw stuk en net doen of het ingekapselde blok legacy code altijd zal blijven werken, is niet de oplossing. Misschien moeten we wennen aan meerdere architecturen binnen één systeem. En leren omgaan met de verschillen in delen van het systeem.
Stel je eens voor dat je als planoloog bezig bent met een nieuwe wijk in een stad die al sinds de middeleeuwen bestaat. Er is een binnenstad met smalle straatjes en lage huisjes, hier en daar ‘verrijkt’ met een gigantische woontoren, een industriegebied en een aardig jarendertigbuurtje. Eis je dan dat de hele stad wordt aangepast aan de architectuur van jouw nieuwe wijk? Natuurlijk niet. De oude delen blijven bestaan en de nieuwe architectuur moet op een natuurlijke wijze aansluiten bij wat er al is gebouwd.
Er zijn wel enkele universele regels: voor de hoogte van viaducten, voor de breedte van rijwegen, er moeten riolering, waterleiding, elektriciteit en glasvezel worden aangelegd. Dit geldt voor nieuwe wijken, maar ook voor oude! De planoloog kan niet een stadsdeel tot legacy-wijk verklaren, er een hek omheen zetten en er dan niets meer aan doen. Infrastructurele zaken moeten goed worden vastgelegd en afgedwongen. De rest mag elke planoloog naar eigen inzicht vormgeven.
Zo moet het ook in grote softwaresystemen: er zijn softwareteams die nieuwe dingen verzinnen aan het bouwwerk en er zijn softwareteams die zorgen dat de noodzakelijke infrastructuur ook wordt uitgerold naar de oudste stukken software die in het systeem te vinden zijn. Dat laatste is een significante ontwikkelinspanning die we nooit op de lange baan mogen schuiven. De oude code moet netjes in leven worden gehouden en meegaan met de infrastructuur die nu vereist is. Ook als daarvoor voor de zoveelste keer de hele zaak overhoop moet.
Als het infrastructuursoftwareteam hoger op de apenrots woont dan het nieuwefunctionaliteitjesteam, dan heb je kans dat het nog lukt ook. Net als de Noord-Zuidlijn in Amsterdam.