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!

‍

Een persoonlijke kijk op de kracht van een team

Een tijd geleden stelde ik mezelf de vraag wat The Beehive zo bijzonder maakt. Waarom voelt wat we doen zo juist aan? Ik geloof dat het de kracht is van een team en het vertrouwen in goed gecoachte, individuele talenten die het geheel zo waardevol maken. ‘We hire for attitude, train for skills and search for talent’.

Een blik terug

Een veilige omgeving creëren zodat elkeen kan excelleren. Dat leerde ik toen ik zeven jaar geleden de kans kreeg om bij Cronos te starten. Ik was toen projectmanager van een team, samengesteld om IT-projecten rond Identity en Access Management voor een federale overheidsdienst op te leveren. Om ervoor te zorgen dat ik niemand vergeet, tag ik hier even niemand. Maar wat was het goed om met zoveel talent samen te werken. Het was in die groep dat ik voor het eerst besefte dat het als projectmanager mijn taak was om elk talent vanuit zijn kracht te laten werken. Alleen zo stijgt ook de groep boven zichzelf uit.

Of het nu ging over Java-specialisten, usability experts, architecten, IAM-consultants, analisten of projectmanagers, dankzij een sterke focus op een agile en zelfsturende teamwerking kon iedereen zijn steentje bijdragen. Ervaring was niet van tel. De goesting waarmee elk teamlid aan de slag ging en het engagement dat iedereen opnam, zoveel te meer.

De taak van de projectmanager?

Als projectmanager was het mijn verantwoordelijkheid om elk project met succes op te leveren. In realiteit voelde dat anders aan. Het voelde vooral als mijn taak om een kader te creëren dat anderen de ruimte gaf om zichzelf te ontplooien, te groeien en hun talenten in te zetten. Het uiterst aangename gevolg daarvan was dat we steeds kwalitatief werk opleverden, sprint na sprint, release na release.

Dat ik toen te maken had met een talentvolle groep was zeker. Daarom kan het ook geen toeval zijn dat zoveel collega’s van toen intussen zijn doorgegroeid tot coachende en leidinggevende rollen binnen Cronos.

Winnen als gevolg, niet als doel op zich

In mijn vrije tijd ben ik al jaren nauw betrokken bij de mooiste basketclub van Vlaanderen, Amon Jeugd Gentson. We zijn niet op zoek naar de nieuwe Michael Jordan, wel is het onze missie om jongeren de kans te geven zich te ontplooien tot sociale en ruimdenkende adolescenten.

Een trainer bij Gentson is in de eerste plaats een coach, geen drill-sergeant. Het is iemand die jongeren leert om problemen te (h)erkennen en oplossingen te zoeken. Winnen is daarvan een gevolg, maar niet het doel op zich.

Een mooi voorbeeld. Een nieuwe coach voor de ploeg van mijn zoon - toen 11 jaar oud - was te laat op training. Geen speeltijd, dachten de spelers, trainen gaan we doen. Drie van hen namen in overleg de touwtjes in handen en startten de training. De ene na de andere oefening volgde. En toen de coach eindelijk arriveerde, geloofde hij zijn ogen niet. Wie mensen ruimte en vertrouwen durft geven, merkt al - zelfs op heel jonge leeftijd - wat ze echt in hun mars hebben. Quod erat demonstrandum.

We kiezen er dan ook bewust voor om naast basketbal-technische zaken, ook onderwerpen als doelen stellen, verantwoordelijkheid nemen en feedback geven… aan bod te laten komen op onze vergaderingen met de coaches. De link met The Beehive is snel gelegd. Want het zijn ook deze skills waar wij op inzetten bij onze zoektocht naar nieuw talent.

Zelfsturende teams als resultaat van zelfsturende teams

The Beehive is het resultaat van zijn eigen ambitie. Want alles waar we nu voor staan, werd door (en voor) het team zelf beraamd. We bevroegen de hele Beehive-zwerm en daaruit bleek dat zelfsturing, gedeeld eigenaarschap en samenwerking bij iedereen hoog op de agenda staat. Daarom trekken we nu met agile teams naar onze klanten. Daarom baseren we onze interne werking op de principes van Sociocratie 3.0. En daarom hebben we een domein voor coaching en mentorship opgericht.

Het voelt dan ook als een voorrecht om nu, na zowel mijn ervaringen als projectmanager als binnen de sportclub, ook in een bedrijfscontext te zien dat als je een team de ruimte geeft om te excelleren, zij dit steeds doen. En dat belooft voor wat komen gaat.

‍

Benieuwd naar alle Beehivers?

Meet The Team.

Wie mensen ruimte en vertrouwen durft geven, merkt snel wat ze echt in hun mars hebben.

We hire for attitude, train for skills and search for talent.

‍

The Beehive als superorganisme

Bij The Beehive is het ontwikkelen van waardevolle software onze core beesiness. Klinkt tof, maar niet uniek. Wat ons anders maakt, is de manier waarop we samenwerken. En dat verhaal zit ook in onze naam omvat: The Beehive.

What’s in a name?

The Beehive betekent letterlijk ‘de bijenkolonie’. En dat is niet toevallig. Van Dale geeft de volgende verklaring: ‘Een hechte samenwerking van bijen zorgt ervoor dat de samenleving een entiteit vorm die boven het niveau van het organisme staat. Bijen zijn dieren die zichzelf al miljoenen jaren organiseren en ook generatie op generatie beter worden.’ En daarmee zijn ook de kernwaarden van ons bedrijf gedefinieerd. Want The Beehive staat voor teamwork en zelfsturing.

Verschillende rollen, één team

Een enkele bij kan niet overleven zonder de groep en de kolonie bestaat niet zonder de bijen. Van het beschermen van de bijenkorf tot het verzamelen van nectar. Elke bij vervult zijn specifieke rol en heeft een cruciale rol in de symbiose.

Zo gaat het ook bij ons. The Beehive bestaat uit een groep bijzondere mensen. Iedereen draagt zijn steentje bij tot de groep en elk individu heeft de groep nodig om te excelleren.

Via agile principes en patronen uit Sociocratie 3.0 geven we iedereen de mogelijkheid om zichzelf te ontplooien en tegelijk verschillende rollen op te nemen die cruciaal zijn voor de groei van The Beehive. Sommigen focussen het liefst op het ontwikkelen van waardevolle software. Punt uit. Anderen willen coachen, onze branding meehelpen vormgeven, een publiek inspireren, of een blogtekst schrijven. Dankzij transparante communicatie en gedeelde verantwoordelijkheidszin zorgen we ervoor dat iedereen steeds zijn ambities kan waarmaken.

Onze missie

Een bijenkolonie weet - onbewust - wat het gezamenlijke doel is. Overleven. In de bedrijfswereld wordt dat een missie genoemd. Het ontwikkelen van waardevolle software en talent, is de gemeenschappelijke missie van The Beehive. Alles wat we doen, staat in teken van dat hoger doel. Vraag aan elk van ons hoe je de beste en meest eenvoudige softwareoplossing maakt, en krijgt telkens hetzelfde antwoord. Het is dat gemeenschappelijke draagvlak dat ons in staat stelt om het steeds beter te doen.

Onze mensen zijn niet alleen de beste ontwikkelaars en projectmanagers. Ook halen ze het beste in elkaar naar boven en versterken ze tegelijk de business value van onze klanten.

Een duurzaam verhaal

Bijen kunnen niet alleen aarden in verschillende omstandigheden, ze helpen ook bij de bestuiving van bloemen in de omgeving. Dat is hun manier van bijdragen. En ook bij The Beehive willen we meeschrijven aan een duurzaam verhaal. In IT-consultancy is het verkleinen van de CO2-voetafdruk de grootste uitdaging. We zijn op goede weg, maar kunnen ook toegeven dat we nog stappen te zetten hebben. We zijn steeds eerlijk, zowel binnen onze eigen teams als naar de klanten toe. En ook zo bouwen we aan duurzame relaties.

Oog voor elk talent

De bij is een bedrijvig dier. Soms zien we er één naar een bloem vliegen om nectar te drinken, tegelijk verzorgen andere bijen in de bijenkorf de larven. Dat laatste is onzichtbaar voor de buitenwereld, maar toch zijn beide rollen even belangrijk voor het voortbestaan van de kolonie.

En zo is het ook met werken in de The Beehive. Wij plaatsen iedereen op hetzelfde schap. Elke bijdrage - of ze nu zichtbaar is of achter de schermen - is even belangrijk. Bij The Beehive hoeft niet iedereen een overtuigende Ted Talk te kunnen geven. Even min zoeken we in elke medewerker een eersteklas coach. Samen zijn we wel steeds sterker, in team, als superorganisme.

‍

‍

Benieuwd of jouw skills een plek vinden in onze bijenkorf?

Neem een kijkje bij onze vacatures.

‍

Meer dan een developer

Deze Full Stack ontwikkelaar is niet alleen een vaste waarde bij één van onze teams bij de klant. Hij werkt ook heel hard mee aan verschillende domeinen in The Beehive om op die manier zijn steentje bij te dragen aan de groei en evolutie van ons bedrijf!

Wil je weten hoe hij zijn hart verloor aan IT en aan The Beehive, ontdek het van hemzelf in het filmpje hieronder.

Meer Info

Interesse om meer te weten over ons, kijk dan even hier.

Ben je zelf gebeten door IT en wil je bij ons aan de slag? Bekijk dan onze jobsite.

‍

Meer dan Java

De JVM brengt vele voordelen met zich mee die over meerdere decennia verfijnd werden. Applicaties die geschreven zijn, met de JVM als basis, kunnen dan ook gebruik maken van gedeelde bibliotheken en werken met dezelfde datastructuren. Hieronder gaan we dieper in op de meest prominente programmeertalen die gemaakt zijn voor de JVM. Van Kotlin en Scala tot de minder gekende Jython en JRuby. Deze talen vullen op een eenvoudige en flexibele manier Java’s tekortkomingen aan.

Kotlin

Kotlin is ontwikkeld door JetBrains in 2010 en werd open-source beschikbaar gesteld in 2012. De syntax is beknopter en minder uitgebreid dan die van Java. Dit betekent dat de compilatie van Kotlin dan ook veel sneller gaat dan die van zijn tegenhangers. Vanuit de basis laat Kotlin ook veel stijlen toe van functioneel programmeren, in tegenstelling tot Java. De elegante manieren van het omgaan met “null-safety” in Kotlin is dan ook één van zijn meest prominente features. Recent heeft Android dan ook beslist om af te stappen van Java en Kotlin te verkiezen als programmeertaal voor app ontwikkeling op zijn platform. De toekomst van Kotlin heeft nog veel in zijn mars. Eén van de toekomstplannen is het compileren van Kotlin naar machine-native byte code om de performantie verder te optimaliseren.

Scala

Martin Odersky ontwikkelde Scala in 2004 om Java ontwikkelaars productiever te maken. Het combineert functionele en objectgeoriënteerde programmeermodellen in eenzelfde taal. Dat zorgde ervoor dat het functionele model beschikbaar en bruikbaar werd in het Java ecosysteem. De syntax van Scala leunt ook veel dichter bij die van Java aan dan zijn grote tegenhanger Clojure.

Clojure

In 2007 werd Clojure toegankelijk gesteld voor het grote publiek. De functionele programmeertaal, door Rich Hickey ontwikkeld, heeft zijn plaats gevonden als de prominentste Lisp implementatie op de JVM. Clojure is ontwikkeld om een antwoord te bieden op het schrijven van applicaties die gelijktijdig met een hoge performantie data dienen te verwerken. Het kan ingezet worden op elke omgeving waar Java draait en brengt een andere uitgebreide set aan programmeerstijlen dan diegene die door Java ondersteund worden.

Groovy

Groovy is ontwikkeld door Pivotal en tot op heden beheerd door de Apache Software Foundation. Het is een programmeertaal die sterk voortbouwt op de bestaande kennis van Java ontwikkelaars en brengt vele features met zich mee die gebaseerd zijn op dynamische talen zoals Python en Ruby. Groovy is direct gesupporterd door het populaire Jenkins en ligt aan de basis van het web framework Grails.

Jython en JRuby

Jython en JRuby zijn, respectievelijk, implementaties van Python en Ruby voor de JVM. Beide worden ze dynamisch gecompileerd naar Java-bytecode en kan op een eenvoudige manier samenwerken met andere JVM-talen, hoofdzakelijk Java.

Andere JVM talen

Er bestaan nog vele, minder bekende, JVM-talen. Hieronder kan je enkele opmerkelijke voorbeelden vinden.

• Frege: Een JVM-versie van de functionele taal Haskell. Het brengt de Haskell immutability en functionele paradigma’s naar Java code klassen.
• Eta: Een tweede variant van Haskell voor de JVM. Het grote voordeel van Eta over Frege is dat het gebruik kan maken van bestaande Haskell’s package repository. Hierdoor is er een grote compatibiliteit met het bestaande Haskell ecosysteem.
• Ceylon: Door Red Hat ontwikkeld om enkele Java issues op te lossen. Het verbindt zich meer met onderliggende JVM-mechanismen en lost de verbositeit van Java deels op.
• Fantom: Een programmeertaal dat implementaties biedt voor zowel de JVM als voor .NET CLR. Het biedt een abstracte API die een brug vormt tussen de grote verschillen van beide platformen. Fantom kan tevens ook gecompileerd worden naar Javascript waardoor de mogelijkheden bijna eindeloos worden.

Een groot aanbod aan talen, The Beehive heeft de juiste kennis

Al deze talen laten communiceren met de juiste applicaties en JVM is een kunst op zich. Een kunst die onze teams onder de knie hebben. Wil jij jouw applicatie laten ontwikkelen met JVM? The Beehive vormt voor jou het antwoord. Neem zeker contact met ons op als je meer informatie wil krijgen over de voordelen van JVM voor jouw applicaties. Of lees onze blogpost ‘JVM- alle voordelen op een rijtje’

‍

Wat zijn de voordelen van werken met een team versus meerdere consultants?

Dat werken in een team onze consultancy naar een hoger niveau tilt, vertelden we je al in Hoe ervaart The Beehive werken in een Team. Maar wist je dat deze manier van werken ook voor de klant van grote waarde is? Een team dat goed op elkaar is ingespeeld, kan sneller aan de slag, werkt efficiënter en boekt bijgevolg sneller resultaten. En er zijn nog meer voordelen.

1. Ga onmiddellijk aan de slag met de juiste profielen

Wil je extra mankracht inhuren, dan moet je op zoek naar de juiste mensen. En dat kost tijd. Recruiters proberen vanuit een interview de sterke en zwakke punten van sollicitanten te achterhalen. In theorie is dat nuttig, maar in praktijk blijkt dit een harde noot om te kraken, aangezien je iemands talenten pas echt ontdekt na een langere samenwerking. Bovendien is het moeilijk om op voorhand in te schatten of je consultant zal matchen met het team waarin hij terechtkomt. Bij The Beehive selecteren we altijd de juiste mensen voor je project en sturen we enkel goed geoliede teams op pad. Wie kiest voor een Beehive-team, vermijdt dus een recruteringsproces en bespaart zo tijd (en geld).

2. Draai meteen op volle capaciteit met goed geoliede teams

Ook al hebben je consultants de juiste technische kennis, losse experten vormen geen team. Consultants uit verschillende bedrijven en met een verschillende achtergrond, hebben tijd nodig om elkaar te leren kennen, hun plaats in de groep op te eisen en hun gezamenlijke aanpak uit te tekenen. En daarom draait zo’n nieuw team niet meteen op volle toeren. Een gemiste kans, want het kan anders. Een Beehive-team maakt wel een vliegende start. Hoe dat komt?

• Al onze teams hebben een gelijkaardige aanpak. Wordt er een nieuw team gevormd? Dan weet iedereen op voorhand welke rol(len) hij/zij opneemt.
• Binnen onze teams is alles bespreekbaar. Zo vermijden we onuitgesproken frustraties en creëren we een veilige omgeving waarin elk teamlid zichzelf kan zijn.

En wat als een consultant voor langere periode uitvalt? Door iemand van onze eigen mensen in het bestaande team te zetten, vermijden we niet alleen hoge (her)opstartkosten, maar houden we het team ook draaiende. En dat is zowel in het voordeel van het bestaande team, het nieuwe teamlid als jouw organisatie.

3. Een team weet meer

Elk zijn specialiteit. De ene ontwikkelaar kent een bepaald framework vanbinnen en vanbuiten, terwijl een andere alles weet over een specifieke database. Het gamma aan tools en technologieën is zo groot dat het onmogelijk is om je op elk vlak als expert te profileren. Maar samen kan dat wel. Want door onze kennis onderling met elkaar te delen, inspireren en versterken we elkaar.

4. Een Beehive-team werkt ook samen met anderen

Waar verschillende teams naast elkaar aan verschillende domeinen werken, loop je altijd het risico dat er tussen de teams - soms grote - verschillen ontstaan. Dit is nefast voor de samenwerking tussen de teams onderling, maar ook voor het toekomstig onderhoud van de opgeleverde software.

Een Beehive-team werkt samen met elkaar, maar ook met anderen uit je organisatie. Daarom nemen onze mensen deel aan team-overkoepelende guilds, waarin zaken die voor iedereen van belang zijn besproken worden. Thema’s zoals onze werkwijze, nieuwe architecturen en frameworks komen er aan bod.

Ook wanneer we met een uitdaging geconfronteerd worden die belangrijke informatie bevat voor anderen binnen jouw organisatie, deinzen we er niet voor terug om die kennis te delen. Dit doen we door onze info te documenteren of in een sessie te presenteren. Hiermee garanderen we dat iedere betrokken partij altijd de nodige kennis heeft om problemen aan te pakken.

5. Een team dat reflecteert, optimaliseert

Elk nieuw project vaart een andere koers. Hoe zal de lifecycle eruit zien? Uit welke verschillende fases bestaat het project? En hoe kunnen we die visualiseren zodat iedereen op de hoogte is van elke statusupdate.

De basis van elke lifecycle is vaak dezelfde. Of we vertrekken vanuit een flow die we eerder hanteerden, of we houden ons vast aan de bestaande workflow van jouw bedrijf. Als we merken dat een bepaalde flow niet voldoet, gaan we een gesprek niet uit de weg om zo snel mogelijk een oplossing te vinden.

Bij The Beehive zijn we er ons van bewust dat werken in een team altijd een leerproces is. En omdat de perfecte manier van samenwerken niet bestaat, sturen we continu bij. Dit doen we in doelgerichte reflectiemomenten waarin we zowel het eigen functioneren als de werking van het volledige team in vraag durven stellen. Respect voor elkaar vinden we daarbij het allerbelangrijkste. Reflecteren maakt deel uit van ons dagelijks functioneren. Het is onze manier om de lat voor onszelf hoog te leggen.

‍

In eenvoud

Simplicity… Hou het simpel, eenvoudig oftewel gebruik je gezond verstand. Dat zijn maar enkele zaken die je zult horen vallen wanneer je in één van onze teams actief bent. Wij vinden het belangrijk dat we niet in de val lopen het onszelf te moeilijk maken. Gaan we daardoor een uitdaging uit de weg? Helemaal niet! Wij houden van een uitdaging maar gaan wel stap per stap bekijken hoe we die uitdaging op een zo eenvoudige manier kunnen tackelen.

Voor The Beehive zien we drie maal het belang van in eenvoud te werken. De eerste is in ons eigen team waarbij we vooral oog hebben voor onze interne communicatie. De tweede pijler is de link met de klant waarbij we de focus leggen op transparantie en de derde poot is onze technische poot. Eenvoudige software om zo het meeste waarde o te brengen.

De eenvoud in ons eigen team

De dag is gekomen. We mogen met The Beehive een team opstarten bij een nieuwe klant. Enkele teamleden kennen elkaar en hebben zelfs al samen op een project gewerkt. Sommigen hebben dit nog niet meegemaakt en maken dus een soort van aanpassingsperiode door. Dat vraagt om de nodige afspraken in de manier van werken met elkaar. Noem het gerust een playbook. Dat playbook moeten we neerschrijven zodat we erop kunnen terugvallen wanneer sommige afspraken irrelevant worden, aangepast moeten worden of wanneer er iemand nieuw in het team komt.

In dat playbook staan volgende zaken opgelijst:

• De manier van communiceren in ons team, wat steeds op een open en veilige manier gebeurt.
• Communicatie met de klant
• Communicatie met de teams van de klant.
• Hoedanigheid (teamlead, developer, architect,...) waarin iedereen met de klant praat, om zo duidelijke rollen op te nemen in het team en verantwoordelijkheden over een specifiek aspect van het project te verdelen.

In dat playbook gaan we het onder meer hebben over de manier van communiceren onderling, dat moet steeds op een open en veilige manier. Hoe we die veilige omgeving creëren komt aan bod in een volgend artikel. Communicatie met de klant komt aan bod, ook andere teams bij de klant waar we misschien en wellicht afhankelijkheden hebben in ons dagelijks werk. We spreken af wie in welke hoedanigheid (teamlead, developer, architect, …) met de klant praat zodat het voor iedereen duidelijk is wie welke rol opneemt binnenin het team en wie de verantwoordelijkheid over een specifiek aspect van het project opneemt.

Als team willen we de communicatielijnen zo kort mogelijk houden. Dat doen we door enkele vaste momenten in een sprint in te plannen. Dagelijks zien we elkaar op een afgesproken uur waarbij onze vooruitgang enblokkerende factoren bespreken, of gewoon advies vragen bij een bepaald onderwerp. In de sprintplanning houden we overzicht op het werk en toetsen we af of we met de juiste prioriteiten bezig zijn. Uiteraard leer je hierdoor ook wat je aankan als team binnenin de afgesproken periode van de sprint. Als laatste is het belangrijk om regelmatig ‘de temperatuur in het team te meten’. Dit doen we door retrospectieven in te plannen na elke sprint. We houden dit eenvoudig maar aangenaam en veilig waardoor het geen sleur wordt, wat wel een veelvoorkomend struikelblok is in veel teams. ‘Inspect and adapt’ als basis agile principes om te groeien en toch eenvoudig te houden.

Je leest dit nu misschien en denkt bij jezelf, “ik lees hier niets wereldschokkends…” en daar heb je volledig gelijk in! Dit is niet moeilijk, je moet gewoon stilstaan bij de samenstelling van je team en wat je als team nodig hebt om zo optimaal mogelijk aan de slag te kunnen. Eenvoud en simplicity staan gelijk aan afspraken maken en communiceren met elkaar. Doe dit NIET en je wordt vroeg of laat stuurloos als team. Dus maak afspraken, schrijf ze op en hou je eraan. Dit is niet moeilijk maar het is gemakkelijker om het niet te doen of een hele complexe structuur uit te werken en laat dat nu net iets zijn waar veel teams zich aan laten vangen.

“Het project moet ook vanuit de business noden gestuurd worden”

Eenvoud in onze relatie en samenwerking met de klant

Eén van de grote uitdagingen is dat ICT onvoldoende weet wat de klant wil en dat de klant niet weet wat ICT kan en tegen welke tijd en kost. Daarom is het belangrijk dat we allen dezelfde taal spreken zodat we elkaar verstaan. Maar hoe vertaal je dit nu concreet in een business project op een eenvoudige en laagdrempelige manier.

Eérst en vooral is het belangrijk dat iedereen van het team begrijpt wat het business doel is van het project en dit niet louter bekijkt met zijn eigen (technische) bril. Dit bekom je door het volledige team te betrekken vanaf het begin van het project, en dit van ontwikkelaars tot de eindgebruikers, tot de effectieve uitrol ervan en dit tijdens gezamenlijke momenten tijdens een project. De ideale kruisbestuiving kan spontaan tot stand komen door samen te gaan zitten.

Het project moet ook vanuit de business noden gestuurd worden. Daarom is het belangrijk dat we eerst bepalen wat het einddoel is en dat we dan bepalen hoe we er gaan komen. In Jip en Janneke taal gaan we die grote olifant gaan verdelen in kleinere beheersbare functionele doelstellingen die we volgens prioriteit gaan implementeren en uitrollen.

Ook is het belangrijk om vrij snel boven water te komen omdat het beschrijven van de noden één ding is, maar het valideren ervan pas goed kan gebeuren door het product te gaan gebruiken en dit zowel voor de functionele als niet functionele noden.

Open en transparante communicatie is ook “key” tussen de partij die een product bouwt en de klant. Tracht dus te vermijden dat de communicatie enkel gebeurd op basis van “green and red flags” rapporteren maar ook door de resultaten te tonen om de x weken. Ook is het belangrijk om de uitdagingen te kunnen benoemen en niet te denken van “oei als ik problemen ga melden gaat men denken dat we het project niet onder controle hebben”. Het tegendeel is waar! Hoe beter en sneller we een probleem kunnen duiden hoe beter we het project onder controle hebben. De kunst van het weten wat je niet weet is dus enorm belangrijk.

Eenvoud technisch

Ons doel blijft om value op te leveren voor u als klant, doormiddel van het bouwen van een software systeem dat voldoet aan de gegeven functionele, beveiliging en performantie noden terwijl deze zo overzichtelijk en onderhoudbaar blijft als mogelijk. Daartoe zijn onze technische doelstellingen eenvoud, modulariteit en kwaliteit.

Eenvoud

Door simpliciteit verlagen we zoveel mogelijk het aantal verschillende onderdelen in het systeem waardoor de verstaanbaarheid hoog blijft en het aantal delen dat kan falen verlaagd wordt wat een positieve impact heeft op de beschikbaarheid van het systeem. Daarnaast houden we de niet-essentiële complexiteit zo laag mogelijk zodat verdere uitbreidingen van het systeem snel en efficiënt kunnen gebeuren.

Modulariteit

Door modulariteit verhogen we de testbaarheid van het systeem en verlagen we de afhankelijkheid tussen verschillende delen van het systeem. Daarnaast laat dit ons toe om aanpassingen te doen in het systeem met minimale impact op de niet gerelateerde delen waardoor onverwacht gedrag vermeden word.

Kwaliteit

Kwaliteit betekent dat we de volgende 2 metrics zo laag mogelijk willen houden: Het percentage van aanpassingen dat tot falen leid in productie, en hoe snel het falen opgelost kan worden eens het gededecteerd is.

‍

De Java Virtual Machine

De Java Virtual Machine (JVM) is een onderdeel van de Java Runtime Environment (JRE). Dat is de minimale omgeving die nodig is voor het uitvoeren van Java-applicaties. Voordat een Java-applicatie uitgevoerd kan worden door de JVM, worden deze gecompileerd in bytecode. Dat betekent dat elk programma dat werd gecompileerd naar bytecode uitgevoerd kan worden door elk platform, zo lang er de JVM op geïnstalleerd is.

Welke voordelen heeft JVM?

We hebben niet zomaar gekozen om hoofdzakelijk te werken met JVM. Er zijn tal van voordelen verbonden aan het ecosysteem. We sommen graag de 5 belangrijkste voordelen voor je op.

Write once, run anywhere

De grote kracht van het JVM-ecosysteem is het “write once, run anywhere” principe. In tegenstelling tot native talen zoals C, die gecompileerd worden voor specifieke platformen, worden de talen die met JVM werken, gecompileerd naar bytecode. Dat zorgt ervoor dat elk platform waarop JVM geïnstalleerd is de bytecode kan interpreteren naar de platform specifieke native instructie taal.

Een gangbare API

Vervolgens maakt de JVM gebruik van een gangbare API om gebruik te kunnen maken van platform specifieke resources. Een voorbeeld hiervan is dat je niet moet nadenken over het aanspreken van bestanden op het platform doordat JVM dit voor jou oplost. Door gebruik te maken van een generieke I/O API om toegang te krijgen tot het bestandsysteem word je op dit gebied volledig ontzorgd. Langs de andere kant kan je hier ook gebruik van maken om andere resources mee te beheren zoals geheugen, netwerk, randapparatuur, etc.

Een goed beveiligde applicatie dankzij de built-in securityfeatures

Ook de built-in securityfeatures van de Java Virtual Machine komen goed van pas. Deze zorgen ervoor dat je op een eenvoudige manier toch zeer goed beveiligde applicatie kan gaan ontwikkelen. Het zorgt voor een scheidingslaag tussen de applicatie, bijvoorbeeld Java, en de resources van het Operating System (OS) waartoe de applicatie geen directe toegang zou kunnen verkrijgen

Gegenereerde code altijd correct dankzij validatie

De JVM zorgt ook voor validatie van de code. Elke keer dat de bytecode geladen wordt door de JVM wordt er een validatie gedaan volgens een vastgelegde specificatie in de JVM zelf. Het zorgt ervoor dat de gegenereerde code altijd correct geschreven is en gecompileerd wordt door een gevalideerde compiler. Enkele voorbeelden van validatie is het nagaan van zaken als toewijzing van geheugenlocaties en zondigingen tegen de “JVM constraints”.

Geheugenlocaties worden automatisch toegewezen

Het toewijzen van geheugenlocaties is een zeer belangrijk proces. Dat wordt volledig afgehandeld door de JVM zelf waardoor de ontwikkelaar zich hier geen zorgen over dient te maken. Dat is wel het geval bij platform native talen zoals bijvoorbeeld C. Het volledige beheer van toewijzing en opruiming van geheugenlocaties wordt door een subsysteem van JVM afgehandeld, de Garbage Collector (GC). Dit zorgt ervoor dat de kans op memory leaks drastisch afneemt ten opzichte van native talen zoals C.

“Eén keer schrijven, overal uitvoeren”

JVM-evolutie: verleden, heden, toekomst

In 1995 introduceerde de JVM twee revolutionaire concepten, zoals hierboven reeds beschreven, die sindsdien standaard zijn geworden voor moderne softwareontwikkeling: "Eén keer schrijven, overal uitvoeren" en automatisch geheugenbeheer. Software-interoperabiliteit was in die tijd een gewaagd concept, maar tegenwoordig zouden maar weinig ontwikkelaars er twee keer over nadenken.

We zouden kunnen zeggen dat James Gosling en Brendan Eich de moderne programmering hebben uitgevonden, maar duizenden anderen hebben hun ideeën in de daaropvolgende decennia verfijnd en verder ontwikkeld. Waar de Java Virtual Machine oorspronkelijk alleen voor Java was, is deze tegenwoordig geëvolueerd om vele scripting- en programmeertalen te ondersteunen, waaronder Scala, Groovy en Kotlin. Vooruitkijkend, is het moeilijk om een toekomst te zien waarin de JVM geen prominent onderdeel is van het ontwikkelingslandschap. We kijken alvast uit naar de komende evoluties binnen het JVM-ecosysteem.

‍

Hoe ervaren wij werken in TEAM?

Hoewel veel mensen die er zelf niet mee bezig zijn, denken dat de meeste software door een lone wolf in een donkere kelder geschreven werd, gaat het er in realiteit net iets anders aan toe. Aan de grondslag van de meeste projecten staat een team van experts die het beste van zichzelf gegeven hebben bij het schrijven van de code.

Deze teams kon je vroeger in twee grote groepen opdelen:

• Enerzijds had je de teams die deel uitmaken van het bedrijf dat eigenaar is van de applicatie. Veelal werken deze teams jaren aan dezelfde applicatie, waardoor de kost voor het bedrijf constant blijft. Er zijn twee zaken die dit bedrijf kan doen om deze kosten aan te pakken. Een deel van het team kan ingeschakeld worden bij de ontwikkeling van een andere applicatie – als deze er zou zijn – of er kan een deel van het team ontslagen worden om zo kosten te gaan besparen.
• Anderzijds heb je als bedrijf de mogelijkheid om een team samen te stellen uit ontwikkelaars die je kan inhuren bij dienstverlenende bedrijven, de zogenaamde consultants. Hiermee kan je een team vormen, dat je ook nog kan aanvullen met eigen krachten om zo toch een deel van de kennis binnen het eigen bedrijf te houden. Nadat de ontwikkeling klaar is, loopt de opdracht van de consultants af en gaan ze naar een ander project, vaak bij een ander bedrijf. Je eigen mensen nemen in dat geval het onderhoud van de software voor hun rekening.

Wij bij The Beehive werken nog net iets anders. Je zou ons wel kunnen indelen bij de tweede groep, maar in plaats van dat wij losse consultants aanbieden, focussen wij op meer ontzorging door een team aan te bieden. In deze post beschrijven wij wat we hiermee voor u kunnen betekenen.

Wat is een team bij The Beehive?

In de sport zie je heel vaak teams aan het werk, verschillende atleten die samenwerken om een zo goed mogelijk resultaat neer te zetten en (hopelijk) de overwinning te behalen. In andere omgevingen is het de teams niet zozeer te doen om de overwinning te behalen, maar wel om een optimaal resultaat neer te zetten. Dat is voor ons ook zo wanneer we software-oplossingen uitwerken. Verschillende experts werken samen op een manier die bij hen past, zodat ze efficiënt kunnen werken om resultaten te boeken. Onze softwareteams bestaan niet alleen uit ontwikkelaars, maar we voorzien ook specialisten die het team helpen om zo goed mogelijk te werken en om de communicatie met alle stakeholders op zich te nemen. Je zal bij onze teams naast de developers ook een scrum masters, architecten, product owners, projectmanagers en dergelijke tegenkomen.

Voor ons is een team niet noodzakelijk een groep mensen die altijd alleen maar met dezelfde mensen samenwerkt. We kiezen er bewust voor om onze teams samen te stellen op basis van de noden van het project waaraan we werken. Grote projecten zijn vaak geschikt voor grotere teams dan kleine projecten. Bepaalde technische vraagstukken vereisen specifieke kennis die voor andere projecten misschien niet zo relevant is, … Door hier slim mee om te gaan kunnen we onze beschikbare mensen optimaal inzetten. Dat is niet alleen interessant voor het project, maar zeker ook voor onze medewerkers. Het geeft hun de kans om nieuwe zaken bij te leren, waardoor ieder teamlid continu kan groeien.

Het verschil tussen verschillende consultants en een team

Wat is dan het grote verschil tussen het samenbrengen van consultants (uit verschillende bedrijven) en het inhuren van een team? Onze mensen hebben, ongeacht hun achtergrond, een gelijkaardige visie op hoe ze het beste presteren. Onze teams werken altijd op een agile manier, wat hen de mogelijkheid geeft om hun werk flexibel in te plannen, volgens hun eigen beschikbaarheid en rekening houdende met de prioriteiten. Ook de manier waarop ze werken kunnen ze continu bijsturen. Indien het team merkt dat er iets is dat volgens hen beter kan, kunnen ze hier als team over nadenken en bijsturen waar nodig. Hierdoor evolueert het team en kunnen ze op termijn steeds beter werk leveren.

“Onze mensen hebben, ongeacht hun achtergrond, een gelijkaardige visie op hoe ze het beste presteren.”

Samen voor en met de klant

Hoewel we een volledig team aanbieden, zien we er nog steeds een meerwaarde in om echt samen te werken met de klant. Uiteraard moet de klant betrokken zijn bij het ontwikkelproces, hij is uiteindelijk de enige die echt weet wat hij écht nodig heeft. Het is voor ons niet voldoende om dit in uitgebreide, uitgeschreven user stories te krijgen. Deze user stories zijn uiteraard wel nodig, zodat ons team weet wat ze juist moeten ontwikkelen, maar het is lang niet het enige waarin we de klant willen betrekken.

Voor ons is het ook heel belangrijk dat we regelmatig een update kunnen tonen aan onze klanten. We willen laten zien wat ons team de afgelopen periode gerealiseerd heeft. Liefst van al willen we dat de klant hier al mee aan de slag kan op een testomgeving. Door er al mee aan de slag te gaan, kan de klant beter inschatten of datgene dat opgeleverd is voldoet aan de vereisten. Dat resulteert automatisch in nuttige feedback waarmee het team opnieuw aan de slag kan om eventuele aanpassingen door te voeren. De betrokkenheid van de klant helpt ons ook in het bepalen van de prioriteiten. Zo leveren we steeds zo snel mogelijk op wat het meest waardevol is voor de klant en de eindgebruiker.

Een samengesteld team van de klant en The Beehive: een mooie leerrijke combo

Ook is het mogelijk om in onze teams technische medewerkers van de klant mee in te schakelen. Het grootste voordeel hier is kennisdeling. Enerzijds kan ons team gebruik maken van de domeinkennis van de extra medewerker(s). De inzichten die we hieruit halen, helpen ons om een oplossing uit te denken die zo goed mogelijk bij de klant past. Anderzijds kunnen we ook de medewerkers van de klant helpen om een zo diep mogelijk begrip van de nieuwe oplossing te vergaren. Dat is vooral interessant om na het ontwikkelproces de door ons opgeleverde software up to date te houden, zodat de oplossing lang kan meegaan. Het is in dat geval beter dat ontwikkelaars van de klant zo nauw mogelijk betrokken geweest zijn bij het ontwikkelproces. De kennis die ze hierdoor opdoen gaat veel dieper dan wat je kan beschrijven in de documentatie.

We staan ook steeds klaar voor andere teams die actief zijn bij de klant, zeker als ze moeten integreren met onze applicatie of de data die we verzamelen. Door deze samenwerking te faciliteren, proberen we de overhead te beperken die je vaak kan zien als verschillende teams raakvlakken hebben. Waar in een meer traditionele setup, de teams die API’s of data van andere projecten willen gebruiken, zich moeten baseren op de documentatie, kunnen we de andere teams versnellen door met hen in gesprek te gaan.

Het begin van een mooi verhaal

Wij zijn ervan overtuigd dat onze teamwerking echt een meerwaarde kan zijn voor onze klanten. Doordat ieder teamlid zich goed voelt binnen het team, kunnen we bergen verzetten en waarde opleveren voor het project waaraan we bezig zijn. Elke dag opnieuw staat het team klaar om nieuwe uitdagingen aan te gaan en stappen te zetten richting het doel van het project.

‍

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.

‍