Don't Skip, Hot Take

Hot take: de meeste software engineers zijn niet goed in hun werk. De standaarden binnen softwareontwikkeling liggen te laag, met echte schade voor echte mensen als gevolg. Soms komt dat door een gebrek aan vaardigheid, maar in de meeste gevallen komt het doordat software engineers hun verantwoordelijkheden niet kunnen benoemen, laat staan beschrijven of ernaar handelen. Ze richten zich op wat ze kennen, op wat anderen hun zeggen te doen, op wat ze leuk vinden om aan te werken, en blijven ondertussen zalig onbewust van hun verantwoordelijkheden voor andere delen van hun werk. Of, nog erger, negeren die bewust.

De verantwoordelijkheden van een software engineer

Hoi! Maak je geen zorgen, ondanks de beschuldigende toon van de alinea hierboven ben ik een aardig persoon en heb ik het goed bedoeld. Sterker nog, deze blog is het eerste deel van een serie blogs waarmee ik hoop jou, de lezer, te helpen om software engineering beter te begrijpen. Maar om de toekomst te verbeteren, moeten we eerst een eerlijk beeld hebben van het heden.

Ik werk nu zo’n acht jaar in softwareontwikkeling, relatief kort. In die tijd heb ik bij verschillende bedrijven gewerkt en veel projecten zien eindigen: sommige succesvol, andere meer in de categorie “crash-and-burn”. Alles bij elkaar heb ik een vrij helder beeld gevormd van wat ik denk dat de verantwoordelijkheden van een software engineer zijn, en waarom die verantwoordelijkheden niet zomaar kunnen worden doorgeschoven naar andere partijen binnen de ontwikkelketen.

Laten we beginnen met een metafoor. Stel je voor dat een arts een patiënt behandelt met een gebroken bot. Tijdens de behandeling ontdekt de arts dat de patiënt ook lijdt aan een dodelijk virus. De arts biedt echter geen levensreddende behandeling aan, omdat “noch de patiënt, noch het ziekenhuisbestuur erom heeft gevraagd”. In plaats daarvan richt de arts zich alleen op het gebroken bot. Wat gebeurt er dan? De patiënt overlijdt, en we verwachten dat de arts wordt ontslagen, aangeklaagd, of erger.

Er zijn honderden andere scenario’s te bedenken, maar in de kern verwachten we van onze artsen niet alleen dat ze de juiste medische kennis hebben, maar ook dat ze:

• proactief zijn in plaats van reactief;
• zich professioneel en ethisch gedragen;
• transparant zijn en relevante informatie kunnen uitleggen, zodat zowel de patiënt als het ziekenhuis weloverwogen beslissingen kunnen nemen;
• rekening houden met de behoeften van de patiënt én het ziekenhuis;
• verantwoordelijkheid nemen voor hun handelen, omdat zij de experts zijn.

Typen softwareontwikkelaars en hun verantwoordelijkheden

Goed, dat klinkt duidelijk genoeg. Maar hoe vertalen we dat naar de wereld van softwareontwikkeling? Om die vraag te beantwoorden, is het verstandig om eerst een belangrijk onderscheid te maken. Niet iedereen die software maakt, draagt dezelfde verantwoordelijkheden. En dan heb ik het niet over het verschil tussen product owners, scrum masters, analisten, testers of developers. Nee, ik bedoel het verschil tussen verschillende typen ontwikkelaars. Binnen de context van verantwoordelijkheden kunnen we ontwikkelaars grofweg indelen in drie brede, enigszins vage categorieën.

Allereerst is er de coder. Dat is iemand die code of scripts schrijft met een eenvoudig en duidelijk doel. Misschien gebeurt dat als onderdeel van een grotere applicatie, of misschien is het einddoel slechts één script dat één of twee keer wordt uitgevoerd. Coders zijn niet per se minder ervaren dan de andere categorieën, maar de reikwijdte van hun eindproduct is gewoon veel kleiner.

Vervolgens hebben we de programmeur. Ook zij schrijven code, maar de code is interactiever, abstracter en generieker. Meestal werken ze als onderdeel van een groter team, of er wordt in elk geval aangenomen dat iemand anders later verdergaat met hun code. Zij leveren features, geen losse code.

En ten slotte is er de software engineer. Software engineers zijn verantwoordelijk voor één of meer applicaties binnen hun context. Dat betekent dat ze moeten nadenken over onderhoud, over hoe een applicatie kan groeien en zich kan ontwikkelen, en over welke metrics belangrijk zijn en waarom. Wat engineers bouwen is software, en werkende software is meer dan alleen blokken code of een verzameling features. Ze richten zich altijd op een complete oplossing.

Het is duidelijk dat we van coders en programmeurs niet dezelfde verantwoordelijkheden kunnen of mogen verwachten als van engineers. Maar uiteindelijk helpt het leveren van code of features zonder werkende software zelden, en kan het de eindgebruiker zelfs schaden. De software engineer heeft hierin een unieke verantwoordelijkheid. En zoals je inmiddels ongetwijfeld begrijpt: de software engineer is goed te vergelijken met de arts uit onze eerdere metafoor.

Kort samengevat: een software engineer zou nooit “je hebt er niet om gevraagd” als verdediging mogen gebruiken. Want degene die had moeten vragen, was niet de “jij” in die zin, die verantwoordelijkheid lag bij de software engineer zelf.

Van codekwaliteit tot ethische software

De software engineer heeft een unieke blik die vraagt om een andere, diepgaandere benadering dan die van een programmeur of coder. In de volgende artikelen van deze serie zal ik ingaan op de verantwoordelijkheden die een software engineer heeft.

Ik zal het hebben over codekwaliteit, softwarekwaliteit en ethiek. Deze drie thema’s bestaan uit veel kleinere verantwoordelijkheden: requirements en documentatie, codekwaliteit, onderhoudbaarheid, het ontwikkelproces, infrastructuur, operations en support, analytics, security, efficiëntie, kosten, de impact van de software, en meer. En ja, we gaan het over al die onderwerpen hebben.

Nu hoor ik je denken: het is toch onrealistisch om te verwachten dat één persoon al die kennis en vaardigheden heeft? Eerlijk gezegd: dat is wél de verwachting die ik heb, en ik vind dat geen onredelijke eis. Ook ik voldoe er niet volledig aan, maar ik blijf streven naar dat hogere niveau. Er zijn bovendien manieren om je tekortkomingen op te vangen, en die zal ik ook delen, in de vorm van links, tips en nuttige metaforen. Mijn doel is om je te inspireren om jezelf te blijven verbeteren, en om dat proces iets makkelijker te maken.

In deze serie maken we kennis met Alex, een fictieve software engineer die werkt aan een fictieve softwareoplossing voor een fictief bedrijf dat workshops verzorgt, zowel op locatie als online. Alex zal helpen illustreren waarom software engineers beter moeten doen. De wereld van softwareontwikkeling is nog jong, maar jong en verantwoordelijk sluiten elkaar niet uit. En net als wij zal Alex nieuwe verantwoordelijkheden ontdekken en groeien als software engineer.

Een overzicht van deze hele blog serie door Jelle.

• Writing Quality Code (part 1)
• Writing Quality Code (part 2)
• Building Quality Software (part 1)
• Building Quality Software (part 2)
• Creating Ethical Software (part 1)
• Creating Ethical Software (part 2)
• The Development Process (part 1)
• The Development Process (part 2)
• The Software Engineer Oath