Strong Opinions, Loosely Held is what’s wrong with tech today
Our first blog post comes from our CTO, Fergus Doyle, hope you enjoy!
These days, there’s a revolutionary new technology/library/framework/approach announced every week. Each comes with it’s own crowd of impassioned supporters claiming it’s the future of the industry… usually with very little evidence to back up their claims.
In the first Kalo Engineering post I’ll give you a high-level overview of how we think about testing and adopting new technologies within the team and the product here at Kalo.
It’s safe to say the engineering culture at Kalo discourages premature optimisation. Instead, we try to foster an environment where different tooling and patterns can be explored and evaluated.
Over the last 18 months we’ve experimented with a veritable feast of select UI elements, datepickers, API utilities and notification frameworks.
Has that led to us having to deal with inconsistency in places? Sure.
Have we said to ourselves “I’m sure we fixed this behaviour the other week”? You betcha.
But has this approach also allowed us to gain a lot more insight into what works, what doesn’t and how we can apply that to a larger set of instances than our initial use case(s)? 100%.
Deciding not to make a decision can be a powerful tool when used carefully.
From our experience: When questioning whether to test something new, the best bet is to use your common sense. Don’t go out of your way to try something else just because a final decision hasn’t been made yet. Equally, don’t block work when you know a decision is going to take you some time to make.
And when the time comes to make a decision don’t defer, hoping that some external factor will narrow down the options for you. This rarely leads to the best outcome.
At Kalo, the following practices help support us in our approach:
- Striving for simplicity — Across infrastructure, technical architecture and implementation design, patterns are easier to identify if you manage to avoid mixing up a number of concerns in large code blocks.
- Discussing new ideas — We make sure that alternative approaches are shared with the rest of the team and that the reasoning behind it is documented for future discussion.
- Supporting decisions once they’ve been made — This is why we explore the problem area before committing to a single approach — it ensures everyone on the team has enough confidence to support that decision moving forward.
One of the most recent examples of us putting these concepts into practice is the fact that we’ve only just started to migrate business logic into domains that we expect to be able to support going forward. Without experience of our users’ expectations of the product and the corresponding evolution of the platform, rushing into decisions can quite often backfire. We’re currently in the process of mapping out the core domains within the platform and translating that within our microservice cluster to reduce complexity across the rest of our stack.
Despite the slightly clickbait-y headline, I do think it’s important to put weight behind your opinions. Having evidence (and specifically, first hand evidence) to support your opinions of what works and what doesn’t is a great place to start. Ignoring the scientific method is not a path towards building stable, scalable software.
The continued evolution of our internal infrastructure is only one of a host of technical challenges that we’re excited to tackle in 2017. We’re always looking for great people to join the Kalo team so be sure to check out our open positions as well as our github (lots of open source goodies coming over the next few months).
If you’ve enjoyed reading, hit the recommend button below!
