CI / CD in practice

In this blog I want to take you, the reader, with me on my quest on finding a comprehensive CI / CD practice for a moderate to big corporate environment. I personally think efficiency is reached when your practices relate to other processes in the organisation. So In this blog, it isn’t that much about tooling but more of the interconnections between the tooling and the practice.

The tools

As you might know I am a Microsoft developer, so the tool of choice is Azure DevOps. I implement apps and api’s, so add Azure, Xamarin and to the list of tools too.

My development process of choice is a ‘real’ Agile environment using Scrum, DevOps and Google design sprints. Agile is all about team trust and team responsibilities. Good CI/CD is very difficult if the team isn’t trusted with the task at hand.

The pipe

Basic strategy

Everything that get’s build/produced is under code control. So when I say ‘code’ it could be all kinds of development work, not limited to programming apps/api’s.

We work on master alone. And only (automated) pull requests gets merged to master (CI).

The pull request is part of our Scrum Definition of Done, and thus gated with a review and a 2-pair eyes policy. Plus additional checks incorporated into the build like unittests and SonarQube analysis.

In the CD pipe we always incorporates an automated test step, in short AT. Postman for .Net (Core) API’s, Xamarin SpecFlow UI testing for apps, Protractor tests for Angular web apps.

There are different CI/CD builds pairs for different components in the landscape. We strive to have a 1 on 1 relation between a build definition and a component. But there could be a couple of codebases in one repository, especially with the ‘start small, specialize later’ approach most of our projects take.

If we use components, we want to use as much ‘native’ as possible. If we make components ourselves and they are shared components, we avoid interconnections between products: a change in one component can’t automatically result in a few broken (non build-able) products elsewhere.

Make sure all this stuff is easily automated and easy to maintain.
In my field of work this all leans heavy on mechanisms in Azure DevOps. They do supply a lot of tooling to get these things like triggers and gate policies automated, have integrated components versioning strategies, and all these things actually work out-of-the-box.

But don’t over automate. Seriously. Rigorous gating checks and extensive templating breeds laziness. Agile is about people, and using the right tools for the right jobs. I think the key to working fast isn’t about automating alone but more about a balancing act between doing things yourself and let others do the work for you.


All work starts with the Scrum Sprint. From there on we define stories. These stories get refined, and when planned for sprinting the tasks get defined. The tasks are then used to attach one branch to when there is a need for a code change.

So in practice, each task that has a code change that triggers the whole CD pipeline. So for each part of your code you know the delta in stability because of the rigorous checks that the AT environment will do.

Make sure you know the impact of the business side (features/stories) on your product.
With our practice we know for each task and story how it impacts our total codebase and how well the new code integrates into the old.

I hear some of you thinking: ‘but each merge into master gets released if you do CD’.
Being practical, I know that not all of the code can be released as soon as it seems to work. I think it is perfectly fine to gather work at the A environment and review it during the Sprint Demo, and start release it afterwards. But I want to add to this that this is for functional reasons only, like instructing users, instructing 1st/2nd line support or getting functional approvals from involved parties.


My CI/CD strategy is build on testing: fail fast and fail often.

Early stage checks should be red often, because I believe that you only learn (and grow) through failure. The CI builds should fail the most, the TA environment should gate 99.9% of the others failures. In acceptance, there must be only functional issues that could halt the pipe.

I don’t believe in a dedicated T environment for manual testing that much. All manual tests are to be automated. If you need some testing, or didn’t automate something yet, our A (Acceptance) environment is supposed to be used for manual (but non-intrusive) testing.

A word on special case testing with prepared databases and such: because we actively monitor the functional coverage of early testing like unittests, and combine this with automated integral testing through API and App testing, there is low to no need for prepared manual special case testings.

I do not believe in total coverage of all kinds of tests all the time. The determined coverage should be the outcome of a risk assessment to determine what parts need what kind,width and dept of coverage.

To make sure there is enough coverage, I rely on a very practical rule.
“I always make sure I trust the code that stands ready on the A environment. I even trust it that much that I dare to start a production release and walk away and go home knowing everything works as intended (and have the support phone with me).”
If I don’t pass this challenge, it is time to revise testing decisions.

And a thing on loadtesting. (TLDR: most of the times it is not worth the investment.)
I only use it on special occasions to get directions, we don’t have it automated in our pipe. To me it is just too errorprone. It is hard to analyse the code to get a meaningfull coverage, and very hard to get production like benchmarking (especially with monthly changing consumer demands that have way more impact than code changes). It is also very expensive to do this kind of testing, because you want to run this on production like environments with production loads to have some meaning.
And why all this if we are in control of support, have live production health monitoring, cloud scaling, and a very fast delivery pipe to correct code if something bad happens to the performance due to bugs?


For me monitoring isn’t restricted to the CI/CD pipe. The released product is the most essential part of the CI/CD, because it tells the real story about the state of the product that is in the CI/CD pipe.

So here are some CI/CD metrics. For us the most important is the state of the pipe (is there a bug detected in code) and where is what code change waiting. This is live on display on dashboard.
But I found out that a lot of the management is interested in CI/CD metrics too because they want to feel in control and thus monitor things like failed build ratio’s or defect ratio’s (features released vs production incidents).

Another part in metrics is our Azure monitoring. We monitor live production performance such as latency, throughput and error rates. These are essential values for product support, but also helpful to determine the quality of the code in production (and thus in the CI/CD pipe). It is difficult however to select the right measurements, and even more difficult to define alert thresholds (because you need to know what action to take, and most of the time you just can’t do a thing about it).

And the last but the most important: business metrics.
Because I think value driven development is the best there is, we want to know what the added value is of each Sprint the team makes. We monitor this by analyzing key points in our products and showing the results on a live dashboard. It is hard to get right, and we aren’t nearly there. But right now a lot of the roadmap is decided on input from these metrics.
Back to CI/CD: you want to know the value of your individual released parts. This can only be done by measuring some kind of business value and relating this to changes made in time.

A note on support: Our metric selection is suited for live support of a real product, but only on a business hours (8/5) support contract. There is 3rd party 1st line support, but they don’t have monitoring. So in essence, I strive for pro-active monitoring during business hours and pro-active error support.

My wishlist

Well, as you might guess I still want to add or change a few things.

  • Better measurements on the added value of releases (to the customer / business). Currently our measurements are not consistently implemented, and when implemented it is most of the time in a customer-facing component. We should add a monitor to report API relevance, the added value of an expensive fail fast-fail often pipe, etc.
  • Better reporting to management on how we perform. I want to have metrics/processes that have an eye for the individual team and its struggles, but at the same time raises the bar so you keep improving. (No, no failed integration build metrics… don’t waste your time on that)

The real deal

This is all from a real-life situation: my current work at the NS.

Here the team dictates the CI/CD strategie (so different teams have different strategies). The team also dictates the Scrum process: when to accept work, how to implement, how to release (ship) it, and how to do maintenance.

To facilitate the team (and only facilitate) there is a so called ‘cloud’ team supplying tooling, and there are architects available for consulting. The boundaries supplied by these entities are relatively free: it puts emphasis on the teams responsibility to deliver outstanding work.

The amount of freedom is monitored by all involved parties. Not all development teams receive the same amount of freedom. That’s oke with me, because trust is something you need to earn. And my team has earned it!

Why Agile is not another buzzword

In my daily life I am a senior software engineer, practicing the latest insights on Agile development. I have seen many organisations, small and big, old or brand-new (even startups). Using this insight I can spot a lot of problems with the often contradictory methods of development organisations are using to create software.

First a quick introduction to Agile development. Because it is often used as a buzzword with few meaning left in it. Non-agile is the factory line: in advance you plan and rule out all odds, the actual work is thus repetitive and not requiring a lot of skills (although you can argue it can still require some practice… but that’s exactly the problem: no thinking involved). It is input driven: someone somewhere decides what has to happen, everything and everyone falls in line to execute on that. Everyone has a predetermined place and function. You don’t need trust, you need rules.

Agile is the opposite. When you are agile you think of what you want to achieve, and make that happen with respect to the current state of the world and the tools at hand. By building on trust, by being in connection with everyone, by embracing the unknown. Yes that sounds idyllic, because that’s how humans like to be.

But why all this Agile or non-Agile? Why bother with project methodologies anyway? Just build something already!
Well, the following picture illustrates how a perfect world would look like. Look at all those connections. It would be great if we would build products in a world where all those connections between the content creators and consumers were flawless.

This image has an empty alt attribute; its file name is agile-gaming-perfect-world.png

However as you probably know from your own experience, all connections between humans suffer from communication issues. This is the same picture, but now with the possible issues.

This image has an empty alt attribute; its file name is agile-gaming-our-world.png

The idea is that a project management method helps you cope with these communication issues. The non-Agile project methods, where almost all game developments methods belong, have the following characteristics:

  • You prepare to make a good-enough product that is sell-able to the masses. (This was done to account for the increasing costs of production, and the consumers accepted it because any product was better than none product at all)
  • You try to mitigate the communication risks by using experts to understand the market’s needs. (This was necessary because your goal was to make something that had maximal impact on as many people as possible, but don’t listen to the individual)
  • You plan in advance with what to build for what cost/benefit. (Because you had to prepare a whole factory line, where profits comes from doing it as efficient as possible)
  • You add a line hierarchy with narrow boundaries to manage your workers. (Because of all these activities, the organisation is like a machine where every gear has its place. But those gears can’t do more than they are ment for, for then the whole thing would turn out to be less efficient.)
  • You use mass media and and deals with large selling companies to get your products to the consumers.

But times are changing. A lot of the problems the non-Agile methods accounted for have been minimized in other ways:

  • Creators and consumers can find each other much more easily. (Much less need for all kinds of parties acting as the middle-man. The internet with platforms like / Amazon have brought both much more close together.)
  • Costs of tooling is so much more lower. (You can work from home, get tooling on-demand without upfront payments.)
  • Access to skills has changed radically. (Flex workers all over the world are available to you with specialized services.)
  • Access to information has changed radically. (You can learn basic to advance skills using the internet (and time/practice) where previously the access was the limiting factor now our time is the only limiting factor.)

Add to this that these non-Agile methods come at a huge cost: the distance of the consumer to the creator is almost automatically enlarged, the time to respond to changes is in terms of quarters and years, and with each change large losses in productivity are unavoidable.

As a matter of fact, a lot of organisations are turning to Agile development nowadays. That is because the costs of non-Agile development out wages the benefits, and customers and workers are demanding a shift in culture.

I know from personal experience that introducing Agile methods in a previously non-Agile environments is a really painful process. The whole organisation has to change to adapt Agile, because otherwise perversely incentives will stay in place and try to re-introduce the bad from non-Agile.

This transition is worth the cost. People will be more happy as workers and as consumers. I hope to write some more blogposts on this subject and link to them from this article. I did write already one on game development over at my game dev site.

I will close this blogpost with a how-to. How to know if a decision on organisation structure of project methodology is Agile or not? I try to think of it as follows.

The past is: thinking in advance (official name: input driven). The future is: building what’s needed (official name: output driven).

Remember: All else is just a remnant of the past. People craving for power and thus aligning the organisation to fuel that craving. Departments creating work to stay relevant. So called ‘experts’ that place the consumer at a distance of the creators, significantly worsen the communication between those two.


Wil je weten hoe een gamejam gaat? Of hoe je er een aan zou kunnen pakken? Ik kon maar met moeite ervaringen van anderen vinden. Dus bij dezen, mijn ervaring met de gamejam in januari 2019.

Dag 1

15:30 Cibap Zwolle

Ik doe dit jaar mee aan de gamejam, en ben opweg naar de start bij Cibap in locatie Zwolle. Het programma geeft aan 15:00 inloop, 16:30 start programma. Door een doolhof van gangen zoek ik mijn weg. Ik blijk de verkeerde ingang genomen te hebben, loop t hele gebouw door naar de andere ingang. Daar vind ik de tafel voor inschrijvingen.

25 man ingeschreven, ruimte voor 75 man. Na de eerste kennismaking blijkt dat een aantal naar andere locaties van de gamejam wilden gaan maar dat die vol zaten. Zwolle heeft maar een beperkte game development scene.

We verzamelen ons in de ruimtes die beschikbaar zijn voor de gamejam. Het wachten wordt verzacht met een lolly, uitgereikt bij de inschrijftafel. En ik ben extra in stemming gebracht met een T-Shirt, wat inbegrepen zat bij de gamejam.

17:00 Kickoff

Van 17:00 tot 18:30 hebben we de start van het programma. We verzamelen ons in een grote zaal met podium. Na een korte intro van de leidende personen en de huisregels krijgen we een filmpje te zien van Rami Ismail heeft het over tekenen, dat iedereen een koe kan tekenen, of er anders een pijltje bij kan zetten met ‘koe’. Ik raak geïnspireerd. De intro sluit af met het thema, gebracht door 2 dames die duidelijk onwennig voor de camera een stukje opvoeren over hun gevoel van ‘thuis’.

Dan volgen er een paar team activiteiten. “Om te bepalen welke personen en eigenschappen elkaar aanvullen.” Eerst een snelle check hoeveel tekenaars/ontwerpers er rondlopen. Er blijkt een team te zijn wat al een vaste samenstelling heeft, 3 artistieke mensen en 1 ontwikkelaar. Maar twee artistieke mensen zijn beschikbaar als team-loos. En nog eens 14 ontwikkelaars. Dat begint goed denk ik.

19:00 diner

Vanaf 19:00 is het diner. Het duurt even, maar na een tijdje arriveert het eten in de vorm van lasagne en spaghetti carbonara. Dat was goed eten. De teams moeten gevormd worden. Veel passiviteit, kan ook niet anders vanwege het overgrote deel aan studenten die toch een beetje onzeker zijn over hun kunnen en wat ze willen. Ik begin gewoon mensen te zoeken. De oudste persoon ter plaatse, Kees, is mijn eerste teamlid. 45 jaar, beheerder bij een recent gesloten ziekenhuis, en nu bezig een carrière in game development te starten. Ik vind nog een andere ontwikkelaar, Peter, en nog een ontwikkelaar/artiest genaamd Jan. Allebei studenten. Daarna gaat ieder team naar een eigen ruimte.

20:00 The first mile

Aangekomen in onze ruimte claim ik de leiding. Recent heb ik bij de NS een 2-tal design sprints gevolgd: 1 week lang intensief samenwerken met alle benodigde disciplines van een ontwikkeltraject en gezamenlijk via een creatief proces het te bouwen product bepalen. Dat wilde ik ook hier gaan doen. In de hoop dat ik zou kunnen oefenen in een neutrale faciliterende rol als spelverdeler.

Via een aantal stappen van ideevorming / reductie hebben we bepaald wat wij met elkaar willen bouwen. Tot 23:00 waren wij bezig om plannen te maken. Geen code aangeraakt. Wel veel besloten. Het concept van de designsprint werkt tot nu toe, alleen wel weinig ‘gebouwd’. Hopelijk betaalt het zich terug.

23:00 we call it a day

We breien er een einde aan voor de dag. De meeste teamleden gaan weer naar huis om daar te slapen. Kees maakt gebruik van de slaapplekken die hier op locatie zijn. Kees geeft ook aan dat hij wel de scaffolding op wil zetten in Unity ergens in de komende uren, als hij een momentje vindt naast t slapen.

Dag 2

07:20 thuis, opstaan

Ik had wat moeite met opstaan. Op de heenweg nog even langs de winkel, extra snacks voor tijdens de jam. Niet dat we per se eten en drinken moesten halen, daarin werden we goed voorzien op de locatie, maar toch. Een paar snacks in handbereik leek mij een goed plan. Net zoals paracetamol. Want ik had toch wel last van hoofdpijn door spanning.

09:00 Cibap Zwolle, ontbijt

Ik kom om 9:00 aan. Het ontbijt was van 08:00 tot 10:00, ik bleek vroeg. Er staat brood en beleg klaar. Ik werk snel een broodje naar binnen.

Aan t werk. Kees was blijven slapen op locatie. Helaas voor Kees maar gelukkig voor ons kon Kees niet slapen en heeft hij in de nacht een paar dingen opgezet. Jan kwam rond 10 uur aan.

Peter had moeite met het OV richting Zwolle te geraken. Wat ik best kan begrijpen. Jan en ik hebben t gemak van een auto en in de buurt wonen, met t OV introduceer je meteen moeilijkheden als je in t weekend vroeg ergens wilt zijn.

Ik probeer het team wat leiding te geven door gezamenlijk korte termijn doelen op te laten stellen. We stellen ons als doel om een basis game neer te zetten tot 13:30.


We gaan voor een gewaagd concept: 2 teams moeten een huis veroveren of verdedigen. T liefst is dit multiplayer te spelen op mobile. En we willen de gameplay asynchroon maken, dus een totaal andere ervaring als je team A of B bent.

bepalen wat we in de komende tijd voor elkaar krijgen

We beginnen maar wat te bouwen in Unity. Want hoewel we nog niet helemaal duidelijk hadden wat we gingen bouwen, realiseerden we ons dat we toch echt wel met de code aan de slag moesten. Ik had uitgerekend dat de jam 13 uur aan bouwen beschikbaar had. Dat krijg je als je een 48 uurs jam neemt en het grootste gedeelte van de tijd slaapt en neven activiteiten uitvoert…

Tussendoor maak ik onze pagina op de site. De game krijgt de naam ‘cozy home – human vs other’. We hebben wat problemen om te bepalen tegen wie je nu precies het opneemt. (Het is uiteindelijk geworden, maar dat wisten we toen nog niet.)

We ontdekken dat Unity zijn (simpele) netwerkoplossing aan het uitfaseren is. Omdat het team weinig kennis heeft op dit gebied, met alleen Kees die er eens een Udemy cursus over gevolgd heeft, zien we multiplayer als een steeds groter wordend risico. Na een kort beraad stellen we een simpele random AI voor als tijdelijke placeholder voor t gedrag van de tegenstander, zodat we niet vastlopen als we geen networking voor elkaar krijgen.

Ik heb niet veel kunnen programmeren vanwege al t organiseren en dingen regelen. Mijn bijdrage deze ochtend aan de code was een basis gameplay flow van menu-selectie-game-ending.

eindresultaat van stap 4, door de groep bepaalde slimme combinatie van de best gewaardeerde gameplay ideeën

13:30 Lunch

We worden gevraagd om naar de lunch te komen. Eigenlijk zijn we best tevreden: we hebben een basis game staan met een menu, level, rond lopend mannetje (‘human’), een huisje en een ending.

Er staan belegde broodjes voor ons klaar. Dat is goed geregeld!

14:00 Lekker jammen

We gaan ons en ons spel voorbereiden voor de eerste playtest.

belangrijkste werkzaamheden in beeld, taken verdelen

Een paar ideeën moeten nog geverifieerd worden. Ik stel een papieren playtest voor om de asymmetrische gameplay te testen want die is heel duur om te bouwen en moet wel werken. Verder kwamen we in discussie of een overlord minion aansturende situatie wel genoeg binding met een huis op zou leveren (en dus home gevoel), dus dat was ook iets wat we gingen testen.

We beginnen ons ook te realiseren dat we ook een extra ending kunnen introduceren die het concept veel sterker maakt: de obvious ending is dat je elkaar uit huis jaagt, de niet-obvious is dat je er samen uit komt.

15:00 Playtesting

Wij waren het eerste team aanwezig in de gemeenschappelijke ruimte. Ik heb er alle vertrouwen in omdat ik de papieren playtest uitvoer. We doen ook een playtest van de unity game op een van onze laptops. Kort schiet het door mijn hoofd dat ik eigenlijk niet echt goed heb opgelet of onze game (dat waar het om draait, lol), eigenlijk wel lekker genoeg aanvoelt. Maar ik ga t prototype bedienen, Kees bedient de game en heeft er de laatste fixes op toegepast.

paper prototype

De playtest. Het gevoel van thuis bleek het beste bij geen afstandelijkheid (geen minion AI, geen afstandelijke overlord). Tijdens de playtest werd duidelijk dat de alternatieve ending een grote pre zou opleveren. Verder merkten wij dat mensen gebalanceerde maar hard-hitting acties leuk vinden. We kregen ook feedback waar we niet om gevraagd hadden: voor velen was er t gevoel dat de human onvermijdelijk gaat winnen bij het binnentreden van het huis, en dat de andere partij hoogstens een delay kan veroorzaken.

De paper prototype werd door veel mensen als heel leuk ervaren. Gewoon een beetje rollenspel spelen. En t was maar goed dat we dat hadden, de game zelf wist minder te trekken. Dat de game niet echt trok viel mij niet op omdat ik de paper prototype bediende, maar achteraf gezien waren hier al signalen dat we gameplay wise niet sterk stonden met onze game.

15:30 Aan t werk

De playtest liep tot 16:00, om 15:30 hadden wij al genoeg info.

We stelden weer nieuwe doelen op. Multiplayer zat er voor nu niet meer in. Wel content, veel meer content.
En natuurlijk geen asymmetrische gameplay: besturing en aanzicht aan beide kanten t zelfde, wel wat verschil qua doel en actions. Een groot voordeel want de UI en interactie systeem zou daarmee herbruikbaar worden.

Vol ideeën weer aan de slag
de prioriteiten zijn ook weer bijgesteld
t werk vordert snel, we moeten al weer nieuwe doelen opstellen

18:00 diner

Het eten komt vroeg voor ons gevoel. Er is nog zo veel te doen. Waar wij bij de playtest nog dachten goed op weg te zijn beginnen we ons nu te realiseren hoe veel er nog moet gebeuren. Effectief gezien zouden we vanaf nu nog maar 6 bouw uren beschikbaar hebben. (Tenzij we op slaap gingen bezuinigen of niet meer mee doen met de gemeenschappelijke activiteiten)

Toch maar eten. Het diner smaakt goed. Lekker Hollandse pot (hutspot en/of stampot, rookworst en gehaktballen). Als team beginnen we al wat beter op elkaar ingespeeld te raken. De tongen zijn losser en we hebben leuke gesprekken.

Na het eten snel weer terug naar onze ruimte. Zo langzamerhand weet iedereen wel wat hij moet doen en komt er minder druk bij mij als spelverdeler te liggen.

Maar we worden al snel onderbroken door de leiding van de gamejam. Er is een gemeenschappelijke gebeurtenis gepland.

19:30 Potten en pannen

Met wat tegenzin begeven we ons naar de gemeenschappelijke ruimte. Daar treffen wij jambe’s aan. En een hele inspirerende instructeur.

let’s hear us for Afrika!

Een uur later, met dikke rode handen, gaan we weer aan t werk. Ik merk dat ik ontspannen ben geraakt van zo’n sessie lekker rammen, dit is iets heel anders dan t programmeer/denk werk.

20:30 meters

We hebben inspiratie. Iedereen weet wel iets om mee aan de slag te gaan. De playtesten hadden leuke resultaten waar we iets mee kunnen.

Zo introduceren we de koe-man ipv duivel, zodat spelers zich beter in kunnen leven. We willen dat beide speelbare kanten een goed home-gevoel kunnen opwekken bij de menselijke spelers. Ons spel heet nu officieel ‘cozy home – human vs cowman’.

Qua werk probeer ik meer in mijn flow te komen. Ik ga de code-behind voor alle cowman dingen bouwen. Tot nu toe hadden we alleen de human kant, dus dit wordt een kopie van die kant plus een ingewikkeld switch mechanisme waarmee je kan wisselen tussen human/cowman maar ook tussen aanvallen/verdedigen.

Ik probeer aan te sluiten bij de heersende programmeer stijl. K heb de hele dag al moeite om erin te komen. Kees heeft al zijn ervaring uit zelfstudies, t zijn geen goede programmeer stijlen maar wie ben ik: als t werk dan werkt het. Vooral als we maar weinig tijd hebben dan wil ik mensen niet uit hun flow halen.

Wat betreft de werkwijzen: Peter werkt hetzelfde als Kees. Peter en Kees maken echt de meters in code. Jan maakt vooral de art, en hangt af en toe wat in elkaar in de Unity designer zoals een nette animatie. Jan blijkt behoorlijk kundig in 2D pixelart.

De game code is een mix van service locater patterns en object-naam gebonden zoekacties. Ik ben onzeker of ik hier wat van moet vinden. Ikzelf zou in ieder geval geen naam-gebonden zoekacties doen, en service locater patterns (als er geen DI framework is) beperken tot t hoogstnoodzakelijke. Liever drag-n-drop ik alles aan elkaar via de designer. Maar ja, ik wil geen oordeel hebben over de programmeer stijlen van de anderen. Want misschien heb ik mijzelf een werkwijze in Unity aangeleerd die niet de meest productieve is, weet ik veel. Ik heb niet veel vanuit zelfstudies gewerkt, ik heb mijzelf gewoon Unity programmeren aangeleerd vanuit mijn jaren ervaring in Enterprise software development.

Rond 11 uur word ik het zat. Ik voorzie nieuwe functionaliteit die we heel slecht kunnen integreren zonder fatsoenlijk aan elkaar hangende code. Dus ben ik toch maar begonnen het DI framework, Zenject, te integreren. Ik weet niet of Zenject de oplossing is, maar ik weet wel dat wat er staat al gauw niet meer te houden is.

Het begint al laat te worden. We zijn ver voorbij de 22:00 die ik mijzelf als doel had gesteld om te stoppen. Ik heb heel veel moeite Zenject er in te krijgen, ze blijken een nieuwe versie met breaking changes te hebben en ik ben alleen bekend met de vorige versie. Om 01:00 geef ik het op. Rollback Zenject. Niet alleen vanwege de Zenject versie, maar t is gewoon te groot om in eens om te gooien en te veel code begint bugs te vertonen.


T belangrijkste wat we deze avond hebben bereikt is dat alles er beter uitziet. Betere graphics, de 2 karakters speelbaar, defender en attacker, alle endings… maar wel dus een kater van de code waar ik mij verantwoordelijk voor voel maar wat niet lekker loopt.

Dag 3


Ik moet vandaag op tijd komen vindt ik. Er moet nog zo veel gebeuren dat ik mij ertoe gezet heb er om 7 uur uit te gaan. Wel voel ik mij moe. Heel moe. Even overwoog ik zelfs de handdoek in de ring te gooien, door mijn code-kater van gisteravond gecombineerd met de moeheid en t vele werk wat nog wacht. Maar ik ga door, ik ga voor de ervaring en t ontmoeten van de mensen, niet voor het in 1x kunnen schrijven van een perfecte game.


Als ik aankom bij het gebouw is het stil. Ik word door de bewaking binnen gelaten. De gangen zijn verlaten. Ons hok is donker: Kees ligt er nog te slapen. Dan maar naar het ontbijt. Dat staat nog niet klaar. Ik loop terug en maak Kees wakker.. We zetten wat ramen open om de slaaplucht eruit te krijgen, en ik ga weer aan t werk.

Peter bleek zich nu echt verslapen te hebben, hij kan pas na half 11 komen vanwege t OV. Jammer, want hij was gisteravond juist goed bezig aan een bepaalde feature, maar die was nog niet af toen hij weg ging.

Jan is steady. Hij komt stipt na het ontbijt om 10 uur, net zoals gisteren.

We zijn lekker bezig. Iedereen zit in z’n focus zone. Ik ben druk bezig de gameflow in orde te krijgen. Er zijn her-en-der bugs die niemand er echt uit krijgt, ik fix ze door nieuwe aanpakken te implementeren.

Peter heeft problemen dingen op de juiste plek in code te krijgen. Ik voorzie nut van DI, dus ik probeer, nu met een helder hoofd, opnieuw Zenject er in te hangen. Maar dan alleen de hoogstnodige dingen in t DI framework te hangen. Dat slaagt in korte tijd.

We hebben veel last van merge conflicten. Unity heeft scene bestanden waar vanzelf veel werk in gebeurd maar die heel lastig mergen. Tel daar een slechte pull-push hygiëne bij op en je hebt recept voor veel frustratie en verloren werk. Frustraties beginnen op te lopen.

de laatste loodjes… wegen het zwaarste

13:30 Eten

Snel weet wat van die belegde broodjes naar binnen werken. T valt mij op dat iedereen door blijft werken, even langs de gemeenschappelijke ruimte loopt om wat broodjes te halen, en daarna weer teruggaat.

14:00 Laatste loodjes

Nog 1 uur over tot aan de upload die van 15:00 tot 16:00 duurt.

We komen in een crisis terecht. Jan stelt terecht vast dat er nog behoorlijk wat schort aan de gameplay. Ik geef hem groot gelijk, maar geef ook toe dat hij degene is met t meeste gevoel ervoor en dat hij zelf met verbeteringen zal moeten komen omdat de anderen ze simpelweg niet zien. Ik mis Kees als backup, Kees was ergens anders in een hok gaan zitten om wat dingen te fixen vanwege concentratie issues. Ik probeer Jan op te beuren en geef aan dat we van heel ver komen en al veel bereikt hebben. Maar het mag niet baten, Jan geeft aan niet tevreden te zijn en niet zijn naam onder de game te willen hebben. Hij gooit de handdoek in de ring en zegt wel met wat dingen bezig te gaan die hij nog ziet liggen in t visuele design. Teveel stress.

Toch kwam deze bij mij hard aan. Ik hoopte iedereen aan boord te kunnen houden door gezamenlijke doelen te blijven formuleren, maar Jan had nu effectief aangegeven dat een gezamenlijk doel nog niet een goed doel betekent.

Ik zie ook de gameplay issues en de vele bugs. Ik was wat ongenuanceerd naar Jan toe dat ik geen gameplay gevoel heb, ik heb best een idee wat belangrijk is. Maar ik ga dat niet het team opleggen had ik mij bedacht… en bij dezen ben ik net zoals Jan niet daadkrachtig genoeg om het voortouw te nemen.

Ik verleg uiteindelijk toch maar de focus van mijn werk, van afronden van de features die we gezamenlijk afgesproken hadden tot nu dan maar ad-hock de feeling op orde krijgen. Maar niet in overleg met het team, dat durf ik niet aan met de spanning die er nu is.

15:30, chaos. Issues.

Intussen blijkt dat de dead-line wat vloeibaarder is dan van tevoren gesteld, gelukkig. 17:00 is de max wat betreft de upload. Jurering gebeurd lokaal, om 17:30. We kunnen ons dus tot die tijd bezighouden met verbeteringen.

17:30 Presentatie en bugs

Het is zo ver. We moeten de game presenteren. Er blijken een paar nasty bugs in geslopen te zijn in de laatste uren. Deel van de normale ending triggert niet, andere ending geeft aan dat je gewonnen hebt ipv verloren. Speciale ending werkt gelukkig wel. Gameplay wise hebben we een probleem: men kan zichzelf insluiten wat tot gevolg heeft dat we de game af moeten sluiten met Alt-F4… want we hebben nog geen menu/esc ingebouwd.

De game, zoals hij speelbaar was tijdens de jurering

Maar er is nog meer: weinig aankleden van de level, actions werken maar half, actions hebben geen nut, AI biedt geen noemenswaardige tegenstand, geen noemenswaardige geluidseffecten/muziek.

Onze game tijdens de laatste playtest / jurering

Ik ben blij dat men uiteindelijk ons nog credits heeft gegeven voor onze ‘betere’ alternative-ending die verstopt in de game zat. En voor de koe. We wisten al dat die features mensen blij zouden maken, en gelukkig waren ze opgemerkt.


Al met al ben ik heel tevreden met deze eerste gamejam. Veel nieuwe mensen ontmoet en connecties gemaakt. Werkwijzen van anderen kunnen zien en meemaken. Daar was het mij allemaal om te doen. Een werkende (soort van) game afgeleverd hebben was voor mij een bonus, en dat is ook behaald.

Ons team, dank voor de leuke tijd!

Maar ik was wel kapot. Van een normale werkweek direct door naar een gamejam, geen weekend, en toen weer een werkweek. Het was het waard.

Nog wat aanvullende gegevens, voor de geïnteresseerden:

Zilveren kogel

Een vraag die ik mij als software ontwikkelaar vaak stel is: ‘is er behoefte aan het stuk software waar ik nu aan bouw?’

Een oplossing

Misschien herken je dit: je wilt een proces verbeteren/versimpelen en je komt tot de conclusie dat dit kan met een stuk software. Dus je maakt een stuk software.
Iedereen blij, vooral omdat er überhaupt naar een wens geluisterd wordt, en men gaat vrolijk aan de slag met je stuk software.

Maar werkt het

Maar na een tijdje begin je jezelf af te vragen of je wel slim bent geweest. Want je krijgt feedback. Complexe processen worden zichtbaar. Waarvan je merkt dat deze de software een stuk complexer maken dan dat je eerst voor ogen had.
En als kers op de taart komen er mensen die je op bestaande stukken software wijzen die ook, min of meer, ‘het zelfde doen’.
Continue reading “Zilveren kogel”

Een app die niet werkt, wat nu?

Waarom je de software die je gebruikt wilt blijven ontwikkelen. (En niet wilt stoppen en het over een andere boeg gooien.)


Nadat wij goed en wel aan de slag waren met de liturgie generator bleek dat we een nieuw probleem hadden: Presentaties waarop willekeurig elementen (tot zelfs volledige slides) ontbraken, het generatie proces wat op willekeurige momenten stopte en zelfs het totaal niet opgestart krijgen op bepaalde computers.

Wat nu

In principe was de applicatie een prima softwareoplossing voor ons druk probleem: we hadden de presentatie samensteltijd tot 1/3 teruggebracht.

Maar het probleem van onbetrouwbare resultaten begon wel tot vragen te leiden en zelfs tot suggesties om een volledige andere softwareoplossing te gaan gebruiken.

Continue reading “Een app die niet werkt, wat nu?”