Does it reduce your decision workload?
In software engineering the question “Does it reduce my decision workload?" can be a great guide in almost all situations1.
Because if you view software engineering as decision making then your decision workload is your software engineering workload.
An example is in order
Take the decision:
Should we implement this service by plugging together off the shelf components or primarily build it ourselves?
Does plug-n-play reduce your decision workload?
On the one hand, plugging components together will reduce your decision workload: you won’t have to decide how to build those individual components. All the decisions encoded within them will go away. But you will have to decide how to use those components, how to integrate them, how to secure them and so on.
Context is costly
You might look at the documentation of some of those components and say ‘that’s fairly lacking’. That doesn’t mean you have to make more decisions, but it does mean the decisions you’ve to make will be harder. It’s harder to gather context from poor documentation and that increases your decision workload.
On the other hand, if you have great documentation from these projects and there’s good information out there how to put them together - in the way you need to put them together - then tickety-boo2 that’s reduced decision workload compared to the poorly documented version.
Does building it yourself reduce your decision workload?
On the other hand, you have implementing it yourself. You have to make all the decisions involved in putting it together and building this thing yourself.
But you know exactly how to do it, how you have done it - or something similar - before. You’ve documented well and can re-gather context quickly. You can use all the tools you’ve already used before. The tools you don’t have to make decisions on how to use because those decisions have already been made.
Choose your own adventure
Which path to take depends on you, your history and the task facing you. But if you look at the options in front of you and of each ask yourself does this reduce my decision workload? it can quickly surface which option is right for you.
Postscript
We’ve had three quick examples of reducing decision workload:
- Bringing in well documented external projects (and avoiding poorly documented ones) reduces context gathering.
- Reusing decisions from past projects skips decisions.
- Documenting your decisions well - for reuse later also reduces context gathering.
Looking at software engineering through the lens of decision making can surface many more. e.g.
- Strong prototyping practices can allow you asses more potential options quickly
- Keeping your code clean can aid context gathering
- Great observability helps with ‘quick-fire’ emergency decisions - make the context come to you.
- As does solid playbooks - pre-decide for speed.
The list goes on and I’ll explore more here, but I’m interested to know what you see when putting your software engineering practices under the lens of decision making. Let me know at
