Door Tweakers Partners

Dev Summit 2024: Dingen die je als developer niet, of juist wél, zou moeten doen

27-11-2024 • 08:00

27

Principal Consultant Dennis Doomen is al 28 jaar actief in de IT-wereld, en uitgegroeid tot een ervaren softwareontwikkelaar en architect. Met zijn keynote op de Developers Summit 2024 - 4 december in DeFabrique in Utrecht - wil hij bekende developers-valkuilen bespreken en dingen laten zien die je vooral niet moet doen. Zijn talk, met de titel 'Use the right tool for the right job at the right time' belooft dan ook een aangename, technisch diepgaande én praktisch toepasbare mindfuck te worden.

Als Principal Consultant helpt Dennis klanten optimaal gebruik te maken van de combinatie van .NET/C# en moderne frontend technologieën zoals React en TypeScript. Zijn expertise omvat principes zoals unit testing, test driven development, domain driven design, Solid, clean code, en design patterns (data, domein, service, UI). Hij werkt met architectuurstijlen zoals CQRS, event sourcing, micro/macro-services en Onion/Hexagon. Technologisch is hij bedreven in onder andere C#, .NET, TypeScript, JavaScript, React, Terraform, Azure en AWS. Voor tools maakt hij gebruik van bijvoorbeeld SonarQube, GitHub Actions, Azure DevOps en Scrum/Kanban om werk efficiënt te organiseren.

"Ik ben eigenlijk een vreemde eend in de bijt", aldus Dennis. "Ik combineer de rol van architect met hands-on ontwikkelwerk. Zo kan ik teams laten zien hoe ik denk dat software gebouwd moet worden." Sinds 2006 werkt Dennis bij Aviva Solutions, een consultancybedrijf dat gespecialiseerd is in maatwerkoplossingen en advies in de Microsoft-stack. "Het bedrijf is klein maar veelzijdig", legt hij uit. "We doen alles: van e-commercewebsites en grote maatwerkoplossingen tot beheer. Een soort full-stack, of beter gezegd, full-service consultancy."

Internationaal spreker en kritisch denker

Dennis brengt veel tijd door bij klanten, maar zijn rol bij Aviva gaat verder. Als Principal Consultant houdt hij zich niet alleen bezig met technische architectuur, maar ook met het verbeteren van ontwikkelprocessen. "Ik focus op alles, van test-driven development tot documentatie, source control en ontwerptechnieken", vertelt hij. "Het doel is altijd om het ontwikkelproces te optimaliseren, van idee tot productie."

Naast zijn werk bij Aviva is Dennis een bekende spreker op internationale conferenties. "Ik ben de afgelopen jaren op plekken geweest zoals Sydney, Londen en Praag. De onderwerpen van mijn talks variëren van test-driven development tot boundary-driven development en AI. Wat ik vooral leuk vind, is om niet alleen kennis te delen, maar ook practices en processen te bespreken waarvan ik vind dat je ze niet moet doen.” Zijn rol als spreker versterkt zijn statuur. "Klanten noemen me soms een thought leader omdat ik continu bezig ben met hoe je ontwikkeling beter en efficiënter kunt maken. En door mijn netwerk en toegang tot andere sprekers blijf ik altijd op de hoogte van de nieuwste trends."

Binnen Aviva en bij klanten is Dennis een drijvende kracht achter kennisdeling. "Ik krijg tijd van mijn werkgever om dingen voor te bereiden en kennis te delen. Intern draag ik bij aan kruisbestuiving tussen teams en help ik ontwikkelingen in gang. Dat kritische, altijd blijven duwen, zit in mijn dna."

Een parade van fouten en valkuilen, op zoek naar de silver bullet

Tijdens de aankomende Tweakers-conferentie zal Dennis een keynote geven waarin hij zijn kennis en ervaringen deelt. "Het wordt een mix van architectuurprincipes en ontwikkelprocessen, bezien met een kritische blik. Ik wil mensen prikkelen en laten zien hoe je écht impact kunt maken in softwareontwikkeling." Dennis is tegelijkertijd niet bang om kritische noten te kraken over de manier waarop softwareontwikkelaars te werk gaan. De titel van zijn talk, 'Use the right tool for the right job at the right time' is bewust gekozen. "Het betekent namelijk dat mensen vaak precies het tegenovergestelde doen: de verkeerde tool, voor de verkeerde taak, op het verkeerde moment."

Volgens Dennis is een van de grootste valkuilen in de IT-wereld het zoeken naar de ultieme oplossing, of zoals hij het noemt, de 'silver bullet'. "We willen een soort heilige graal vinden die al onze problemen oplost", legt hij uit. "Een goed voorbeeld is de manier waarop monolithische systemen vaak verguisd worden. Bedrijven denken dat microservices dé oplossing zijn voor alles, zonder te beseffen dat ze daarmee juist complexiteit toevoegen." Dennis benadrukt dat het probleem vaak niet bij de monoliet zelf ligt, maar bij de manier waarop bedrijven omgaan met hun ontwikkelprocessen. "Als je moeite hebt om één monolithisch systeem in productie te krijgen, waarom zou je dan vijftig kleinere systemen bouwen die allemaal met elkaar moeten communiceren? Je maakt het probleem alleen maar erger."

Dry-principe en antipatterns

Een andere veelvoorkomende fout is wat Dennis 'toekomst-proofing gone wrong' noemt. "Ontwikkelaars bouwen vaak allerlei abstracties en frameworks, in de hoop dat ze daarmee klaar zijn voor toekomstige veranderingen. Maar dat werkt zelden. Je doet aannames over de toekomst die vaak niet blijken te kloppen. Als je later aanpassingen moet doen, zit je eerst vast aan de beperkingen van die abstracties."
Dennis noemt dit een van de klassieke antipatterns in softwareontwikkeling. "Je denkt dat je tijd bespaart, maar uiteindelijk moet je al die complexiteit weer ongedaan maken om het systeem aan te passen."

Het dry-principe (don't repeat yourself) is een ander voorbeeld waar Dennis kritisch op is. Hoewel het idee achter dry – het minimaliseren van duplicatie – goed bedoeld is, kan het leiden tot problemen. "Als je te veel logica deelt in je systeem, creëer je onbedoeld een sterke koppeling. Dit maakt het juist moeilijker om onderdelen van je systeem te veranderen of te verplaatsen." Hij ziet een alternatieve aanpak als veel effectiever: "Binnen de grenzen van een module of service wil je duplicatie vermijden, maar daarbuiten is het vaak beter om logica te dupliceren dan om hem te delen. Dit maakt je architectuur flexibeler en makkelijker schaalbaar."

Continu leren van fouten én de community

Tijdens zijn aankomende keynote op de Dev Summit zal Dennis bovenstaande inzichten delen en verder uitdiepen. "Ik ga het hebben over valkuilen en dingen die je vooral niet moet doen. Een van mijn doelen is om anderen te behoeden voor de valkuilen waar ik zelf in ben gestapt." Want met 28 jaar ervaring heeft Dennis een schat aan kennis opgebouwd, maar hij ziet zichzelf nog steeds als een leerling. "Ik leer continu van mijn eigen fouten en van de community. De kern van mijn werk is kritisch blijven, mezelf en anderen uitdagen, en altijd zoeken naar manieren om het beter te doen."

Haal snel de allerlaatste tickets voor de Developers Summit in huis

De stapel kaarten voor hét evenement dat developers in het zonnetje zet, slinkt met de dag. Zorg dus dat je deze bijzondere summit niet mist. Tickets zijn verkrijgbaar voor 299 euro (plus 1,99 euro servicekosten) of als '3 halen, 2 betalen'-deal.

Als jouw werkgever de tickets vergoedt, wordt er uiteraard een factuur verstrekt voor administratieve doeleinden. Persoonlijke gegevens worden niet gedeeld met partners.

Meer infot button

Kijk hier voor het privacybeleid van Tweakers.

Ben je student? Mail ons dan via concepts@tweakers.net, zodat je een ticket kan kopen voor een gereduceerd tarief van 75 euro.

Dev Summit partnerblok

Reacties (27)

27
26
18
0
0
2
Wijzig sortering
Ik focus op alles
Vandale.nl over 'focus':
2. het zich concentreren op één bepaald punt

Altijd leuk dit soort advertenties 8)7
Je kan sowieso zien dat dit geschreven is zonder achtergrondkennis :P

Als je als schrijver van zaken af zou weten dan weet je ook dat het niet nodig is om te focussen (:+) op DRY omdat SOLID (niet Solid) daar al iets aan doet via SRP.
Eh, nee hoor. SOLID en DRY kunnen elkaar juist in de weg zitten. Wil je daar meer over weten, dan moet je naar die keynote komen.

[Reactie gewijzigd door dennisdoomen op 27 november 2024 20:36]

Ik denk niet dat m'n vorige reactie duidelijk genoeg was, want ik ben het juist met je eens dat alleen focussen op DRY niet nuttig is :Y

Wat ik echter probeerde aan te geven is dat focussen op SOLID al een flinke stap is op weg naar een omgeving waarin DRY niet eens echt nodig is om aan te houden en dat dit nuttiger is om te bespreken wanneer je begint over "toekomst-proofing". Je gooit er hier namelijk iets in wat überhaupt geen probleem zou moeten zijn, want seniors zouden dit doorgaans al moeten begrijpen en juniors doen opvallend vaak juist niet eens aan DRY. Welke doelgroep spreek je hier aan?

Althans, dat is wat ik met ongeveer net zoveel jaar ervaring en te veel schermen met code van ontwikkelaars op verschillende niveau's die aan mij voorbij zijn gegaan denk te kunnen zeggen.

[Reactie gewijzigd door Stukfruit op 28 november 2024 08:13]

Volgens mij gaat het in het artikel juíst om, om soms Do Repeat Yourself te doen ipv de Don't.

Met SOLID kun je dus een class/methode krijgen die door tig andere wordt aangeroepen (ivm Single Responsability, één stuk code die iets doet). Nu wil je voor één implementatie iets een klein beetje anders doen. Ga je daarvoor alles refactoren om toch die ene implementatie te herbruiken? Of is het beter om daar een eigen implementatie voor te gebruiken?
Deze vraagstukken spelen al op module/service nivo.

Voor microservice/enterprise nivo speelt dit ook, maar dan groter. Ga je bijvoorbeeld bepaalde functionaliteit kopiëren in een ander systeem? En hoe doe je dat?
Ik heb gezien waar ze domweg een deel functionaliteit "gekopieerd" hebben ipv servicecalls of events naar de originele service. Dat komt ook door een ander probleem dat developers hebben, namelijk DIY.

[Reactie gewijzigd door SPee op 27 november 2024 11:33]

Nu wil je voor één implementatie iets een klein beetje anders doen. Ga je daarvoor alles refactoren om toch die ene implementatie te herbruiken?
Als je "iets" een klein beetje anders wil doen dan volg je imho al niet echt SRP (of bv. contracten in het algemeen, of andere patronen die voor "clean code" zorgen) meer en is er al een grote kans dat de betreffende code gebaseerd is op drijfzand.

Maar m'n punt was dat ik hierboven in het artikel dingen lees die, zeker voor mensen met minder ervaring, alsnog sneller kunnen zorgen voor dat drijfzand. Imho ligt de focus op het verkeerde concept door te zeggen dat DRY niet altijd slecht is. Het is (nogmaals: imho) beter om code in het algemeen netter te houden ipv te focussen op dit soort details.

Dat heb ik in de praktijk helaas ook te vaak gezien. Dan hoort iemand dat het ok is om werk te dupliceren, maar zonder achtergrondkennis weet men niet hoe ver te gaan. Dus dan krijg je alsnog wildgroei en dat mag je als senior dan jaren later alsnog weer zelf met "veel moeite" fixen :P (tussen aanhalingstekens omdat je er na een hoeveelheid projecten met dat soort code steeds vaker opvallend vrolijk en fluitend doorheen gaat).

Als je wil focussen op schaalbare en flexibele architectuur dan ga je trouwens sowieso al snel richting werk gebaseerd op domeinen e.d. ipv supergeneriek werk, dus ook op dat vlak ben ik het er helaas niet helemaal mee eens.

[Reactie gewijzigd door Stukfruit op 27 november 2024 17:29]

Die "iets anders" kan het gevolg zijn voor een change request, waar het voorheen wel 100% gelijk was.
Dus hoe ga je die wijziging in je code proppen?
En ja, dan gaat het inderdaad om kennis, kunde en ervaring van de ontwikkelaar en richtlijnen binnen je project/product/team.
Ligt aan het soort change request. Als het een feature is die anders moet werken dan verkoop je "nee" of "alleen na X en Y" aan de PO of PM.

Als het puur technisch is dan klopte de DoD niet en doe je het zo nodig (ivm gepokerde tijd of punten) ook later, wellicht via de senior, maar dan via de officiële weg omdat je anders voor verborgen technical debt zorgt die niet alleen jezelf maar ook de rest van het team een keer gaat opbreken.

En yes ik weet dat het in de praktijk makkelijker gezegd is dan gedaan is :) helaas heb ik de virtuele brandplekken om gewoon niet meer onderhands aan zulke verzoeken mee te willen werken.
In mijn ervaring zijn het juist de juniors die extreem complexe generieke systemen proberen te schrijven om maar te voorkomen dat ze zichzelf een beetje hoeven te herhalen.
In mijn ervaring zijn het juist de juniors die extreem complexe generieke systemen proberen te schrijven om maar te voorkomen dat ze zichzelf een beetje hoeven te herhalen.
Binnen de Unity-wereld misschien ;) maar daarin wordt je sowieso de verkeerde kant opgeduwd door het framework dat zo'n beetje alle basisprincipes van schone code negeert.
Er mist inderdaad een stukje. Gelukkig zijn jullie er nog.
Nog een paar nuttige die iedere developer moet hanteren:

- Bouw alleen wat er gevraagd is. Als er later meer eisen komen, dan is dat een nieuw project.
- Als je een snelle PoC hebt gebouwd, gebruik dat niet voor een uiteindelijk product. Begin opnieuw met alle basiszaken die voor een productieomgeving essentieel zijn (bijv. security by design e.d.). Maar al te vaak wordt in alle enthousiasme een demo uitegebouwd tot een product.
niets is zo permanent als een tijdelijke oplossing die werkt :+
Als je een snelle PoC hebt gebouwd, gebruik dat niet voor een uiteindelijk product. Begin opnieuw met alle basiszaken die voor een productieomgeving essentieel zijn (bijv. security by design e.d.). Maar al te vaak wordt in alle enthousiasme een demo uitegebouwd tot een product.
Probleem is dat veel managers je die keuze niet geven door de resterende informatie "close to the chest" te houden omdat ze het zelf beter denken te weten. Dat levert uiteindelijk een Frankenstein-PoC op omdat er steeds wordt gevraagd: "kun je hier nog een stukje aan bouwen?", "kun je daar nog een stukje aan vastknopen?"

Als senior heb je het lef wel om daar tegenin te gaan, maar juniors durven dat (terecht) niet en zo ontstaan draken van systemen waarbij de veldslagen uit Game of Thrones verbleken.

TL;DR: stop (als senior) met werken voor partijen waar je dit ziet gebeuren.

[Reactie gewijzigd door Stukfruit op 28 november 2024 08:12]

En gerelateerd aan DRY: maak je code-eenheden (of dat nou klassen, functies of procedures zijn) niet al te groot. Laat ze 1 ding doen en niet meer dan dat. Zorg er voor dat ze alles binnenkrijgen als parameter zodat ze zo 'stateless' mogelijk zijn. Dat maakt het hergebruik veel en veel makkelijker en het stelt je in staat om later heel andere toepassingen te maken dan je in eerste instantie had gedacht.

Voorbeeld: in een ERP applicatie van een klant zat een functie om een bestelling te verzenden. Dezelfde functie zat (gekopieerd) in een scherm in de fabriek. Ik heb beide losgeweekt en samengevoegd tot een losstaande functie. Later was er behoefte aan het verzenden van een bestelling vanaf een tablet op een heftruck. Dat was nu ineens appeltje/eitje...
Als je dat grapje combineert met "1 stuk code heeft de verantwoordelijkheid, de rest mag alleen bij de resource via die code", dan ben je opeens heel ver :) Dan wordt t makkelijker DRY.

[Reactie gewijzigd door Martijn.C.V op 27 november 2024 09:41]

Ah, de SOLID principes. ;)
Je omschrijft het KISS principe.
Klopt, maar dat is verdraaid moeilijk. Dingen moeilijk maken is makkelijk. En omgekeerd
Dennis geeft altijd goede talks! :)
Als developer blijft toch een smak geld, 300 euro voor 'e'en dag praatjes luisteren. Dan koop ik daar liever een leuk yoke van. 8-)
Bedoel je hiermee dat mensen die in C# ontwikkelen geen 'developer' zijn?
Refereer je naar een typo? Wat bedoel je te zeggen? Je weet dat C# en .NET niet dezelfde dingen zijn.
Ja, ik was ook wel benieuwd wat het probleem hier is.
Ik vermoed dat Microwilly neerkijkt op windowsprogrammeurs. Onterecht, die lui maken ook best coole software.

Op dit item kan niet meer gereageerd worden.