Digitalisering van ingenieurswerk

Digitalisering van ingenieurswerk is lastige materie. Enerzijds heb je de snel beter wordende modellen; Plaxis, Mike21, Delft3D en vele andere. Ik heb in 30 jaar tijd de interfaces ingrijpend zien verbeteren en rekentijden fors zien dalen. Het gevolg is dat we deze tools steeds beter kunnen inzetten voor het ontwerp. En waar ik zelf nog ben opgeleid met de inktpen en de tekentafel zijn we, via AutoCAD, aangekomen bij de 3D-modellen.
Anderzijds is het gebruik van Excel hardnekkig. Blijkbaar is er een blijvende behoefte aan overzichtelijke kleine sommetjes. Ik ging op zoek naar verbeterde werkmethoden voor dit deel van ons werk. Lees hier mijn resultaten.

(Foto gedownload van LinkedIn Sales Navigator via Pexels)

Excel als veel gebruikt programma voor kleine sommetjes. Zelf heb ik het voor technische berekeningen al lang geleden uitgebannen. Mijn gereedschap was het jarenlang het progamma MathCAD; het beste te omschrijven als een formule-editor die echt rekent. De laatste jaren zag ik MathCAD echter ook uit de tijd raken; in een tijd van overvloedig beschikbare data schiet MathCAD tekort. En dan hebben we Python. De potentie ervan is enorm; de toepassing niet altijd evident of probleemloos. De successen zijn wisselend.

Afscheid van MathCAD
Toen ik bijna twee jaar geleden startte met mijn eigen onderneming had ik al behoorlijk vlieguren in Python gemaakt. Dus ik stond voor een keus; koop ik een licentie voor MathCAD of ga ik “Cold Turkey” en geheel over op Python. Dat laatste heb ik gedaan. Een goede vervanger is Jupyter Notebooks, documenten waarin je korte stukjes Python code combineert met toelichtingen en zo komt tot een totaal adviesdocument. 

Maar ik had het gevoel dat er meer in zat. Simpelweg MathCAD vervangen door Jupyter Notebooks was me niet genoeg. Parallel aan mijn eerste opdrachten (dank aan mijn opdrachtgevers!!) ging ik op zoek naar manieren om ingenieurswerk beter te digitaliseren. En dan vooral de vroege projectfasen waarin we "zoekende" zijn en panklare programma's minder goed bruikbaar zijn. Mijn eigen wetenschappelijk onderzoek kreeg een extra rol als proeftuin waarin ik nieuwe werkwijzen testte. En ik ging lezen. Boeken van ervaren software ingenieurs. Dikke en zeer slecht geschreven boeken en dunne boekjes zo tjokvol goede ideeën dat ik er jaren mee voort kan. Al experimenterend ontstonden er enkele leidende principes. 

Luiheid is een deugd
Het eerste principe is lui programmeren. Ik nam me voor om alles wat ik programmeer nog maar 1x te programmeren. Dat klinkt evident maar is het niet; in ons werk gebruiken we veel formules en die worden telkens opnieuw ingeklopt of, en dat is nog veel gevaarlijker, met een “knip-en-plak” actie overgenomen van het ene document naar het andere. Daarbij ontstaan gemakkelijk fouten die niet altijd naar boven komen bij collegiale controle. Door alles nog maar 1x te programmeren ontstaat overzicht over wat er in de bibliotheek zit en ben je ontslagen van deze kopieerfouten. Maar daarmee ben ik er niet, want lui programmeren vergt dat je code inricht op hergebruik; dat werd het tweede leidende principe. 

Herbruikbare code in packages
Hergebruik van code krijgt in Python vorm door het maken van “packages”. Een package wordt met een “import” statement beschikbaar gemaakt voor je project. Het kunnen gebruiken van packages is een belangrijke vaardigheid voor de Python gebruiker. Zou het niet mooi zijn als jouw eigen slimme functies beschikbaar zijn in een package? En liefst met van die mooie toelichtingen erbij die het leven zoveel makkelijker maken. Ik dook erin en vond de manieren om packages te maken, te documenteren en de documentatie zichtbaar te maken voor de gebruiker. Ik had er al snel profijt van; het is niet te bevatten hoeveel je vergeet in een paar maanden tijd. Regelmatig las ik mijn eigen documentatie terug om mijn eigen code goed te kunnen gebruiken.

Maar weer knaagde er iets. Want hoe weet ik of mijn mooie herbruikbare en gedocumenteerde code wel correct is.... en blijft?

Blijvend aantoonbare kwaliteit van code
Veel van ons werk is het overnemen van ontwerpformules uit handboeken. Een verstandige ingenieur controleert zo'n geprogrammeerde formule altijd met een handberekening. Onze wereld is vol van exponenten, logaritmen en ingewikkelde breuken en een foutje is zo gemaakt. Nieuwe code controleerde ik daarom al met behulp van handberekeningen. 

Als je het goed wil doen, dan moet je bij iedere toepassing opnieuw controleren of je code nog steeds overeenkomt met je handberekening. Dat is tijdrovend, geestdodend en heeft het risico dat er toch iets wordt gemist. Wat zou het mooi zijn als de vergelijking van code en handberekening door de software kan worden overgenomen. En dat blijkt te kunnen!

Mijn zoektocht bracht me bij geautomatiseerde Unit-tests. In de IT-wereld gemeengoed; in onze wereld (nog) niet. Handberekeningen zette ik om in testcases en voortaan kon ik met een druk op de knop een package controleren. Het derde principe werd dus altijd gecontroleerde code-kwaliteit met behulp van geautomatiseerde unit-tests. 

Als je testen centraal stelt in je code-ontwikkeling, dan ben je aangekomen bij "test-driven development". De IT-wereld lijkt nog te debatteren over de meerwaarde ervan; zelf ben ik al overtuigd. Test-driven development is het proces waarin mijn Python-code lui, herbruikbaar en gecontroleerd tot stand komt.

Werkt het?
In mijn eigen proeftuin zag ik mijn eigen effectiviteit toenemen. Werkzaamheden die voorheen veel tijd en zweetdruppels kostten kon ik nu met enkele eigen functies snel uitvoeren. Het draaien van alle “unittests” voorafgaand aan een oplevering werd snel een gewoonte.

En natuurlijk leverde een test ook weleens een foutmelding op. Ik merkte dat ik dan heel snel de fout kon lokaliseren tot enkele regels code; dat was voorheen veel moeilijker. Kortom, ik merkte de meerwaarde van mijn gevonden aanpak.

Nu is het tijd om mijn ervaringen te delen en dat doe ik op twee manieren. Ten eerste is een deel van mijn code, inclusief testcases, openbaar beschikbaar op bij HVEC-lab, te vinden op github. U kunt hiervan direct gebruik maken en bent daarmee ontslagen van een hoop programmeerwerk. 

Ten tweede draag ik mijn werkwijze uit in de vorm van trainingen. Ik ontwikkelde cursusmodules voor verschillende doelgroepen, van beginnende programmeur tot projectmanager. De eerste trainingen lopen nu; de eerste ervaringen zijn positief. U hoort er binnenkort meer over.