Software engineering can be modelled as decision making. And looking at it in that light can give us clarity can help us develop faster, build better workflows and make confident progress.
Let me give you a taste of this idea by looking at software engineering through this lens from the broad scope to the narrow.
At the broadest scope, decision making in software engineering tends to be software architecture1. The really big stuff in a large company. Hundreds, maybe thousands of engineers could be affected on that scale.
On that scale architecture is often choosing sets of technologies that you’re going to invest in. And making it easy for your engineers to take the happy path that you want them to go along.
It’s a difficult job, and it’s a job where you have to align various business and technical needs and find where that intersection on the Venn diagram is. Then - within that within the little overlap - decide which technologies are the best for you, your company and for the product2.
Looking at that through the lens of decision making, it’s two things: decision elimination and context reduction.
First, you’re pre-deciding; you’re eliminating options that could be facing the software engineers working with you3. Choosing the technologies you are going to invest in, eliminates the ones you’re not. That reduces the set of decisions that the engineers you’re responsible for have to face.
For example, if you say ’OK, Postgres is our relational database. period’. 99% of the time that’ll work for your engineers. You can make that the happy path and they won’t have to make the decision “which relational database should we use?”4. Sure, the other 1% of the time they might need another relational database. That’s fine. You can deal with that. But you’ve made the 99% of ‘which relational database should we use?’ decisions disappear.
Second; you’ve also reduced the amount of context your engineers will have to search through. With fewer different technologies in play the richness of successful examples and solutions using those technologies will naturally increase. I.e. they won’t have to search far and wide for a solution to their problems. They can ask their co-workers, or look up internal documentation. This accelerates every database related decision going forward.
So that’s the high level, software architecture piece, viewed through the lens of decision making. Pre-decide, reduce context.
Now, if you want to zoom in all the way to the other end, you’ve one engineer working on a task that doesn’t directly involve anyone else.
They’re writing some code in some codebase, and they need to make some decisions about it. There’s millions of decisions that they could face, but one thing I see, particularly junior engineers, pause on is when to remove code.
Let’s say that there’s some interface. It’s being satisfied by some implementation. We need a different one. They build the new one and then ask themselves:
Should I delete the existing one? Or will I leave it there, for later?
Look at these options through the lens of decision making. If they leave it there, then any engineer looking for something to satisfy that interface will now have an extra option. Another option to assess.
By removing that option, it’s no longer something the next engineer has to face. They don’t have to face the question: “Should I use this? Or should I use that?”. And they don’t have to dig through the context of ‘which one was built when?’, ‘Which is better or worse?’ And they don’t have to find that actually, we’ve tried to replace this one with something newer5.
So in that case, the engineer implementing that change, they can look at it through the lens of decision making and say: ‘okay, yeah, I’ll help decisions in the future by removing this option’. Eliminate unnecessary decisions, reduce context.
So that’s decision making a broad level and narrow level, and I do believe it permeates pretty much everything we do as software engineers.
Good documentation greases decision making. Poor documentation just takes ages to read. Context reduction.
If you want to decide between strictly vs loosely typed languages you’re trading the decisions:
how should I model this data?
Is it bug lite6 and how can I be sure?
Pick the decisions you’ll be happy to face; to spend time on.
What tracing/logging/alerting tools do we need?
How much context gathering can you stomach during an emergency?
Decision making is a useful lens through which to view software engineering. It can clarify a lot of ‘what we do and why’ and that clarity can help us develop faster, build better workflows and make confident progress.
You could pick nits between software/enterprise/* architecture
And then, of course, you have to assess them properly, to advocate for them and all of that. Details, details. ↩︎
In reality seniority is on the bottom, not the top. ↩︎
Hopefully better ↩︎
Bug free is a white whale ↩︎