BoosterConf 2023
Last year was the first time for me attending BoosterConf and I was happy to re-visit it again this year.
Around 400 participants gather in one of Norway's most beautiful cities: Bergen. During three conference days, the BoosterConf program offers keynotes, lightning talks, experience reports, workshops and even an OpenSpace during one afternoon. The program is very varied, and offers content and inspiration for the entire team. That is also the reason why the audience was a good mixture of all roles involved in digital projects.
The agenda offers a nice pacing and long enough breaks so there is time to connect with other attendees and reflect on what was just heard.
I really liked the opportunity to discuss relevant topics with participants during the open space, which this year was 3 hours long without any program at the side, so there was no distraction. I wished the OpenSpace was however split in multiple rooms and not run as multiple chair circle in the big hall.
The conference has already published the video recordings on Vimeo, so you can get yourself an impression of the talks. However, the workshops and the OpenSpace was not recorded.
Lisi has also written about her impressions on her blog: Lisi Hocke: Booster Conference 2023 - Changing Perspectives.
Here are the sessions that I attended; I shared them live on Mastodon using the hashtag #BoosterConf.
Day 1
Opening keynote
The #BoosterConf opening keynote is by Anne Landro, a Norwegian service designer, and she talks about how to build innovative solutions that people really want (however they won't honestly tell you).
She gave us a quick assignment: talk to each other 2 minutes about a specific time when you were showering.
Very interesting to see how few managed very essential things like: were you wet when you left the shower, were you dry when you entered?
That shows that users, when interviewing them, can't share many important facts.
Users are too used to the (suboptimal) processes that they are using, they can't see the problems with it.
In order to find good solutions we need to dig deep into the problem and resist the urge to jump to the immediate, obvious solution.
But just talking is not enough, and getting to the true needs of a user is challenging, because users are often not honest about their true needs.
[ I love the 5 Why's for that: https://en.m.wikipedia.org/wiki/Five_whys ... and she just mentioned it. ]
There is a less offensive way to dig into the root cause (5 Why's can feel offensive), you can ask users about the benefits they solution they have in mind will yield for them. This can lead onto the path of finding out why they have a specific solution in mind.
Nevertheless, the best way to find out what your users need is to observe them find the user's pain points.
But make sure that does not influence them too much. Because users that are aware that they are watched, often behave differently.
Lightning talks
First set of lightning talks at #BoosterConf starts with Einar W. Høst who reminds us that developers should be emancipated enough to understand their role with the same confidence as the so called business people do. They are, in the end, the ones who need to take ownership over the decisions they make and how they influence the business.
The second talk is by Daria Kostiuk who speaks about the dangers of scope creep.
Don't forget that any new feature you accept has a tendency to cause unintended side-effects and cause other things to take longer than expected.
The third talk is by Kjersti Berg, who talks about reviving a code base from a state where it was practically unmaintainable.
She used an ensemble approach to get out of this mess. They used one hour every day to get everyone together. Ensembling helps here because it improves knowledge sharing and decision making; both are key to make confident decision.
After a year this improved code quality, ability to fix bugs and overall team happiness!
Finally in this slot of Lightning Talks at #BoosterConf Dalibor Jovic has also a talk about technical debt and he proposes a few things you can do about it (because sometimes it is not avoidable).
Now in the second slot of Lightning Talks at #BoosterConf Nora Gjøen-Gjøsæter gives us a very important reminder how biased AI models are.
They all are, but some are more than others and effort is needed to not reinforce and proliferate the biases the models get from their source data.
Karianne Berg shares her best practices for making awesome database indexes. Some strong language included 🤣.
Make sure to understand your database schemas when building your applications, otherwise your performance will suck!
Monitor in production to spot queries that need to be optimized (often the problem only becomes apparent with production data).
Very cool lightning talk by Embla Flatlandsmo explaining how keyboards just™️ work when you plug them into your computer. Love the hand-drawn slides!
Architecture Workshop with Oliver Zeigermann
we are working on a car insurance architecture Kata. First we are looking at a very simplistic implementation.
Then we are reviewing potential solutions by trying a few simple examples on https://ml-playground.com/ which is a really great idea to explain architectural tradeoffs.
Finally, we got 30 minutes to discuss potential solutions in teams. That was fun!
Fishbowl
Now it's time for the fishbowl at #BoosterConf with controversial questions from the audience:
- Is HTML a programming language? Doesn't matter.
- Uncertainty is mandatory: yes
- Should we fear AI? No, potential is real.
- There is no such thing as a full-stack developer: right, there is not.
- There is nothing every developer must know: probably Git today is a common denominator. But for every given profession there is a set of tools you need to know.
- Technology should not be seen as magic.
- Psychological safety is just a lazy excuse for doing nothing: absolutely not. There is research that shows that high performance and psychological safety correlates.
- Cloud vendor independence is not needed and wasteful: maybe, but some standardization is useful.
Day 2
Second day of #BoosterConf starts with a #refactoring workshop run by Karoline Skylstad and Siv Midtun Rollup, we are going to dive into a #Java codebase while applying some constraints.
The project source we work with is https://github.com/kantega/refaktorama.
OpenSpace
Really cool to have two slots for #OpenSpace sessions at #BoosterConf.
The topics.
First round: talking about quality.
Second round at the #BoosterConf #OpenSpace: why do do many companies require CS degrees?
This is where I learned about https://www.vilbli.no/nb/nb/no/informasjonsteknologi-og-medieproduksjon/program/v.im which teaches media and programming skills which allows workers to enter the workforce much earlier with relevant skills. It's still a certified training, so companies get a reliable level of education.
Talk by Elisabeth Whiteley about side-projects
Elisabeth Whiteley shares great insights on how she deals with finding a way for side projects so it doesn't feel like work.
Make it fun, and don't replicate the same constraints that you have for work!
Day 3
Talk by Hege Dreiem about API Design
Final day of #BoosterConf and I am starting with a session on API Design from Hege Dreiem.
She talks about the challenges of designing a ticket booking API for the Norwegian railway.
It's important to design an API that gets used by many clients that you don't control to be open for extensions from the start.
Developing a ubiquitous language is important in the beginning to develop an understanding of what the API needs to express.
Talk by Aleksander Olavsrud about Machine Learning
Marius Aleksander Olavsrud explains how he and his team used Machine Learning to reduce the number of wasted breads at a Norwegian supermarket chain.
Building a ML solution that works requires the right data. However that often is not there. Make sure to get the input data right. The implementation is only half of the project. Don't underestimate the effort needed to change their processes according to the findings.
They used Facebook Prophet because it can account very good for seasonal and holiday events (and it's open source).
Unfortunately he did not share how successful this project was in the end.
Talk about GraphQL by Pål Thomassen
Pål Thomassen now shares his bad experience with GraphQL for building an API for traffic data at Statens Vegvesen.
He starts with a basic introduction to #GraphQL. The bug advantage he mentions is that it is great to document the contract between server and clients, and there are many tools that can generate consumer code.
The goal was to provide public access to the data they collect, and in 2018 when they need to pick a new technology it looked like a good choice, addressing the shortcomings of REST. The initial evaluation and internal tests went quite well, and even though there was some hesitation because it was uncertain if it was the right choice over REST, it was decided to continue with the approach. It was easy to model the API according to the business domain. And they went on to launch it.
Now for the downsides:
- it introduces a bunch of new and complex concepts for implementing it properly
- from a client point of view it can be challenging to build clients that need to retrieve a lot of deep, nested data
- Many users often want spreadsheet exports, that's hard to match from a nested structure
- Because of the complexity the internal adoption of the new API was not a full success, which is a good indication that it's not an optimal solution
- a lot of consumers wanted access to Gigabytes of data, and transferring this via #GraphQL creates a huge overhead.
So it turned out that it a traditional REST API would have been a better choice, both it would be easier to maintain with a smaller team, and it's a more established technology that would scale better for this specific project.
Talk by Andrew Harmel-Law about Architecture
In his session at #BoosterConf Andrew Harmel-Law talks about how architects can change their behaviour to not keep teams back, but to enable them making their own architecture decisions. #AnybodyArchitecture
He proposes The Advice Process:
"Anyone can make any decision But before doing so they must: seek advice from all affected parties & people with expertise in the matter."
But how to keep people from making bad decisions? Use ADRs to document the decision to be made and iterate on it.
In the draft phase the team pulls in advice from all affected parties and document this advice.
All of this effort gets synchronized in weekly meetings of the Architectural Advice Forum.
It's important to track progress of ADRs to have an eye on those ADRs that get stuck.
Finally he points out to watch out for potential causes this approach can fail:
- "Bad" decisions (there are none really)
- Old guard == New guard (not giving room for others to make decisions)
- Off-the-grid decisions (teams not using the process)
- No trust
This is the detailed blog post for this talk: https://martinfowler.com/articles/scaling-architecture-conversationally.html
Closing
Daan van Berkel closes #BoosterConf for this year.
Thanks to the #BoosterConf organizers and team, that was a blast!