The Value Of Experimentation In Software Development
Going beyond POCs, spikes, and hackathons…
For the most part, I think that software engineers, developers, programmers, coders — call ’em whatever you like — all tend to share an important trait — curiosity. Yes, even the jaded cynics with a decades-long career behind them. Curiosity may have killed the cat, but when it comes to those of us who write code for a living, it can actually breathe life back into one’s day-to-day, be that at the office, at home or stranded in an airport while traveling around the globe writing software.
Yet, as much as we all love solving problems and writing code, let’s admit that more often than not we feel like we’ve done it all before, the only variable is the context. Heck, many companies hire us exactly because we’ve done something before, we’ve done it well, and now they want us to do it for them. It’s called having experience and expertise and being appreciated for it. It’s no wonder then that the older a software engineer gets, the more you hear across the industry they’ve “been there, done that”, “it’s just another job”, “there’s nothing new under the Sun” alongside the sigh of having to “go back to the salt mines” after a well-deserved holiday or vacation.
What exactly happened?
Well, one could say, life happened. The day-to-day happened. Naturally, features need to be developed, and those features follow an endless list of other features. Frontend engineers are writing their 789th API call to some internal or 3rd-party service, the backend engineers are writing yet another… you guessed it… microservice, and so on. A sense of monotony can easily set in and even when you truly enjoy coding, sometimes you just can’t shake off the urge to experiment, to try something out that’s not on the Jira board.
Of course, one could argue there is always a good spike or POC to sink one’s teeth into, and should there be none, by now most software companies hold regular hackathons. I remember joining Prezi in January 2022, literally starting with a week-long hackathon. It was fun, I even participated, and I got to know half the company in a single fast-paced, inspiring week. But hackathons don’t happen every day and the rush of it can wear off quickly, hence the need for something else.
A simple, yet effective solution
Because you see, life doesn’t just happen in a vacuum, we do have some control over it. One effective solution is perhaps to move from a full-stack developer role to an SRE position, or from frontend to backend, and while those are both very effective for getting back the excitement and a sense of newness in one’s day-to-day, it’s not the simplest of solutions organisationally speaking.
So what is?
When we developed Prezi Video for Zoom, we quickly realised as a cross-functional team that beyond just our respective areas of expertise, we had a lot more to give. We found that many of our planning sessions or design syncs resulted in not just making decisions about what needs to get done next, but tangential ideas were coming from every direction, and some intriguing enough that while we couldn’t justify jumping on them as a team, we also couldn’t deny its potential value, and some of us felt really eager to at least create a demoable version of it. So how do you do that without it being on the product roadmap?
When you really believe in something, and you want to do it, you create time for it.
And we called this time “Gold Days”, a refreshed concept in Prezi, where a team sets aside some time — in our case two days — every two months to allow team members to experiment around the product. And when I say experiment, I mean anything goes:
- Develop and demo an entirely new feature that you really believe in.
- Modify or improve an existing feature the way you imagine it should work.
- Try out previously unexplored 3rd-party services and see what integrations might work well in the future.
- Tackle a technical challenge that was never truly solved before in the product.
For transparency, we tracked these experiments in a Confluence document that anyone could add ideas to. Not just our team. Everyone from the company. On the first day of Gold Days, anyone who wanted to participate from the team (it wasn't compulsory), would pick one of the ideas they felt strongly about, and would commence experimenting. The expectation was that by the end of the second day there would be an output in the form of a demo, a findings document or both.
Another important aspect of this setup was the understanding that no output was guaranteed to become part of the product. It was still product’s decision what’s worth spending more time on and what isn’t. But that was part of why Gold Days worked well for us. There was zero pressure to build something for production, but all the freedom to experiment within the product.
The benefits of experimentation
Before I proposed reviving this concept within the team, I realised that beyond the obvious answer of “because it’s fun” to the equally obvious question of “why?”, there had to be other reasons to give the team the bandwidth for experimentation. Here’s just some of them:
- People care about their ideas, and the more we allow them to explore, the more we fulfil a natural need. Satisfying that need leads to people who feel more accomplished, even if the result doesn’t end up in the product. That idea is no more in the back of their minds, and there are no more frustrations about never having had the time to try it.
- It teaches lessons. Ideas on the surface can be great, but just as well prove to be unfeasible when trying to implement them. In the case of a success, one gets to learn how to get quickly from an idea to something they can demo to the team. In the case of a failure, the entire team learns about UX or technical challenges that were never considered before.
- It sharpens presentation and documentation writing skills, both essential for a software engineer. It’s one thing to build it, and it’s another to sell it and document it in a way that anyone can understand the benefits of the demo.
- It fosters new ideas. Regardless of a demo being successful or not, seeing it rather than just having a few lines of text in a Confluence document or a fleeting comment on Slack, can start tangential conversations that can ultimately become new avenues for the product. Inspiration can come from anywhere, even a failed demo.
- In the case of a successful demo, it might just become the feature that users love the most.
For my team, Gold Days was a great space to express ourselves as software engineers and create different conversations. It was a great opportunity to learn new tricks, try positively crazy stuff and break the mundane while inspiring ourselves and others.
Not necessity, but curiosity is the mother of invention. Experiment.
Attila Vago — Software Engineer improving the world one line of code at a time. Cool nerd since forever, writer of codes and blogs. Web accessibility advocate, LEGO fan, vinyl record collector. Loves craft beer! Read my Hello story here! Subscribe for more stories about LEGO, tech, coding and accessibility! For my less regular readers, I also write about random bits and writing.
