There's no such thing as a technical decision
Let me just tell you something right away: strange as it sounds, your goal as a software developer is not to write code, not to write tests, and neither it is to put and maintain a system in production.
Your goal as a developer is to help your company make money.
I say make money, but it could be something else depending on the kind of organization you work for. It could be more users, more page views or more ads, anything. Do you know what’s the goal of the organization you work for? So, that’s your goal too.
If this is okay to you, fine, you may go ahead reading this article. But if not, if you disagree or didn’t understand, you should stop here, this article won’t make sense to you. You can close this tab, see you later!
Still here? Great, moving on.
Software gets built for a reason. The target application—whether a trivial game or a program to guide radiation therapy—is the entire point.
Sandi Metz
I’ll say again: there are no technical decisions.
Are we going to use React or Vue? Ruby or Python? Are we writing those tests or not? It is common to hear this: Technically, this is the right thing to do, but the business needs us to do that.
The business always has its way. The business always wins this fight. Software doesn’t exist by itself, the business is the reason software exists and it is the reason our profession exists.
I think this tweet explains it:
The point is: all decisions are economic ones. If we’re going to use Windows or Linux, Java or C#, Microservices or Monolith, it is the business impact that will ultimately decide. Not what I like the most, not what is hyped and not what Hacker News or my favorite guru said.
Our role is precisely to match the business’ needs and goals to the technical reality.
Only we can do this. We are the experts.
Business is Software is Change
Software played different roles since its origin. Its use and how it was built transformed throughout the decades.
In the 60s, when software was first used by people other than military and academics, it was mostly used to automate some task that already happened manually. The first commercial computers, those huge and super expensive machines that people used to do stuff like running payrolls, are from this time.
Smaller and cheaper computers could arrive later, when microprocessors were invented. And instead of companies having one big computer that was shared, people could have their own (micro)computer. The PC, the local network and tools like Visicalc and Lotus 1-2-3 revolutionized the way people worked in the 70s and 80s.
After that, around 1990, we see software perform a new role: “real world” products would have their software version. The software version was a competitive advantage for these products and companies. Remember Encarta?
A CD-ROM encyclopedia is still an encyclopedia, it’s the same product. The technology only enhances its capabilities: less physical space, more content, multimedia and easy searching. The first company’s websites from this time were just a façade or showcase for the brick and mortar business: Hey we’re here on this Internet thing! Our address is this and our phone is that. Give us a call!
Smartphones and Web 2.0 technologies allowed businesses to do more than put their flag on the cyberspace, it allowed them to create businesses and products that could only exist due to the technology. These products are not a just a web or software version of the real world thing, they could not exist without the technology.
What is Uber? Netflix? Fitbit? It is the app, the cloud services, the scalability, the resilience, the GPS, the sensors and the AI. These companies and these products only exist because of the technology. They are not enhancements or competitive advantages. They are the business itself.
No wonder a lot of the organizations that are recognized by its technical excellence and house the best engineers are not technology companies per se, they are transportation, hospitality, health and fitness and entertainment companies. Years ago, engineers’ dream job would be work for IBM or Microsoft, today they want to work for Tesla or Facebook.
Before we had
- Rigid rules
- Few computers and few people using them
- Technology supporting what already existed
Now we have
- Fluid rules
- Everybody has a computer in their pocket
- Technology is the business
This implies that for a business to do well, the software has to do well. A successful business depends on a successful software. If the system is down, it is not only a department that stops, or some service gets degraded, the whole business halts. It stops working and making revenue.
This moves the technology and us professionals from the backstage, where we used to support the people doing the real important work to the center of the stage, where the show happens.
Every business is a tech business now.
Businesses are very dynamic things, changes happen all the time.
Businesses pivot, change strategy. They grow, get more customers in more places. They shrink and need to decrease their operation. Businesses create new products, new sales channels, different ways to serve their clients. They experiment, launch new products, test and then pursue or close that line. Businesses respond to law changes, to customers feedback and to competition actions.
A business that stays still dies. So does software.
Ugh! They changed the requirements. Again!
Have you heard this complain? Usually followed by stories of stupid users or clients that never know what they want and keep changing their minds, to the annoyance of the wise programmers.
For real? Who thinks like this didn’t get what we are doing. Didn’t get what is the role of a software developer.
As I said before, our role as developers is to bring value to the business. And we just saw that businesses change all the time. It’s normal and healthy that it happens. And that if the business changes all the time the software also has to change all the time.
A good developer is someone that besides never complaining about change in requirements, is one who understands the importance of those changes, accepts them, welcomes them and knows how to code in a manner that makes changing cheap.
Change is inevitable, so we have two alternatives on how to proceed:
We can treat our software as something that has an ideal form and that every change potentially moves it away from this form. And what we do all day long is modify the software, the same way we did yesterday, the same way we will do tomorrow. And the work is never done.
Or we can admit that changes are part of business and software development, and treat it like business as usual to us. We can have in mind that it is our job to make changes happen as smooth and cheap as possible. And that it is exactly it that allows the business and the software to prosper.
Changing requirements are the programming equivalent of friction and gravity. They introduce forces that apply sudden and unexpected pressures that work against the best-laid plans. It is the need for change that makes design matter.
Sandi Metz
Software tends to chaos.
All software change. The business demands that features are added or modified, that libraries are updated and that security patches are applied.
Each one of those changes by itself is small and harmless. But over time they add up and, when we’re not careful, the program turns into a big tangle impossible to work with.
The more tangled, the more rigid the software becomes – the opposite of what software should be. Software’s main attribute is its flexibility, its ability to adapt. It’s what distinguishes it from hardware, after all.
The more rigid the software, the harder, the slower and the more expensive it gets to work with.
The purpose of design is to allow you to do design later, and its primary goal is to reduce the cost of change.
Sandi Metz
One way to reduce the risk and cost of changes is to plan and to prepare so the impact of these changes are as low as possible. We could design our software accordingly to this plan and it would be ready for future changes at a low cost.
But we can’t predict the future.
So, what’s the alternative?
Take a look at this equation. It’s a simple way of understanding risk:
Risk = Chance That Something Happens x Cost If That Something Happens
Traditional software engineering attacks the first factor of this equation: the chance or probability.
The idea is that with research, documenting requirements and estimation, we will know what will be done, the eventual changes and the whole software roadmap. With everything known and predicted, the probability of a change or surprise becomes very low, reducing the cost.
The Agile way, on the other hand, doesn’t worry about the probability of change. We know that the chances of something changing are 100% and, in fact, it is desirable.
What we propose is that the cost of change is reduced. That messing around the software has the least economical impact and it can happen all the time.
Instead of trying to predict what will be the changes, which is impossible, we have to make changing cheap, so we can iterate, experiment and test hypothesis, over and over again.
Design activities certainly do take up time and effort, but they payoff because they make it easier to evolve the software into the future. You can save short-term time by neglecting design, but this accumulates TechnicalDebt which will slow your productivity later. Putting effort into to the design of your software improves the stamina of your project, allowing you to go faster for longer.
Martin Fowler – Design Stamina Hypothesis
Alright! Our software’s design looks excellent! It took us only four lines of code to add that new feature, following all the good practices and principles. But this is a real-time-high-risk-performance-nothing-can-ever-go-wrong-scary type of system, and brings up a preprod environment with production like data and run all the tests is going to be a bit of work. Let’s not forget also all the configuration and all the 37 manual steps that have to be done in a specific order to integrate the back-office and 3rd party systems.
There’s something wrong in this scene, right?
Design should go beyond the application. Automated testing, DevOps culture and Infrastructure as Code allow us to apply all the software engineering practices to the Operations space. Tests, data, environments, configuration, logs, alerts, monitoring, this is all code. All that is code change and should be designed.
People ask me: should I change my design only to make the software more testable | deployable | monitor-able | etc.?
Yes! Of course!
Your system – the app with data, tests, environments, processes and everything else – should be operable and changeable the same way we like our apps to be.
Business is permanently changing, so is software.
The only way for this change to be sustainable is with proper design. Our role as developers is to guarantee that the business can prosper through evolving software.