Tools for Decision Making
Effective decision making strategies for software development.
The project you’re working on might well be in one of two phases: either you’re embarking on a new build and staring at a blank piece of paper; or you need to restructure or extend an existing application.
Either way, there are architectural decisions to be made. In this article I will look at four tools to help navigate the shifting sands of product development and how setting guiding principles and measurements of success early on can make future decisions easier and more likely to lead to success.
Use a Mission Statement
As a cynical Brit, many mission statements sound somewhat trite to my ears. However, the aim here is to write a single sentence or short paragraph for your project or requirement that doesn’t sound trite but instead conveys meaning and distils the goal of the project into a guiding principle. Focusing on project aspirations, not long term business goals, will make it meaningful and a tool for decision making.
“Be the best event in the world.” — This is a terrible mission statement. Not only is it woolly management & marketing speak, but it doesn’t really provide any detailed guidance about the user experience or business needs.
“Provide delegates with clear information about our event, enable them to easily purchase tickets, and ensure they have enough information to attend the event.” — This gives you something to work with. It focuses on the user and covers a significant customer journey (the “happy path” that most should take). It provides a good overview of your goal that the entire team can use to align their individual activities.
Or a Definition of Success
For those who are more goal orientated, a definition of success will set meaningful targets for the team to work towards.
To set your definition of success, look at what the user, business and development team needs are and create one or more definitions. For example:
- Customers should be more confident in making a purchase on our site, as measured by UX surveys. (User)
- Increase conversion by 15%. (Business)
- Reduce time spent on resolving issues in production. (Dev Team)
Ideally a definition of success will have a clear & discreet target which can be measured and tracked. Vague goals make it harder to know if you’ve succeeded and harder to justify follow-up work.
Note that the definition of success does not state any particular implementation remit. This gives your team flexibility to work towards that goal however they see best.
Your architectural principles are as important, if not more so, than the architectural decisions made.
That sounds hyperbolic but when you’re making decisions it helps to have a set of guidelines to steer you. Principles help you focus on what’s important and perhaps the most important tool to use.
To give you an idea of what they look like, here are some principles I’ve used in the past:
- Plan for the organisation’s abilities.
- Plan for failure by building in fault tolerance.
- Allow for independent development & deployment of domains.
Principles are not requirements or product choices. For example, “We will use Redis for caching” is not a principle, it is a product choice. Product & technology choices are, or should be, subject to change. (Unfortunately there are times where somebody has made an expensive purchase and seeks to bind that to the architectural decisions, but that is something you have to manage.)
Principles can be unique to a project, a team, or a company.
Often companies have mission statements or values that translate well into guiding principles but it’s more likely you’ll derive them within your team & projects.
Principles can be shared across teams.
It helps to work with teams that share some common principles but don’t force it if it doesn’t happen naturally.
You probably already have a personal list of principles.
Experienced developers & architects have histories which have influenced their thinking over the years. These are your personal principles that guide your decisions. However they may not fully match the principles that you agree on with your design team, so be open to discussion about them.
Principles should be collaborative.
Often there is design team, who will collectively discuss decisions. The design principles should be shared by all team members and to do that they should be the result of that team collaborating to produce them. If a single person is driving the creation and application of the design, it helps if the principles have been discussed with a larger audience so that you’re not faced with opposition during implementation.
Principles should be public.
Publicly stating the principles which have affected your decisions for a solution help others align with those choices. Documenting them, even at a high level, means that people can be aligned now and in the future, when decisions need to be reviewed due to new requirements.
Don’t have too many principles.
It’s a balancing act. It’s good to have guidelines but the more you set, the tighter you’re binding yourself into early decisions.
Strong but flexible.
Principles should be flexible, realistic and lead to your definition of success. Whilst a principle should not be abandoned lightly, occasionally exceptions have to be made to your principles and others will have to make mitigations to work around yours. Software development is an iterative process and your principles need to be able to undergo the same release & review cycle your code does.
Principles are products of past experience and are only relevant when you’re in the same environment that defined those principles. If your problem space substantially changes they your principles might need to too.
It’s worth noting that the longer you spend on something, the harder it is to let go or change it. This is called irrational artifact attachment and it’s something to look out for. You are unlikely to be working in isolation, so you should be open to discussion, review and potentially changing what was previously considered set in stone.
Finally, all these decisions will end up being reviewed, often far into the future when the solution undergoes a major change. My memory is far from reliable, so I try to keep decision logs for various aspects of a project, including architecture and requirements review. An architecture is the result of many decisions & choices, but tells you nothing about why they were made.
So it’s a good idea not to rely on collective memory and instead create a lightweight decision log of what was decided, when and why. There are many times where I’ve benefited from being able to search my notes during a discussion to re-introduce the factors from the initial decisions. Decision logs can be brief, even just a sentence or two, so there’s no need to write a formal specification for everything. Just focus on recording the key factors that led to a decision to include or reject a process, technology, pattern, etc… Your future self will thank you for it.
Hopefully these tools sound useful to you. There will be plenty of other articles out there about them and, as with most project tools, adapting them to fit your own culture will work best.