Buzzy Developing Valuable
Software and Talent

De Cruciale Rol van Product Managers en Product Owners in Softwareontwikkeling

Binnen het IT-landschap speelt product management een essentiële rol bij het vormgeven van allerlei softwareoplossingen. Het is de kunst van het balanceren tussen technische mogelijkheden, marktinzicht, klantgerichtheid en economische haalbaarheid, waardoor bedrijven concurrentieel kunnen blijven in een competitieve omgeving.

Of het nu gaat om het ontwikkelen van interne hulpmiddelen die de efficiëntie verhogen, of het creëren van op maat gemaakte softwareoplossingen voor externe klanten, het belang van doelgericht product management kan niet worden overschat. Het vormt de ruggengraat van een succesvolle ontwikkelingscyclus, waarbij het nauwkeurig afstemmen van technische mogelijkheden op de behoeften van de gebruiker en daarnaast de doelstellingen van de organisatie essentieel zijn.

In dit artikel richten we ons specifiek op de oplossingen voor onze externe klanten, waarbij we de schijnwerpers richten op de cruciale stappen en strategieën die bijdragen aan het leveren van software van goede kwaliteit en die bovendien waarde aanlevert aan onze klanten.

‍

Product Manager of Product Owner?

Binnen IT product management bestaan er twee belangrijke titels: de Product Manager en de Product Owner. Hoewel de rollen vaak als synoniemen aanzien worden, vertegenwoordigen ze verschillende, maar complementaire, aspecten van het productontwikkelingsproces.

De Product Manager staat aan het roer van de strategische visie van een product. Hij is bedreven in het begrijpen van markttrends, identificeert kansen en beheert de gehele levenscyclus van een product. Zijn focus ligt op het maximaliseren van waarde voor de klanten, maar zeker ook voor het bedrijf. Hij probeert gedefinieerde doelen te bereiken en is geïnteresseerd in de outcome van de software, niet zo zeer in de details van wat het ontwikkelingsteam oplevert.

De Product Owner daarentegen richt zich op de tactische uitvoering van die strategische productvisie. Hij vertaalt de visie naar de praktijk en zorgt voor de kwaliteit en klantwaarde van het eindproduct. Hij werkt daarvoor nauw samen met de klant en met een of meerdere multidisciplinaire ontwikkelingsteams. Hij vertaalt de behoeften van de klant in concrete taken , beheert de backlog en stelt prioriteiten.

Het is belangrijk op te merken dat hoewel er theoretisch gezien een duidelijk onderscheid is tussen de rollen van een Product Manager en een Product Owner, er in de praktijk vaak sprake is van aanzienlijke overlap. Beide functies zijn van cruciaal belang voor het succes van een product, maar de manier waarop bedrijven ze invullen kan variëren en zo kunnen de verantwoordelijkheden vaak in elkaar overvloeien, vooral in kleinere teams of startupomgevingen.

In sommige gevallen kan het voorkomen dat één persoon beide rollen vervult. Dat vereist een zorgvuldige balans tussen strategie en uitvoering. Deze persoon moet in staat zijn om de bredere visie te behouden en tegelijkertijd effectief kunnen schakelen naar de meer tactische taken. Het is een uitdagende, maar haalbare taak, die uitgevoerd dient te worden door iemand die kennis heeft van alle aspecten van het gehele productontwikkelingsproces, vanaf de conceptuele fase tot aan de uiteindelijke productie en lancering van een product.

‍

Van Product Management tot softwareontwikkeling

Product management zorgt ervoor dat strategische doelen worden omgezet in een concreet en functioneel product dat echte waarde toevoegt aan jouw bedrijf en jouw klanten.

Wil je meer weten over hoe wij jou kunnen ondersteunen met het invullen van deze cruciale rollen? Ontdek hier meer over hoe The Beehive jou kan helpen met jouw product management.

En er is meer! Zodra de visie helder is en gevalideerd, kunnen wij ook de volledige ontwikkeling van jouw applicatie verzorgen, door je een ervaren java-developmentteam van The Beehive aan te leveren. Van idee tot ontwerp en ontwikkeling, wij begeleiden je door het hele proces.

Neem contact met ons op en ontdek hoe wij je kunnen ondersteunen bij elke stap van jouw softwareproject. Jouw project is van begin tot eind in goede handen.

‍

Introductie

Spring is momenteel de standaard voor Java projecten en het lijkt er niet op dat dit binnenkort zal veranderen. Dat is niet echt een verrassing; Spring werd al veel gebruikt voordat Spring Boot op het toneel verscheen en deze heeft het nog makkelijker gemaakt dan ooit om projecten werkend te krijgen. Overal vind je documentatie, handleidingen, cursussen en voorbeelden, waardoor de leercurve aanzienlijk wordt verlaagd.

Met Spring Boot kun je snel een webproject opzetten: start met de Initializr, voeg een flinke hoeveelheid afhankelijkheden toe, en gebruik enkele annotaties. Voilà, je hebt een applicatie die HTTP-endpoints biedt. Eenvoudig, toch?

Persoonlijk hecht ik meer waarde aan eenvoud dan aan hoe makkelijk iets is. Ik wil begrijpen wat er precies IN mijn applicatie gebeurt. Natuurlijk kan ik @GetMapping’s gebruiken als de beste, maar wat doet dat eigenlijk achter de schermen? Om dit te onderzoeken, gaan we in Clojure een eenvoudig framework ontwikkelen, genaamd Jump. Dit framework zal vergelijkbare functionaliteiten als Spring aanbieden. Daarnaast zullen we proberen de code interface zo dicht mogelijk bij die van een Spring toepassing te houden, zodat het gebruik van Jump net zo makkelijk zal zijn. Het einddoel is een eenvoudig framework hebben dat gemakkelijk te gebruiken is, terwijl je precies weet wat er gaande is.

‍

Het games archief

Om de ontwikkeling van ons framework te begeleiden zullen we een zeer standaard JSON gebaseerde CRUD API maken voor een games archief. Eerst maken we een deel van de app in Spring, vervolgens schrijven we wat Clojure-code die zo dicht mogelijk bij de Spring-definitie ligt, en tot slot schrijven we Jump framework code om alles te laten werken. We zullen ook proberen enkele van de dingen te identificeren die Spring impliciet doet, waar je misschien wel of niet van op de hoogte bent, en ze ook in Jump implementeren om zo dicht mogelijk bij de functionaliteit van Spring te komen. Laten we eraan beginnen!

‍

Endpoint om een game toe te voegen in Spring Boot

We beginnen met het aanmaken van een endpoint dat een game toevoegt aan het archief. Omdat we nog geen datastore hebben gaat deze implementatie enkel de id teruggeven.

‍

De Spring test

Eerst maken we de test specificatie:

‍

‍

De Spring controller

Nu we de test hebben kunnen we de controller schrijven die hieraan voldoet.

‍

Endpoint om een game toe te voegen in Jump

Nu beginnen we met het maken van het Jump framework. Even ter herhaling, we gaan twee doelen nastreven: Ten eerste zullen we een framework bouwen dat dezelfde verantwoordelijkheden op zich neemt als Spring Boot; Ten tweede willen we een gebruiker van het framework de mogelijkheid geven om op dezelfde "gemakkelijke" manier te definiëren wat het framework zou moeten doen zoals Spring dat toelaat. Dit is natuurlijk enigszins subjectief, dus laat me weten als je denkt dat we te ver afwijken van de manier waarop Spring werkt.

Clojure syntax

Voordat we ons verdiepen in de code, geef ik eerst een overzicht van wat je gaat lezen. Als je in Clojure werkt, maak je voornamelijk gebruik van pure functions die transformaties uitvoeren op plain values en datastructures.

Bijvoorbeeld, data die je normaal in een DTO of POJO zou modelleren kan eenvoudigweg als een map aangemaakt worden die achterliggend ook de Java Map-interface heeft.

De test

We beginnen met dezelfde test te definiëren als in Spring.

De Controller

Normaal zouden we zelf de syntax kunnen bepalen van de code die een gebruiker moet schrijven, maar omdat we hier Spring als voorbeeld willen gebruiken blijven we zo dicht mogelijk daarbij.

‍

De DispatcherServlet

De kern van het verwerken van web requests in de meeste Java toepassingen draait om de Servlet API. De Jakarta (voorheen javax) Servlet is een interface die de web application servers waarin je toepassing draait, zoals Tomcat of Jetty, kunnen gebruiken om requests naar je app te sturen en een response terug te krijgen.

Spring haakt in op dit proces voor HTTP requests door een DispatcherServlet te definiëren, die extend van de Jakarta HttpServlet, en zich bewust is van de ApplicationContext. Deze servlet stuurt het verzoek door naar een handler. Deze handler roept uiteindelijk de methode van je controllers aan en duwt vervolgens alles wat je hebt returned helemaal terug omhoog door de stack, zodat een HTTP response kan worden teruggegeven.

De Jump Servlet

Eindelijk tijd voor wat framework code. Onze eerste taak zal zijn om onze eigen implementatie van de Servlet interface te maken. Deze Servlet moet onze create function aanroepen met gegevens van de ServletRequest en hetgeen dat terugkomt omzetten naar een ServletResponse. Net als Spring zullen we ons baseren op de HttpServlet.

Laten we eerst een test schrijven die verifieert dat onze servlet kan werken met een simpele handler:

De servlet-request en servlet-response functions maken mock objecten aan die de respectieve Jakarta interfaces implementeren.

Om onze simpele servlet te implementeren moeten we wat Java interop doen, hier de basis:

De eerste versie van de servlet:

Met deze implementatie hebben we een servlet die de inhoud van een verzoek kan lezen en kan reageren met een status code en headers. Dit is genoeg om onze testen te laten werken. De servlet test werkt al, maar om de controller test te laten slagen, zullen we nog één laatste functie maken die de MockMvc helper van Spring weerspiegelt.

En tot slot kunnen we onze controller test aanpassen om onze mock servlet te gebruiken en deze laten slagen.

Samenvatting

Eerst definieerden we een HTTP endpoint voor het toevoegen van een game in Spring met behulp van MockMvc en weerspiegelden dat in Clojure. Vervolgens implementeerden we een basis Jump HttpServlet met de minimale functionaliteit die we nodig hebben, en tot slot creëerden we een mock servlet dat we gebruikten om onze test te doen slagen.

Met de huidige implementatie kunnen we slechts één functie definiëren die alle inkomende verzoeken afhandelt, maar dat is iets wat we volgende keer gaan oplossen wanneer we beginnen met het implementeren van een router.

‍

In mijn voorgaande blog, ‘Kwaliteitsvolle Software Opleveren’, had ik het al over het belang van testen als essentieel hulpmiddel om de kwaliteit van code te verbeteren. Maar hoe pak je dat nu net aan?

Voor veel developers is het schrijven van testen een taak die ze niet graag doen. Ze doen het omdat het moet. Bij The Beehive kijken we hier net iets anders naar. Testen zijn een hulpmiddel om zo snel mogelijk extra value op te kunnen leveren. Door te testen kan je immers garanderen dat de code die je oplevert ook echt doet wat je verwacht dat ze doet.

Natuurlijk gebeurt het wel eens dat we onszelf erop betrappen dat we eerst onze code schrijven om ze nadien pas te gaan testen, wat er op die momenten inderdaad voor kan zorgen dat het een hels werk is. Je hebt immers veel code geschreven om die nieuwe functionaliteit uit te werken, maar nu moet je al die code nog gaan controleren. Dit is echter niet de beste manier.

Wat is Test Driven Development (TDD)

Test Driven Development (TDD) werd in extreme programming (XP) initieel omschreven als “test first". Dat zegt eigenlijk grotendeels al hoe we bij TDD aan de slag gaan. Laat ons daar nu in iets meer detail naar kijken:

Bij TDD spreken we vaak van de red-green-refactor cyclus. We beginnen zoals XP het beschrijft met onze test. Vooraleer we een letter code geschreven hebben, gaan we dus al onze eerste test schrijven. Logischerwijs zou deze test moeten falen en dus rood kleuren. Bij het schrijven van deze test baseren we ons uiteraard op de requirements die we moeten implementeren.
Als we onze falende test hebben, testcode die niet compileert, valt ook onder een gefaalde test, kunnen we beginnen met het schrijven van productiecode. Hier schrijven we net genoeg code om onze test terug te laten slagen.
Als onze test geslaagd is, kunnen we gaan bekijken of onze code een refactoring kan gebruiken, zodat we de kwaliteit van de code kunnen verbeteren zonder dat we de functionaliteit van de code gaan veranderen.
Deze stappen blijven we nu herhalen tot we de hele functionaliteit hebben kunnen uitwerken.

Wat is Behavior Driven Development (BDD)

BDD gaat nog een stap verder dan TDD. Hier vertrekken we niet vanuit unit-testen, maar we vertrekken echt vanuit de uit te werken functionaliteit. Vooraleer we beginnen te werken aan de uit te werken functionaliteit, gieten we de acceptatiecriteria die in de story geformuleerd zijn in automatische testen.
Deze testen kunnen geschreven worden met behulp van verschillende tools en frameworks, maar je kan ook al een goede basis leggen door integratietesten te voorzien die alle acceptatiecriteria aftesten. Hierdoor moet je niet noodzakelijk nieuwe libraries gaan toevoegen of nieuwe frameworks gaan bestuderen, maar je kan gewoon gebruik maken van de test-libraries die je al aan het gebruiken bent.

Voordelen van TDD en BDD

Het schrijven van testen heeft naast het garanderen van de werking van de code ook nog andere voorbeelden. Aangezien we kwaliteit willen opleveren, is echter de correcte werking van de code wel het belangrijkste.

Daarnaast kan TDD en BDD bijdragen aan een betere architectuur en structuur in je code. Door eerst je testen te beginnen schrijven, ben je verplicht om al na te beginnen denken over de structuur van je code. De tijd dat we alle code in een enkel bestand schreven is gelukkig al lang voorbij, dat zorgt er ook voor dat we onze code gemakkelijker in kleine blokken kunnen verdelen die apart getest kunnen worden. Vaak zie je developers worstelen met het schrijven van testen. Ze vloeken omdat er bepaalde stukken code bijna onmogelijk bereikt kunnen worden met automatische testen of dat de setup die hiervoor nodig is gigantisch ingewikkeld is. Dat is een alarmsignaal dat aangeeft dat er ergens iets niet goed zit in de structuur. Als je eerst je testen schrijft, heb je dit probleem niet. Je past de structuur van de code immers zo aan dat het helpt om je testen te laten slagen.

Het laatste voordeel dat voor mij belangrijk genoeg is om te vermelden, is dat je niet alleen op het moment dat je de functionaliteit uitwerkt weet dat ze werkt. Je hebt een blijvende controle over de correcte werking van de code, omdat je de testen geautomatiseerd kan laten uitvoeren in de CI/CD tools die je gebruikt. Hierdoor zie je het zeer snel als er toch iets kapotgaat door wijzigingen in bestaande code, refactorings of versie-upgrades.

Het toepassen van TDD en BDD zoals het beschreven is, vergt natuurlijk wel wat discipline. Iedere developer komt wel eens in de verleiding om toch snel die kleine bug, story,… op te lossen zonder er eerst een test voor te schrijven. Hieraan zijn echter altijd risico’s verbonden, doordat je misschien uiteindelijk zelfs vergeet bepaalde delen grondig genoeg te testen. In het begin lijkt dit misschien niet problematisch, maar een codebase kan zeer snel groeien. Als je dan te vaak toegeeft aan de verleiding om “binnendoor” recht naar de oplossing te gaan, kan deze binnendoor vaak een grote omweg worden. Hier zal je dan achteraf ongetwijfeld de gevolgen van moeten dragen, doordat er meer bugs naar boven komen of cruciale delen ineens niet meer correct blijken te werken. Bijt even door de zure appel en pas je manier van werken aan, je zal er achteraf ongetwijfeld de vruchten van plukken. Code on!

‍

Inleiding: van probleemgericht tot kwaliteitsvol programmeren

Code schrijven kan iedereen! Of beter gezegd, iedereen kan leren hoe je moet programmeren. Programmeren gaat immers “gewoon” over het oplossen van problemen. Dat probleemoplossend denken is iets dat iedereen geleerd heeft in het onderwijs. Wie herinnert zich immers niet de talloze vraagstukken die je moest oplossen in de lessen wiskunde! Je krijgt een probleem voorgeschoteld. Hier ga je dan na wat de gegevens zijn en wat er gevraagd wordt, dat laatste noemen we bij software development de requirements. Deze probleemstelling ga je dan vaak opdelen in kleinere deelproblemen die je eenvoudig kan oplossen. Dat is net hetzelfde bij het schrijven van software, de “problemen” die wij op moeten lossen, delen we op in kleinere taken. Bij deze taken gaan we dan kijken naar wat er al beschikbaar is en welk deel van het probleem we in deze taak moeten gaan aanpakken. Dat doen we dan met behulp van de bouwblokken en structuren die voorzien zijn in de programmeertaal en de frameworks die we gebruiken.
Er is echter nog wel een groot verschil tussen code schrijven en kwalitatieve code schrijven. In de volgende paragrafen gaan we hier dieper op in. We bekijken eerst wat we bij The Beehive verstaan onder kwaliteit en nadien bespreken we hoe je volgens ons best deze kwaliteit kan garanderen.

Wat is kwaliteitsvolle software?

Kwaliteitsvolle software is eigenlijk best een complex begrip. Code die vandaag kwalitatief is, kan binnen een paar jaar als niet-kwalitatief bestempeld worden. Bij kwaliteit gaat het immers om meer dan alleen de structuur van de code of het voldoende testen van de werking ervan! Kwaliteit is voor ons een werkwoord, misschien kunnen we het zelfs nog beter beschrijven als een continu proces! Onze teams zijn hier tijdens hun werk dan ook constant mee bezig, maar hoe doen ze dit dan?

Clean Code

Het eerste punt waar we zorg voor moeten dragen, is dat de code die we schrijven ook “clean code” is. Clean code is een geheel van puntjes waar je als ontwikkelaar op moet letten om ervoor te zorgen dat de code die je schrijft gemakkelijk te lezen en te onderhouden is. Het gaat hier onder andere over het beperken van complexiteit, zorgen voor duidelijke naamgeving en nog veel meer. Over clean code is al heel veel geschreven, daarom ga ik er hier ook niet dieper op in. Ik kan je alvast wel aanbevelen om het boek “Clean Code” van Robert C. Martin eens te lezen als je hier meer over te weten wil komen! De belangrijkste vuistregel hier is dat je altijd probeert een bestand “cleaner” achter te laten als je klaar bent met je werk dan wanneer je het opende.

Onderhoudswerken

Kwaliteit wil ook zeggen dat je onderhoud zal moeten doen. Dat is met alles zo! Als je vandaag een nieuwe auto koopt, krijg je bij de levering een wagen die voldoet aan de geldende kwaliteitseisen . Je kan er dus gerust op zijn dat je er veilig mee op pad kan gaan. Je zal tijdens de levensduur je wagen regelmatig schoonmaken, je moet een onderhoudsschema volgen, … Doe je dat niet, dan zal de auto een minder lange levensduur hebben dan wanneer je dat wel zou gedaan hebben. Hetzelfde geldt bij software!

Software wordt dan misschien niet blootgesteld aan weer en wind, toch zal de kwaliteit ervan door de jaren heen verminderen als je er niets aan doet! Maar wat zijn dan deze onderhoudswerken? Bij java-applicaties moet je bijvoorbeeld regelmatig updates doen. Je wil geen verouderde versies gebruiken, want hierin kunnen problemen of kwetsbaarheden zitten die in nieuwe versies verholpen zijn.
Ook kan je de kwaliteit van software meten op basis van de werking van de beschikbare features. Software die vol met bugs zit, kan je moeilijk kwalitatief noemen. Dat wil je natuurlijk niet enkel controleren voor nieuwe zaken die je toevoegt, maar ook bestaande functionaliteit moet altijd blijven werken zoals het hoort.

Kwaliteit garanderen

Om de kwaliteit van je codebase te garanderen zijn er een aantal best practices die je in je team best kan integreren. Deze helpen je om de werkwijze van alle teamleden zo goed mogelijk op elkaar af te stemmen.

Clean houden van de codebase

Het eerste waar je aan kan werken in het clean houden van de codebase. Dat is niet altijd eenvoudig, maar oefening baart kunst. Het maken van afspraken zoals eerder gezegd is hier een goed hulpmiddel bij. Begin daarom al met afspraken rond codestyle. Het komt de kwaliteit van de codebase niet ten goede als je aan de stijl van een stuk code kan zien wie dit geschreven heeft. Hier kan het gaan om “banale” zaken als indentatie, gebruik van whitespaces in je code,... maar ook naamgeving van classes, methods en variabelen valt hieronder. Er zijn tools die je hierbij kunnen helpen. Denk maar aan de linting-tools die door vele teams gebruikt worden. Deze gaan puur nakijken of de stijl van de code die je geschreven hebt conform is met de stijlregels die ingesteld zijn.

Technical debt wegwerken

Een andere tip die je best in je teamwerking verwerkt, is het wegwerken van technical debt. Technical debt? Hieronder kan je verschillende dingen verstaan. De belangrijkste zaken die hier volgens mij onder vallen zijn onder andere het up to date houden van de versies van de gebruikte tools en het refactoren van stukken code die beter kunnen. Dit refactoren is iets dat je niet altijd als technical debt zal benoemen. Bepaalde refactorings nemen immers niet veel tijd in beslag en zijn nodig om nieuwe functionaliteit op een propere manier toe te kunnen voegen. Er zijn echter refactorings die uitgebreider zijn. Een goed voorbeeld hiervan is de aanbeveling van “spring cloud stream” om over te stappen naar het functionele programmeermodel. Hiervoor zijn meerdere wijzigingen nodig, die je niet zomaar snel even wil meenemen. Dergelijke grote wijzigingen kunnen dus best apart opgelijst worden als technical debt. Hiervan neem je met je team dan elke iteratie een aantal zaken op, zodat de technische backlog niet eindeloos blijft aandikken.

Hou je dependencies up-to-date

Je dependencies in lijn houden met de meest recente (stabiele) versie ervan, gaat vaak zonder veel grote problemen. Zeker als het gaat over een tussentijdse upgrades. Bij een major update kan het zijn dat er sommige dingen niet meer werken zoals voordien, maar dit zijn vaak dingen die in de release notes goed gedocumenteerd zijn door de maintainers.

Voer regelmatig Code Reviews uit

Iets anders dat je ook vaak tegenkomt op projecten zijn afspraken die gemaakt worden over de gehanteerde codeerstijl. Het is me ooit al wel overkomen dat ik op een project terechtkwam, waar je duidelijk stukken code kon onderscheiden die geschreven waren door verschillende developers. Dit is iets dat je natuurlijk best zoveel mogelijk moet proberen te vermijden. Hier kan je gebruik maken van de kennis van je collega’s. Dat doe je bijvoorbeeld door code reviews te laten uitvoeren. Hier bekijkt een collega de code die iemand anders geschreven heeft om een bepaalde feature uit te werken. Je kijkt hier naar de uitgewerkte functionaliteit en je gaat na of er geen fouten in de implementatie aanwezig zijn. Een belangrijker deel van deze review is dat je ook gaat nakijken of de code voldoet aan de afgesproken standaarden. Je gaat hier vaak zaken uithalen waarin fouten gemaakt zijn tegen afgesproken naamgeving, maar ook verbeteringen in de structuur kunnen hier voorgesteld worden. Zo kan het zijn dat een andere developer ziet dat je bij een bepaald stuk code beter kan kiezen om een designpatroon toe te passen. Dit kan enerzijds zijn om de code duidelijker te maken, maar anderzijds kan het ook zeker gebruikt worden om de onderhoudsbaarheid of de uitbreidbaarheid van de code te verbeteren.

De code style kan je uiteraard ook nog op andere manieren laten controleren. Er bestaan verschillende tools die dit automatiseren. Denk hier bijvoorbeeld aan linting-tools of engines zoals sonar die je code gaan analyseren. Deze gaan enerzijds controleren of je alle conventies gerespecteerd hebt. Als er zaken niet in orde zijn, zullen deze weergegeven worden in de output van de scan. Veel van deze engines zijn ook configureerbaar, waardoor je de regels die gehanteerd worden eenvoudig kan aanpassen aan de afspraken binnen het team.

Testen van uitgewerkte functionaliteiten

Tot slot wil ik ook nog even de nadruk leggen op het belang van testen om de kwaliteit van code te garanderen. Hier gaat het niet zozeer over de kwaliteit van de code zelf, maar wel over de kwaliteit van de uitgewerkte functionaliteit. Hier zijn verschillende soorten testen mogelijk. Enerzijds heb je natuurlijk de manuele testen. Hier gaat iemand uit het team zelf aan de slag om via de user interface de werking van functionaliteit te testen. Dit is natuurlijk iets dat redelijk arbeidsintensief is. Meer nog, de hoeveelheid werk groeit naarmate de applicatie groeit. Het is immers perfect mogelijk dat een werkende feature ineens niet meer werkt bij aanpassingen in de code. Daarom voorzien we in al onze projecten ook altijd grondige testsuites, die geautomatiseerd de werking van, zowel bestaande als nieuwe, code controleren.
Ook hier onderscheiden we verschillende soorten testen. Je hebt bijvoorbeeld de unit testen, integratietesten en end to end testen, elk met hun specifieke eigenschappen en niveau van isolatie.

Het grote voordeel van automatische testen is dat je ze heel vaak kan uitvoeren. Of beter nog, je kan dit automatiseren. Alle moderne CI/CD tools bieden de mogelijkheid om tijdens de pipeline testen geautomatiseerd uit te voeren. Hier kan je met een beetje configuratie zelfs een opsplitsing maken tussen verschillende soorten testen. Zo kan je bijvoorbeeld bij elke commit kiezen om alle unit testen uit te voeren, terwijl je de integratietesten enkel uitvoert als er een code change toegevoegd is aan een pull request. Hiermee kan je dan de build time in de hand houden, om zo toch ook de kosten een beetje te drukken.

Conclusie: Streven naar Kwaliteit in Software Development

In deze blogpost nam ik jullie mee in een reis van probleemoplossend denken naar het streven naar kwaliteit in software development. Want zeg nu zelf, kwalitatieve software op de markt brengen, dat willen we toch allemaal. Nog een belangrijk aspect voor het op de markt brengen van kwaliteitsvolle software is uiteraard het testen. Daarom leg ik jullie in een volgende blog meer uit over twee belangrijke aspecten van kwaliteitsvol programmeren: Test Driven Development (TDD) en Behavior-Driven Development (BDD)

‍

Great Place to What?

Het Great Place to Work certificaat is een tastbaar bewijs van onze toewijding aan de creatie van een cultuur gebaseerd op vertrouwen, samenwerking, openheid en respect. Voor ons is dit certificaat een weerspiegeling van onze inzet om een omgeving te bieden waarin elk individu wordt gewaardeerd, gehoord en aangemoedigd om bij te dragen aan het succes van ons bedrijf.

Een ode aan diversiteit en groei

Devora Friedman – Full Stack Developer

Devora, een van onze vrouwelijke full stack developers, deelt haar ervaringen met openheid en groei. Ze benadrukt hoe haar unieke achtergrond en vaardigheden worden gewaardeerd, en hoe ze zich thuis voelt in een omgeving waar ze zich vrij kan uiten.
‍

Tijdens mijn zoektocht naar werk wilde ik groeien en leren van diverse collega’s. In The Beehive vond ik de juiste plek, een plek dat openstaat voor diversiteit en unieke perspectieven. Maar ook een plek waar een open en gezellige sfeer heerst. Niemand kijkt vreemd op als ik iets niet weet en ik voel me vrij om vragen te stellen.Onze samenwerking gaat verder dan individuele projecten, toen we moesten brainstormen over de implementatie van een aspect binnen Biddit, kwamen collega's spontaan samen om bij te dragen. De toegevoegde waarde van The Beehive is de toegankelijke kennis en expertise voor elk project.Ik vind het prachtig hoe oprecht men hier omgaat met Sociocratie. Toen ik voor het nieuwe jaar een kaartje in de bus kreeg met een teamfoto, dachten mijn kinderen dat de baas degene was die in het midden zat. Maar dat was niet zo. Joris zat helemaal aan de kant, en toen ik hem vertelde wat mijn kinderen zeiden, zei hij: "Ik ben helemaal geen baas”. The Beehive betrekt ons bij het bepalen van de koers. Als ik één verandering zou willen? Graag meer vrouwelijke developers!

‍

Verbinding en Waardering tot in de Kern

Michael D’hondt - Project Manager

Voor Michael, één van onze projectmanagers, is de sleutel tot ons succes de nadruk op vertrouwen, waardering en open communicatie. Hij beschrijft hoe The Beehive erin slaagt een hechte gemeenschap te creëren waar iedereen betrokken is bij elkaars groei en welzijn.
‍

Ik voel me echt gewaardeerd bij The Beehive. De open communicatie houdt me betrokken en op de hoogte van alles wat er speelt. Joris en de andere collega’s tonen oprechte interesse en bieden altijd ondersteuning. Dat creëert een warme en betrokken sfeer waarin we goede gesprekken kunnen voeren en hechte banden kunnen opbouwen.Wat The Beehive onderscheidt? De unieke bedrijfscultuur die door onze eigen visie wordt gevormd. Het is geen standaardpraktijk, maar eerder een resultaat van onze sociocratische aanpak en agile mindset. We zetten sterk in op coaching, wat me aanmoedigt om me meer open te stellen en diepgaandere gesprekken te voeren met collega's zoals Dirk, mijn coach binnen het bedrijf. Een mooi voorbeeld daarvan was eigenlijk mijn start bij de klant. Je komt in een complexe omgeving terecht en moet jezelf inwerken, vertrouwensrelaties creëren, je positie vinden,.. Dat is een uitdaging die veel energie vraagt. Dankzij de coaching sessies die ik maandelijks heb met Dirk, heb ik een sparringpartner om zo een zaken aan te pakken.Ook mijn work-life balans is dankzij The Beehive beter dan ooit tevoren. Ik hoef me niet bezig te houden met meerdere projecten, wat mijn balans en welzijn ten goede komt.

Het Belang van Teamgevoel

Brend Simons – Full Stack Developer

Bij Brend, Full Stack Developer, ligt de nadruk op het belang van teamwork en op mentale gezondheid bij The Beehive.

The Beehive is in mijns inziens uitgegroeid tot een bedrijf waarin het Team en de mentale gezondheid van de mensen centraal staan. Dat resulteert in collega’s die allemaal enorm graag deel uitmaken van het bedrijf. Wanneer het even wat minder gaat, bieden collega’s met veel plezier hun hulp aan. Daarnaast heerst er ook een enorme cultuur van vertrouwen. Bij The Beehive is er de perfecte work-fun verhouding.Een specifiek moment waarop The Beehive zich als een Great Place to Work bewees voor mij, was tijdens mijn betrokkenheid bij het 'Biddit-Team'. Dit project was niet alleen enorm leuk en leerzaam, maar ik heb ook de kans gehad om samen te werken met fantastische collega's, wat mijn groei zowel technisch als sociaal bevorderde.Het feit dat we bij The Beehive kunnen deelnemen aan domeingroepen, wat ons in staat stelt om samen beslissingen te nemen over bepaalde onderwerpen en de richting van het bedrijf te beïnvloeden, is voor mij echt een voorbeeld hoe je je binnen een bedrijf echt gehoord en gewaardeerd kunt voelen. Ook de immense nadruk op TEAM is geweldig. Het gezegde 'Together Everyone Achieves More' is hier echt van toepassing.Ik geloof sterk in onze manier van werken, zoals beschreven op: https://thebeehive.be/blog/The-Beehive-superorganisme

Samen Bepalen We Onze Richting

Christophe Mees – Full Stack Developer

Voor Christophe, Full Stack Developer, is het unieke aan The Beehive de nadruk op transparantie en inspraak. Hij beschrijft hoe het gebruik van sociocratie hem het gevoel geeft dat zijn stem gehoord wordt en hoe hij een echte bijdrage levert aan de richting van het bedrijf.

‍

The Beehive is voor mij een geweldige werkplek vanwege de transparantie, de mogelijkheid om mee te beslissen over de richting van het bedrijf en het gevoel dat iedereen gehoord kan worden.Toen we gezamenlijk via sociocratie een visie creëerden voor het soort bedrijf waarin we willen werken, was echt een Great Place to Work-moment voor mij. Het was opmerkelijk om te zien dat het bedrijf daadwerkelijk die richting begon in te slaan. Dat toont aan dat het bedrijf niet alleen een toneelstuk opvoert, maar daadwerkelijk samen met ons aan de slag wil.Als ik één verbeterpunt zou moeten noemen voor onze werkplek, dan denk ik dat het belangrijkste op dit moment is dat het bedrijf verder groeit, zowel in onze werkwijze, het vinden van klanten, als in het aantal medewerkers. Dat zal ons nog dichter bij onze gedeelde visie brengen.

‍

‍

Een Cultuur van Betrokkenheid

Dirk Wille - Projectmanager

Dirk, Projectmanager, benadrukt de unieke cultuur van betrokkenheid en inspraak binnen The Beehive. Hij deelt zijn ervaring met sociocratie en hoe het de deuren opent voor communicatie en besluitvorming op alle niveaus.

‍

The Beehive is voor mij een geweldige werkplek omdat we echt de principes van sociocratie toepassen, waarbij iedereen de kans krijgt om mee te bepalen hoe we ons organiseren voor de zaken die we echt belangrijk vinden.Elke keer dat ik aanwezig ben op kantoor in Kontich, toont The Beehive alweer waarom het een Great Place to Work is. Ik voel een sterke binding met het Beehive-team daar. Dat gevoel is pas ontstaan sinds The Beehive is opgericht, en niet tijdens de acht jaar dat ik voor Cronos werkte.Binnen onze organisatie worden alle medewerkers gewaardeerd en gehoord door verschillende "kanalen" zoals coaches, de werking van de domeinen en projectteams. Op het gebied van waardering vind ik dat dit ook voldoende wordt uitgesproken en getoond, bijvoorbeeld met extra verlofdagen en tijd en ruimte voor opleidingen.De mindset van sociocratie en de vele ontspannende activiteiten zoals bordspellen, leesclubs, Les Ondes, inzet voor goede doelen en townhall-meetings maken van The Beehive een werkgever zoals ik er nog nooit één gehad heb.

‍

Conclusie: Een Gemeenschap van Groei

Het Great Place to Work certificaat is meer dan een erkenning. Het is een bevestiging van onze toewijding aan een cultuur waarin elk individu wordt gewaardeerd, gehoord en aangemoedigd om bij te dragen aan ons gezamenlijke succes. Bij The Beehive streven we ernaar om niet alleen een geweldige plek om te werken te zijn, maar ook een gemeenschap van groei en samenwerking.

‍