De kans is groot dat je regelmatig code schrijft in een taal die zelfs nooit uitgevonden had mogen worden. Of misschien gebruik je wel de verkeerde IDE of de verkeerde tekstverwerker, of één of ander versiecontrolesysteem dat zijn taak met geen mogelijkheid aankan. Misschien ben je voorstander van een programmeermethode die nooit werkt, of de omlooptijd van je releases is helemaal fout geregeld. Misschien debug je je code wel op de verkeerde manier, of heb je geen enkel idee welke optimalisaties je in je compiler moet inschakelen. Wat het ook moge zijn, je projecten zijn gedoemd te mislukken.

Tegelijkertijd is de kans groot dat ik ook een idioot ben.

Waarom zijn ontwikkelaars er toch altijd als de kippen bij om elkaar af te fakkelen? Waarom zijn ze zo koppig in hun overtuigingen, kiezen ze zo snel partij en verlagen ze alles tot een vals zwart-wit argument? Kijk maar eens rond op ontwikkelaarsforums: je hoeft niet lang te wachten totdat een schijnbaar onschuldige thread uitmondt in een regelrechte flamewar.

Er lijkt geen einde te komen aan de lijst met hot topics: Emacs versus VI. Java versus .Net. C++ versus Java. Eclipse versus NetBeans versus Visual Studio. Perl versus Python versus Ruby. Agile versus waterfall. Django versus Rails. Extreme programming versus Scrum. Git versus Subversion.

Kijven over SF-programma's

Star Trek conventies daargelaten zul je niet snel een strijdlustigere groep tegenkomen. Een beetje kijven over je favoriete science fiction programma doe je gewoon voor de lol. Het is vermaak; het heeft niks met de realiteit te maken. Veel ontwikkelaars voorzien echter met programmeren in hun levensonderhoud. Wanneer beslissingen over tools en routines gepolariseerd raken en fanatisme in de plaats komt van rationele discussies, wordt er niet alleen tijd verspild: het gaat ten koste van je motivatie, het zit je communicatie op andere gebieden in de weg, en in het ergste geval vormt het een bedreiging voor het succes van veel belangrijker doelstellingen.

Het is zelfs zo erg geworden in de wereld van de applicatie-ontwikkelaars dat groepen ontwikkelaars "manifesten" zijn gaan uitdelen alsof ze Zuid-Amerikaanse opstandelingen zijn. Eerst had je het Agile Manifest. Nu komen anderen met het DevOps Manifest aanzetten (hoewel de gedachte achter die revolutie wat moelijker onder woorden lijkt te brengen).

Nu we het er toch over hebben wil ik zelf graag ook een manifest voorstellen, voor alle ontwikkelaars die al het geruzie, vingerwijzen, flamewars en scheldpartijen beu zijn. Omdat ik niks beters kan verzinnen noem ik het het Volwassenheids Manifest, en het gaat uit van een aantal sturende principes:

1. Ik verwerp het dogmatisch denken over tools, routines en processen

Als je merkt dat je steeds naar bepaalde websites terugkeert op zoek naar redenen waarom jouw favoriete tool beter is dan alle andere, dan is de kans groot dat je je favoriete tool niet goed genoeg begrijpt om er met zoveel passie over te kunnen ruziën. Sterke punten zijn goed om ontwikkelaars te overtuigen waarom ze een nieuwe tool zouden moeten gebruiken of expert zouden moeten worden op het gebied van een tool die ze al kennen. Maar je hebt er weinig aan als een team een aantal verschillende opties evalueert voor een specifieke taak.

Weersta ook de verleiding om een tool uitsluitend op basis van de leverancier te verwerpen. Je persoonlijke voorkeuren (of vooroordelen) wat leveranciers betreft komen niet altijd overeen met de belangen van het project.

2. Ik verkies flexibiliteit boven herhaling

Omdat iets de vorige keer werkte, wil dat nog niet zeggen dat het de enige manier is waarop iets deze keer gedaan kan worden. En werkte het de vorige keer echt zo geweldig goed dat het echt niet beter kon? Is er helemaal niks veranderd - de beschikbare opties, het beschikbare personeel, de deskundigheid van het personeel - dat ervoor kan zorgen dat een optie die voorheen niet passend was nu wel geschikt zou kunnen zijn? Probeer een 'open mind' te hebben wanneer teamleden met nieuwe methodes aankomen die nog niet zijn uitgeprobeerd. Wanneer besloten wordt om een bepaald idee voor deze iteratie af te wijzen, wees er dan niet te snel bij om het de volgende keer weer af te wijzen.

3. Ik neem alles in overweging voordat ik een oordeel vel

Wees vooral op je hoede voor kwalitatieve bijvoeglijke naamwoorden, zoals "sneller", "kleiner", "eenvoudiger", "schaalbaarder" en "robuuster" wanneer je tools verdedigt. Net als kunstmatige benchmarks vertellen ze zelden het hele verhaal. Het kan best zo zijn dat de best geschreven C++ code op dezelfde taak beter presteert dan de best geschreven Java code. Maar zijn de C++ programmeurs in jouw team echt de allerbeste? Tellen prestaties zwaarder dan andere overwegingen, zoals het onderhoudsgemak van de code of het geheugenbeheer? Voor sommige projecten is de marktintroductietijd misschien wel de belangrijkste factor; in dergelijke gevallen is de "beste" tool simpelweg de tool waarmee de taak het snelst voltooid kan worden. Zorg ervoor dat je de prioriteiten van je project begrijpt voordat je een bepaalde tool aanbeveelt.

4. Ik erken de tekortkomingen van mijn tools, ook die van mijn favorieten

Ik ben nog nooit een taal, proces of methode tegengekomen die in alles even goed is. C mag dan wel de meest logische keuze zijn voor een project als de Linux kernel, maar het is een beroerde taal voor tekstverwerking. Agile methodes werken geweldig voor kleine groepen, maar voor bedrijfsbrede projecten werken ze niet. Domme programmeurs kiezen steeds opnieuw voor dezelfde tool, gewoonweg omdat ze die het beste begrijpen; slimme programmeurs zijn bereid hun favoriete methodes opzij te zetten wanneer ze vanbinnen weten dat ze niet ideaal zijn voor de taak die ophanden is.

5. Ik maak het perfecte niet tot vijand van het goede

We hebben ongetwijfeld allemaal weleens afschuwelijke code onder ogen gekregen, en we zijn vast allemaal een tool tegengekomen die een taak moest volbrengen waar hij nooit voor bedoeld was. Dit zijn de ongunstigste voorbeelden. In andere gevallen is een niet-optimale oplossing die het doel bereikt een betere optie dan een optimale oplossing die te lastig te implementeren is binnen de gereserveerde tijd. Het is van belang dat ervaren ontwikkelaars bezwaar aantekenen wanneer ze probleemgebieden tegenkomen, maar zodra die kwesties besproken zijn is het tijd om het debat af te sluiten en je te richten op het doel. Sommige dingen kun je beter op een later tijdstip uitvechten.

6. Ik geef mijn fouten toe in plaats van het erger te maken

We hebben het allemaal weleens bij het verkeerde eind. Soms zeggen we gewoon iets doms. Hoe ervaren je ook bent, hoe zeker je ook van je zaak bent, er komt waarschijnlijk een moment waarop je iemand tegenkomt die een probleem of tool beter begrijpt dan jij. Zulke momenten zijn geen nederlagen. Het zijn kansen. Je doet jezelf en je plaats in het team niet alleen een plezier als je zelfverzekerd genoeg bent om met passie je positie te verdedigen, maar zeker ook als je zelfbewust genoeg bent om een les die het leren waard is te herkennen.

Mocht dat niet lukken, dan kun je altijd nog naar huis gaan om de hele wereld uit te schelden op een forum - veel succes.