Waarom je oude software moet weggooien (en hoe te herontwikkelen)

Jep, er zijn veel redenen waarom je verouderde software zou moeten herontwikkelen. Dit is echter niet zo eenvoudig als het klinkt. Hier zijn enkele tips om een aantal gebruikelijke valkuilen bij herontwikkeling van software te vermijden.

Maar eerst, waarom zou je opnieuw beginnen, een oud systeem volledig weggooien en de software vanaf nul herontwikkelen? Het IT-landschap verandert enorm snel. Sneller dan de meeste andere industrieën. Denk maar eens terug aan de software die je 10 jaar geleden gebruikte. En denk dan nog een stapje verder terug, software van 20 jaar geleden, 4 jaar vóór de eerste iPhone. Veel bedrijven hebben mooie software gebouwd en hebben deze jarenlang netjes onderhouden en doorontwikkeld. Echter, die software is meestal nog steeds gebaseerd op een verouderde basis. Op een bepaald moment is het dan vaak beter om met een schone lei te beginnen en de software te herontwikkelen op basis van huidige technologie.

Naast verouderde software is er ook een hele andere categorie software die uiteindelijk opnieuw ontwikkeld zal moeten worden. De in-house gebouwde "tijdelijke" oplossingen. Dat programmaatje dat een van engineers geschreven heeft om wat documenten te automatiseren, of die tijdelijke Excel-sheet die klein begon, maar nu de primaire processen van je bedrijf ondersteunt. Dit zijn handige en snelle manieren om te automatiseren of te innoveren, maar zodra meer mensen het gaan gebruiken, of wanneer de maker te druk is om het te onderhouden, heb je een robuustere oplossing nodig.

Oke, je gaat de software herontwikkelen. Je hebt de oude software als voorbeeld. Dus wat is er zo ingewikkeld aan? Hierbij een aantal vaak voorkomende fouten:

"We willen dat het hetzelfde doet als de oude software." - Ja, je bent gewend aan de oude -comfortabele- software, maar het is een gemiste kans als je de huidige functionaliteit niet evalueert en de nieuwe mogelijkheden van moderne technologie niet benut. Daarnaast is je bedrijf waarschijnlijk ondertussen ook veranderd, dus zorg ervoor dat de nieuwe software die veranderingen goed ondersteunt. Je gebruikers moeten misschien hun werkwijze iets aanpassen, of wennen aan een nieuwe interface, maar dat is uiteindelijk de moeite zeker waard.

"Requirements opstellen? Kijk gewoon naar de oude software." – Het is verleidelijk om "tijd te besparen" en gewoon te beginnen met herontwikkeling op basis van een snelle blik op de oude software. Kritieke details en belangrijke use cases kunnen zo echter vergeten worden, vooral wanneer het ontwikkelteam de oude software niet in detail kent. Neem de tijd om een overzicht te maken van de oude functionaliteit, en vergeet om met de huidige gebruikers in gesprek te gaan om zo te ontdekken hoe zij werkelijk met de software werken en welke "oplossingen" zij hebben bedacht om met tekortkomingen in het systeem om te gaan.

"We demonstreren het later wel aan de gebruikers.” - Oké, dit geldt voor alle softwareprojecten, maar vooral bij herontwikkeling. Het is belangrijk om de gebruikers betrokken houden. Je lanceert namelijk niet zomaar een nieuw systeem. Je vervangt iets waar ze aan gewend zijn. Om weerstand te verminderen en om het nieuwe systeem succesvol te maken, betrek je de gebruikers gedurende het hele project. Je ontwikkelt waarschijnlijk toch al Agile, dus waarom zou je de feedback niet gebruiken?

In de afgelopen jaren hebben we bij SST Software veel herontwikkelingsprojecten uitgevoerd. Hoewel herontwikkeling niet zo verschillend zou moeten zijn van het "gewoon" ontwikkelen van een nieuw systeem, is dit in werkelijkheid wel het geval. Je hebt te maken met andere verwachtingen en risico's. Mits op de juiste manier aangepakt, is het zeker de moeite waard en zorgt het ervoor dat je klaar bent voor de toekomst.