)
About the author: With nine years of experience in software engineering, Akshay joined sennder in August of 2022 as a staff software engineer on the workflow and search platforms.
He brought a wealth of experience working in early stage startups. His work at sennder marks his first journey with a tech-enabled logistics organisation.
Why We Need a Framework for Choosing New Tools
A beloved tradition among developers is endlessly debating which technology to use for a new project (or for existing projects as well).
Sometimes we don’t like the current tool in use. Or maybe we’ve discovered a shiny new tool that we hope will magically solve all of the problems we’ve had.
Also, given enough time, developers want to replace existing tools with something different, just because. It is a wonder that we manage to get anything done at all.
Currently, I am evaluating technologies for use in two different teams.
I work with the search and workflow platform teams. These teams build internal platforms that help domains within sennder accomplish their business needs and processes.
Both these teams are rebuilding their core offerings. So naturally we’re talking a lot about technology choices at the moment.
In this role I have given a lot of thought to the process and criteria for choosing technologies. The answer I have come up with is that it depends on your needs and constraints at the time.
But this is not a very helpful answer. There has to be a north star, or guiding principle, that can help set some boundaries to narrow down the different choices.
Establishing the North Star for Technology Choices
I define that north star in terms of three aspects: value, resources, and quality.
Value is constrained by resource availability and quality requirements.
How we define each of these terms may differ, depending on the situation. But broadly speaking, I define them like this:
- Value solves a need, and is usually expressed as a feature or set of features
- Resources typically refers to time, money, or engineers
- Quality is both a measure of how well the software works and how well it is built
Software that does not provide value is not particularly useful.
So we need to define exactly what value we want to derive from the software. This value can come in a variety of forms, depending on the nature of the project. For example, for a personal project the value might be in learning something new or just the joy of the creative process. Regardless of what the value is, once the value needed from the software is defined and the constraints identified, then the rest of the decisions are easier to make.
Let’s say you have a complicated business process that is currently manual, labor intensive, and error prone.
You need to quickly automate this process. Because of the time constraint, the quality requirements are lower than usual–a 50 percent success rate, with harder to solve edge cases still being handled manually.
A 50 percent success rate may seem poor, but you are going from zero to 50 percent automation, and that’s a huge advantage to the business–a huge value.
Now that the value, resource constraints, and quality requirements are defined, making technical decisions is a lot easier.
Let’s take another example. Say you want to experiment with Rust instead of writing in Python.
However, we need to consider:
- It will take a lot longer to get started with Rust. The team needs to learn the language, how to productionise it, and to operate software written in Rust. Whereas with Python, all of this is already known.
- The primary benefits of Rust, like performance, are not a quality requirement.
Given this context, it makes sense to stick with Python, at least for now.
What We’re Up to at sennder
Both the search and workflow platform teams at sennder have made similar decisions–trading off some quality attributes in favour of providing value more quickly.
Some examples of quality attributes are:
- Performance at scale
- Performance under certain edge conditions
- Developer productivity and ergonomics
- Delivery velocity
- Software flexibility
Since these quality attributes are missing, both teams are looking at a fresh rewrite. I don’t think this is a bad situation to be in. The teams delivered working software that solved business needs, I.E. provided value in a timely manner.
Now that both the platforms have been in use for a while, the trade-offs made are starting to show. This indicates that more investment in these platforms is required.
This brings us to another great quality of this framework–it doesn’t just help guide technical decisions at the beginning of a project.
It also can be used as an indicator to decide when major changes need to be made.
In this case the trade-offs made in certain quality attributes meant that more resources (developer time and infrastructure costs) were needed to provide the same value.
Now, it’s clear we are ready to invest more resources to improve both these platforms.
Now the value and quality requirements are much higher, but so are the amount of resources available. This means the teams will make a different set of technical decisions and trade-offs to solve the same problem.
Then the cycle repeats.
Hopefully this time, in a few years rather than in a few months. Which is a good thing and expected, as that means the software provided value and its usage scaled.
)
)
)