Ever consider how you take decisions? Like, not just if you do or not, but how you actually reach an answer you can get behind?
Listing pro’s and con’s and trying to weight these is go-to standard. Or maybe simpler yet, list the requirements and pick whatever option ticks most of the boxes?
Taking decisions
In my current project, we are doing a big rewrite. This decision itself warrants a post of its own so I won’t cover it in detail here. However, as you can imagine, this requires taking many, many decisions.
We are approaching this as a team, looking at our goals and then ideating options. We have evaluated these options and now we will test them. We still consider it a PoC so we will build what we need to but as a test. If it does work, we polish and scale, if they don’t, we try something else.
As I said we are evaluating our options, this is what I would like to cover in this post.
What is your priority?
There are a million ways we could build our project. So before we even start looking at solutions, we set down our priorities, what should drive our decisions?
Some priorities come from lessons learned in our current system and others are informed by business targets.
- Moving fast: Being a start-up, moving fast is more important than working perfectly.
- Avoid tech debt: Moving fast is impossible with loads of tech debt. Our new system must apply good practices such as decoupling
- Don’t reinvent the wheel: Avoid building things that exist already and isn’t our core business
Agreeing on values
These priorities are a good start to filter out options. But we don’t always agree once the options are clear, we need to go even further. This brought to mind an episode of the brilliant podcast Developer Tea I heard to the other week, Disagreeing better, on purpose.
Mr Cutrell makes the point that often in disagreements, it’s not that either party are wrong. We simply value different things. So when we disagree, begin by clarifying what we value our solution by.
Do we propose X because of performance, speed of delivery or the difficulty of maintenance maybe?
If we can agree on the values we need, which in turn are really just fine-grained priorities, we are more likely to agree on the right course of action as well.
An example of deciding
We should allocate time to decouple parts of the app code to avoid references between layers in the clean architecture. We can avoid incorrect references between modules by separating them into pods. This will also allow us to reuse these pods later.
discussing how to approach rewriting the iOS app
First up, we went into the assumptions of what we want to do. We want to decouple the code, yes that definitely fits with our priorities.
Why do we need to allocate extra time?
It will take time to break the references and create new repositories.
Maintaining separate repositories costs extra time though. Are there other ways to achieve the same thing?
Since we have a thorough PR culture and we could avoid module dependencies manually, also using frameworks or projects to achieve levels of the same thing and this would be faster. Allowing us to do it in steps as well.
This would not allow us to reuse the pods?
That is true, but do we need to? There is actually no plans to do this within the year. In case we do want to, having avoided references between modules even if they are in the same project, it will be easy to separate it when needed.
Looks like a process for deciding
We clarified our assumptions, their impact, effort and risk, on the short and long term and then looked at options.
Of course, there are harder decisions as well. Like the next one we are facing, should we use something like Cloud Spanner over Cloud SQL?
This encompasses major architecture impact which if not done right to start with could cost both time and money in the long run.
If we set our values and assumptions to begin with though, we are better equipped to agree.
And agreeing is key because only if we do can we move fast in the same direction.
Closing words
I’ve been using something called ICE (Impact, Cost, Effort) in the past to compare and prioritise options. Bundling this with Risk makes it even better. However, we are humans and there are fuzzy values I think is important to not forget.
With inspiration and motivation, we can achieve more, even if our choice isn’t logically the best option. So if you have a big refactor or a new tool you really want to use, maybe this non-measurable should factor into the decision as well?
Finally, I stumbled across a new child of the Stack~ family the other day, a tool for openly discussing tech decisions just as described here. So before your next big decision, check out https://stackshare.io/ and maybe you can find inspiration there.
That’s it for this time, thank you for this time! If you have your own battle stories or tips&tricks, please share and inspire!