Well Played

I built a theme park in OpenRCT2 based on things that are wrong in tech

RollerCoaster Tycoon and its spiritual successors are timeless classics that never get old, unlike messages from tech recruiters.

RollerCoaster Tycoon spiral slide
Guest 8472 doesn’t like being picked up against his will, but he’s willing to let it slide this time.

RollerCoaster Tycoon was one of the first Windows games that I played on my Compaq Presario. 22 years later, this legendary theme park simulation game still holds a special place in my heart.

I can’t say I feel the same amount of love for its successor RollerCoaster Tycoon 2, but given how enthusiastic YouTuber Marcel Vos is about the game I decided to give OpenRCT2, the open-source reimplementation of RollerCoaster Tycoon 2, a try.

I didn’t really know how to write an entertaining article about a video game, so instead about a young developer who joins a dysfunctional software development team, that just happens to include screenshots from OpenRCT2.

A new opportunity awaits


Like most software developers, you often receive unsolicited phone calls and messages from tech recruiters and headhunters. You usually ignore them, because you have better things to do than listen to the same made-up stories about “wonderful new opportunities” and “competitive salaries”.

But at the same time you also desperately and are perpetually bored at work, so you do respond to them from time to time, as long as they’re not overly spammy.

Most of the time the positions being offered aren’t particularly enticing. But every once in a while an opportunity comes along that genuinely looks promising and you’ll agree to have a little coffee chat with the hiring manager.

In this case, the company is a digital agency of some sorts, which means you’ll get the opportunity to work on lots and lots of greenfield projects with whatever exciting new technologies you like. I mean, just look at all these green pastures. Who wouldn't want to work here?

An empty park with a lot of grass

I know the grass always looks greener on the other side, but you have to admit: this looks pretty nice!

The company – let’s call it Greenfield Software – is housed in a small building that wouldn’t look out of place in an American suburb. None of that corporate nonsense here. This is definitely a good sign. So is the sign in front of the building by the way; it was personally hand-crafted by the founder and CEO of the company, Dave.

A small house. A sign in front of the house says “Greenfield
Software”. The door is wide open.

At Greenfield Software, the door is always open. Like, literally always. It’s stuck in an open position.

Dave isn’t in today. However, the company’s lead developer, who also happens to be called Dave, is more than happy to tell you how great it is to work at Greenfield. Not only because the company provides unlimited free snacks and drinks in its kitchen, but also because of its company culture. “At Greenfield we don’t just work hard, we also play hard”, he says while pointing at a table tennis table in the middle of the office.

The interior of the house. A large animatronic rock star plays
music in the kitchen while guests walk by.

Dave is what many would call a larger-than-life character.

Dave is what most people would call a rock star developer. He’s been part of the company since it was founded five years ago. In those five years, he has single-handedly architected an entire e-commerce platform, which now comprises more than 80 domain-driven microservices that run across three inter-linked Kubernetes cluster singularities. You have no idea what that means, but it sounds like a pretty impressive feat.

This might just become your new forever home! You accept the job offer and excitedly look forward to your first day.

Unfortunately, the excitement doesn’t last very long.

Guests walk down a green hill.

Things would soon go downhill.

Lies, damn lies, and Greenfield


For starters, onboarding was pretty rough. The new MacBook that you were supposed to get hadn’t even been ordered yet, so instead, you’re working on a seven-year old Mac Mini until the MacBook arrives (hopefully soon).

It quickly becomes apparent that the Mac Mini wasn’t the only thing that was old. As it turned out, Greenfield doesn’t actually make its money from greenfield projects – at least most of the time. The few greenfield projects it does take on are mostly handled by Dave, as he is the only person in the company who has enough experience with greenfield projects to be qualified to work on them.

The rest of the company is responsible for maintaining the company’s many brownfield projects for external customers, although it’s not entirely clear what “maintaining” means at Greenfield. All projects still use PHP 5.5 (which has been declared end-of-life since 2016) and none of the projects’ dependencies have ever been upgraded.

Sadly, there’s nothing that can be done about it. All software runs on a shared web hosting account that’s provided by CEO Dave’s cousin. It only supports PHP 5.2 and 5.5, for stability reasons.

The path leads to a brown, muddy field with gold rush era equipment.

Legacy tooling. Legacy tooling everywhere.

Greenfield’s implementation of scrum also leaves a lot to be desired. The company’s 28 developers are all part of the same Scrum team to promote collaboration among team members.

The team gathers every day at five o’clock in the kitchen for a daily stand-up meeting, which takes place around the table tennis table. First, Dave tells people what he did today (“solved very hard problems using recursive algorithms”, “aligned with external stakeholders”, etc.), then he picks a random person who gets to do the same (usually some variant of “I worked on the ticket that was assigned to me”). This process repeats until the group is convinced that everyone has had the opportunity to provide a status update.

A boring coaster that’s basically just a multi-storey merry-go-round.

I have the feeling we’re just going round in circles.

Despite all the effort the team puts into carrying out the various Scrum rituals, it rarely manages to complete all work that’s planned within a sprint. But this is not really seen as a problem.

Sprints are simply two-weeks periods during which tickets may or may not be completed. The JIRA sprint backlog is just a wish list. Some tickets are small and can be easily completed within a day, while others may take weeks of work (because “tech is hard like that sometimes”). It’s probably more accurate to say that the team is using some constipated form of kanban. That’s fine though, as customers are billed by the hour anyway.

Nevertheless, the team has taken measures to increase their productivity. For instance, each developer is responsible for one specific project. This way, less time is wasted on overhead like code comprehension and . Dave argues that this frees up more time for things that are actually important, like programming. That doesn’t sound right, but you don’t know enough about technical leadership to dispute it.

A boat hire where people can’t find their way back to the station.

A common sprint goal? No, it’s every man for himself.

The burnup, burndown, and velocity charts all look like flat lines with a few small bumps here and there. No one in the team seems to think that there’s anything wrong. And why would they? Everyone is working hard and playing hard, and Greenfield’s customers don’t seem to mind the glacial pace at which work is completed. After all, they’re still lining up.

The velocity might be a bit too low, but as long as you get there eventually it doesn’t really matter.

To be fair to those customers, from their perspective Greenfield does a pretty great job. Virtually all software that Greenfield maintains runs flawlessly, with little signs of that so-called “software rot” that competitors often like to moan about.

The secret, you know, is to simply never update anything. If you never make changes to your software or the platform it runs on, it will never fail in unexpected ways. As the saying goes, “if it ain’t broke, don’t fix it.”

That’s not to say that serious incidents don’t ever happen. Some customers want changes to be made to their software, which means that those changes need to be deployed at some point. That’s generally where things go wrong, because Greenfield’s deployments have the tendency to break things.

Fortunately, the team has found a brilliant loophole. You see, the trick is to never announce when you will attempt to deploy new changes to production. If the deployment succeeds and the system keeps working as expected, you can inform the customer that you did a good job. On the other hand, if the deployment fails or causes system outages, you can quickly swoop in and save the day. In both cases the customer is grateful for your hard work.

Many deployments are rolled back before they even finish.

All of this really frustrates you as a software developer, but quitting is not an option – especially in the current economy. You have a family to take care of, a hefty mortgage and a massive study loan that needs to be paid off. Nonetheless, you try to look for a way out, if there is one.

A maze, built using paths and fences.

There must be some kind of way outta here…

Wear a different hat


Fortunately, Dave (the CEO) believes he may have something that could suit you a bit better. He sends you to an agile conference where you attend inspiring talks about scrum and agility. With renewed vigour, you return to the office the next day with a bag full of agile goodies and a brightly-coloured “Scrum master” hat.

Dave smiles. “I can see that you’re a product owner now”, he says.

A guest has just bought a hat from a stall.

Things are finally looking up again.