Software maken met een vuistbijl

17 oktober 2011

Veel ontwikkelaars in onze branche schrijven hightech software, maar zijn wat betreft hun editors blijven steken in het stenen tijdperk van de computerindustrie. Ze gebruiken vaak een ouderwetse teksteditor zoals VI of Notepad++. Die bieden wel wat ondersteuning zoals syntaxcontrole, maar kunnen in vergelijking met een moderne integrated development environment (IDE) toch als vuistbijl worden beschouwd.

We weten allemaal dat software in de hightech-elektronica-industrie een sleutelrol speelt, en dat veel kennis en IP in die software opgesloten liggen. Daarmee wordt het belang van de software steeds groter, evenals de behoefte eraan. Het gevolg: we moeten steeds sneller steeds meer software opleveren.

Dat leidt tot herziening van processen: organisaties ontwikkelen hun software in efficiëntere processen (Agile, Scrum) en kopen ook steeds meer software in, hetzij als compleet product, hetzij als uitbesteed maatwerk. De ontwikkelorganisatie verandert daarmee steeds meer in systeemintegrator. Voor de programmeurs van zo’n organisatie worden de integratie en het onderhoud (voor zover niet ook uitbesteed) van de code een steeds belangrijker deel van hun takenpakket.

Met moderne tools zijn behoorlijke efficiëntie- en effectiviteitswinsten te boeken. Toch blijven ontwikkelaars zich vastklampen aan hun prehistorische vuistbijl. Argumenten om ze te blijven gebruiken, variëren van ‘we werken hier allemaal met VI’ tot ‘ik kan er razendsnel code mee schrijven’. Ongetwijfeld waar, maar is dit nog wel doorslaggevend voor de hedendaagse softwareontwikkeling? In de praktijk is een ontwikkelaar, ook als die echt ontwikkelt, het grootste deel van zijn tijd bezig met het navigeren door bestaande code en het aanpassen (refactoren) daarvan.

Juist bij dat laatste schiet de ondersteuning van een teksteditor vaak tekort. Refactoren betekent namelijk dat namen van functies of variabelen veranderen, of dat hele functies worden losgetrokken uit bestaande functies. Dit zijn wijzigingen die op meerdere plekken in de software tot andere aanpassingen leiden, en handmatig zoeken, aanpassen, opslaan en kopiëren kan dan een tijdrovend en foutgevoelig karwei worden. Dit wordt nog erger als onder de tijdsdruk van een project kwaliteitsverbeteringen in de code worden uitgesteld.

IDE’s zijn in dit soort gevallen veel efficiënter. Die bieden ondersteuning bij het automatiseren van refactoring, naast functies om over hele projecten heen te zoeken en software automatisch te compileren en te testen. Met andere woorden: ze ondersteunen de activiteiten die veel belangrijker zijn dan code schrijven.

Het gemakkelijk kunnen vinden van klassen en functies is niet alleen handig maar ook erg nuttig. Programmeurs zijn van nature lui en zullen doorgaans kiezen voor de gemakkelijkste optie om een probleem op te lossen. Met een IDE is het zoeken en hergebruiken van bestaande functionaliteit makkelijk. Met een teksteditor niet, dus is het veel aanlokkelijker om de gevraagde functionaliteit daar gewoon nog eens te programmeren. Gebruik van ouderwetse tooling wakkert het not invented here-syndroom aan: ontwikkelaars zijn al gewend alles ‘zelf te doen’, wat maakt dat het bouwen op software van een ander niet voor de hand ligt. Ter illustratie: bij een bedrijf werden eens na een simpele zoektocht dertig (!) verschillende implementaties van een simpele afrondfunctie gevonden.

Het is niet makkelijk om een ontwikkelorganisatie over te laten stappen op de modernste gereedschappen. Ontwikkelaars zijn gewend en gehecht aan hun huidige editors en managers zijn bang voor de risico’s van verandering en voor hogere licentiekosten. Toch doet een organisatie die hightech software ontwikkelt en hecht aan de kwaliteit van haar product er in deze tijd goed aan het gebruik van de vuistbijl te heroverwegen.

Angelo Hulshout en Egbert Teeselink

Terug naar overzicht