“There are so many factors to consider when it comes to software development.” Every senior developer has heard this from their colleagues, or maybe they’ve said it themselves to a client. It’s a good thing—great software development is flexible. You never want your software house to say, “We have always used this technology, so we’re sticking with it forever.”

When an idea appears and it’s time to choose a technology stack, a developer will often say, “Well, it depends…” because there is a gut feeling that conditions and goals are unknown, and it wouldn’t be wise to proceed right away. 

But what exactly do software development decisions “depend on?!” Let’s break down how we investigate circumstances to make technology decisions to find out just what the heck “it depends” really means when we say it.

Rule 0: Postpone Decision-Making

This may seem counterintuitive at first. But the best way to approach making a decision is to realize that you shouldn’t make one right away at the start. In software development, the best thing to do is to delay any decisions for 3 key reasons:

• You’ll have more information down the line to make a better decision. Give your teams time and they’ll make smarter decisions!
• You may not even need to make the decision in the end.
• Other possible solutions may appear in the meantime!

Any decisions made in software development means, in one way or another, the rest of the system relies on it. Rather than making a decision on a specific solution or implementation and jamming it into our architectures, we may build around it, so in the end it’s less tied to the specific solution = more flexible. The entire project and its stakeholders benefit from holding off on making any concrete decisions for as long as possible.

But let’s be clear, not all decisions can be postponed indefinitely. So which decisions need to be made first? Well, it depends.

• What is our confidence level of the objective and technology?
• What would it cost if for a wrong choice down the road?
• If we aren’t going to make a decision now, how much would it cost us?

The answer is to postpone all key decisions as long as possible, except the ones that identify cost-centers and time variables. These should form the groundwork for any future decisions, as deadlines for making decisions help drive the process and make time constraints transparent for everyone.

Rule 1: Go for the goal

Business clients often come to us with a specific goal in mind. They assume these goals are well-defined, but nearly 100% of the time, we as software developers have to investigate much deeper.

• Who are the end-users?
• What are they familiar with?
• What’s the market like?
• What are competitors doing well? 
• How is this project going to succeed?
• What are the expectations at each stage of the process?

All stakeholders in a process need to ensure that a goal is well-defined. Without this metric, no one really knows what ‘success’ looks like at the end of a project!

Decision-making is best led by hard-coding our goals. The business-side will typically drive these goals, but developers and designers need to fully understand them as well. Even if you have a strictly technical decision to make, the truth is that those software decisions are 100% business-driven.

Rule 2: Describe characteristics as costs

Hey, it looks like we’re finally getting somewhere! The next stage is gathering options about software choices, but we need to pinpoint exactly what we’re looking for. 

For example, the business or developer sides can say that “we need a solution that is easily maintainable,” but it’s not telling us specifics. What does maintainability mean for this specific project? Who benefits from ease of maintenance? Why do we even need something maintainable? What does maintainability look like after a month or year?

When we drill deeper into attributes like ‘scalability,’ ‘maintainability’ or ‘ease of use,’ we find that they tend to provide benefits to specific key stakeholders in a project. Of course, they impact everyone, but some group is benefitting the most:

• Shareholders
• Development Team
• End users of the application

Depending on the type of application we are building, the people from groups in the above list may even be from a single company (for example when we are creating company internal software!)

However, we still need to define who cares about a particular decision, and how it impacts them. 

Let’s look at some examples:

• Fast Performance - Primarily affects end users, as they want fast, responsive experiences. It indirectly benefits shareholders, as they can lose customers if the app is slow.
• Ease of Development – Greatly benefits the development team in terms of headache and time costs. This indirectly benefits shareholders, because of shorter development lead times and less hours worked.
• Highly Integrated - Impacts project shareholders directly as they benefit from connecting other aspects of the business (SaaS services in marketing, accounting, logistics, e.)

But here’s the rub. All of these ‘characteristics’ of a website or application, are directly related to cost centers. Slower performance loses the client money from unsatisfied customers, or lack of integrations may hinder the business’s growth effort. The “it depends” portion of this rule is that a software decision balances people’s needs and cost centers. 

Fast decisions may lead to helping a business in the short term, but also may slow down the long-term development of future projects. Everything costs something, and this step is where we find out who gains what, and at what expense.

Our job is to compromise between this mix of parties, their needs, the characteristics of the app project, and the costs of what happens when we decide to move forward.

BTW: This is the reason for most of the technical debt many organizations are dealing with right now. Sometimes we choose to prioritize short term goals (e.g. going to market earlier) and we simply forego the variable of time and infrastructure for growth down the line, which leads to legacy platforms that aren’t easily maintainable.

Rule 3: Keep flexible for change

Things will change whether you make a decision or not. Even if you don’t do anything, the environment will change: end user goals will change, technology will become outdated, or new solutions will appear. 

Does that mean that we need to prepare our code base for every possible change that would or would not happen in the future?

NO.

Of course, we can try. We should listen to the letter O from SOLID principles. But first of all, even if we do, we won’t prepare for EVERY change. Secondly, more important, every flexible point in the code comes with a price. More “joints”, and more abstractions make our code base bigger, which translates to a higher cost of maintenance.

That’s why we should communicate with all the parties mentioned earlier. You should deliberately choose where those joints should be built, based on discussion on what can change in the future, but looking no further than 1–2 years ahead.

Now, a Favor

As you can see, it’s not that hard to make an IT decision! We really didn’t even make one at all, just asked a lot of questions, and gathered tons of information about the project. No matter which technology decision we make, they will be stronger and reliable when supported by concrete, well-researched intentions.

Therefore I have a favor to ask of all readers:

• If you are a Product Owner, make sure your team has enough information to make proper decisions.
• If you are a Developer: don’t just say “It depends” without explaining WHAT it depends on! 

The Architecture of Decision-Making

Remember that in modern software development, every decision (even those not being made right now) should be written down in the Architecture Decision Record. 

This document should clearly state the problem, the choices for solutions, which one was finally chosen and reasons for WHY. 

Trust me, after a couple of months or years the team working on the project will be thankful for such a document. The next time you have to show that ‘it depends,’ you’ll have a traceable record that shows exactly what it depends on, and why it makes the most sense (or at least did, at the time!).

Originally published on Medium.com