Mechanical Decision Making on Software Projects

Each choice you make as a software engineer, from the selection of tools, technologies, or development and testing approaches, can dramatically impact your personal and team's performance. The decision-making process you use is arguably more important than the actual decisions, as it is definable, improvable, and repeatable – it's the multiplier behind the ultimate outcomes you achieve.

Bias

Our psychology often leads us to make bad decisions due to something called 'psychological bias' – a cognitive shortcut that influences judgment and decision-making, often causing us to overlook information, underestimate risks, or overestimate benefits for certain approaches.

Take an example; tell me how many red cars you saw last time you went for a drive? Can you tell me? I doubt it.. Now imagine this; I tell you I will give you $100 for every red car you see next time you go for a drive. What do you think will happen? You are going to know exactly how many red cars you see. This is because you now have a bias; a bias to actually care about the number of cars you see!

Blind Spots

Biases impact our decisions and affect the code we produce because our brains have natural 'blind spots'. These are built-in limitations in how our brain organises and filters information around us. There is too much information at any given time for our brain to process, so it filters out a large majority of the information it receives, focusing only on what it deems relevant based on pre-existing information, beliefs, motivations, and feelings (in other words our biases).

Here's a quick warning for senior engineers; the more experience you have in something, the more likely you are to think you have fewer blind spots – a dangerous assumption, as research has shown that people tend to overestimate their abilities for easy tasks but underestimate them for more difficult tasks. So make sure you always consider more junior opinions - they may be able to see something you can't.

Time Impact of Decisions

So, biases and blind spots affect our ability to make decisions throughout the development cycle, from minute-to-minute choices to those spanning weeks or months. The real problem with biases and blindspots however is that many decisions that are made off the back of them come too late in the delivery cycle, when their impact is already high and difficult to change.

For example, architectural and testing approaches have implications for folder structure and coupling between modules, but by the time we reach code review or testing, we're often stuck with decisions made earlier. Trying to change them at this point can lead to counterproductive conflicts, as it's hard to hear that you need to change code you've already spent hours or days on.

Instead of leaving debates until the end of the release cycle, when it's often too late, we should introduce a mechanical decision process that moves conflict earlier in the delivery cycle, before we're committed to decisions. The longer you leave a decision, the higher its impact.

Mechanical Decision Making (Using Principles)

This mechanical decision process involves developing principles – logical thinking frameworks to help you make decisions. Principles act as guardrails, providing a consistent set of criteria for assessing potential solutions, approaches, and trade-offs.

You can have a principle for anything. The world of software has many principles you can use (such as SOLID). They are super useful; but you don't need to just blindly swallow off-the-shelf principles; you can make your own. In fact this is exactly what we did when we designed The 5 Principles of UI Architecture which you can download here.

While biases and blind spots can hinder effective decision-making, establishing a set of guiding principles can help teams side-step them to consider the best way of doing things and get greater clarity and alignment. By collectively defining and adhering to a coherent set of software development principles, teams create a shared framework for evaluating choices and making decisions that align with their project's goals and constraints before these decisions have made too much of an impact.

In our online course Decision Making for Engineers we develop a way to make better coding and even strategic decisions by implementing a ‘principles’ approach; you can think of a principle like a mechanical part of your brain, that lets you filter inputs and come out with a different output instead of letting your bias take over....

These principles should serve as guardrails, providing a consistent set of criteria for assessing potential solutions, approaches, and trade-offs. For example, principles focused on maintainability might guide decisions towards modular architectures and well-documented code, while principles emphasising scalability could influence the choice of technologies and infrastructure.

Regular reviews and updates can ensure that the principles remain relevant and aligned with the project's evolving needs and objectives.

Conclusion

In conclusion, biases and blind spots are inherent in human decision-making, leading to weaknesses in code structure and strategic choices. These biases often result in conflicting decisions made late in the project lifecycle, causing negative conflicts. Adopting guiding software development principles helps mitigate these issues by establishing a shared framework for decision-making. By embracing this principled approach, teams can navigate complexities with clarity, alignment, and increased chances of project success, making better coding decisions earlier in the delivery cycle before the 'commit' phase creates too much resistance and unhealthy conflict!

Author: Pete Heard

Pete is the founder of Logic Room. He designs the companies core material for JavaScript architecture, test automation and software team leadership.

LinkedIn