·9 min read
Why Software Architecture (and Other Practices) Matters
If you want to start getting into application engineering, I recommend you keep reading
First of all, you should know this isn’t a technical post in the sense of applying knowledge. Rather, I’m trying to show why Software Engineering matters and spark some interest. This goes way beyond learning the most in-demand framework or language of the year. If you want to start getting into application engineering, I recommend you keep reading :)
Well, I’d like to start by mentioning that you tend to see better Software development practices at product-focused companies, where there’s a single business model and you have the freedom to improve your company’s product. In my experience it’s more common, and makes more sense, when our developers only have to learn the business rules and policies once. That lets them constantly improve the system, rethink a solution over and over (even one that’s already shipped), refactor, propose, etc. So those might be good places to sharpen your skills as a professional. Just saying ;)
What is architecture?
Personally, I like to define it briefly as the way to control accidental complexity and keep essential complexity. If you don’t get what that means, don’t worry, I didn’t either at first. I’ll leave the concepts below :)
Accidental Complexity: It’s everything that wasn’t planned as part of the development and that now makes maintaining and extending the system harder. Basically, this is what ruins your day. How many times have you built a program that starts out easy and ends up hard, or maybe does something really basic but is a nightmare to change? Don’t touch it or it’ll break! Any developer who’s been around a while has surely heard that one.
Essential Complexity: You can think of it as the natural complexity of what we’re building. Every time we add new features to our application we’re adding extra complexity, but unlike accidental complexity, this is done out of necessity or a requirement. E.g.: sending a notification when a user subscribes to a post.
Essential complexity is the kind we want in our application; accidental complexity is the kind we need to reduce.
Heads up! I’ve heard some professionals talk about Software architecture as if it were about gathering requirements, or even about design (Photoshop and that kind of stuff) or the markup (HTML, CSS)… nothing could be further from the truth!
Clearing up confusion
Product-focused companies, which are usually the ones that best follow these practices, show some of the benefits of architecture. But I want to make something clear to avoid certain situations: don’t be fooled by a system that works. Good practices are hidden from the spectator’s eye. A team of developers with solid architectural knowledge is at the highest level of a Software Engineer, but that still doesn’t mean someone without architecture knowledge can’t build programs that work well. Architecture backs an application working well, that’s clear, but as strange as it may sound, it plays a passive role in that sense. Working well is basically the consequence of the architect doing things right. Going back to the fact that there are professionals with little (or no) knowledge of this stuff, we can’t ignore that they build programs that work all the same. So is an application that works not the same as a well-designed one? Of course not, and it’s a common mistake to think so. The core purpose of architecture isn’t for things to work well, but to support the application’s lifecycle (maintenance, easy understanding, and ensuring continuous development). An application that works well from the user’s side doesn’t mean it’s well designed. A well-designed application ensures it covers the lifecycle aspects mentioned above. Uncle Bob says “the ultimate goal is to minimize the lifetime cost of the system and maximize programmer productivity”. So, from everything said, you can infer that software that simply works well won’t necessarily keep working well throughout its life, nor that it can be extended or expanded with relative ease, let alone that it’s a good investment. This is where applications stop being Software and become Hardware (something hard to change). If you don’t keep this in mind, you can throw big investments in the trash or inflate them unnecessarily. I’ve even seen companies on the brink of bankruptcy because of their bad designs. We don’t want to end up there, which is why we look for a better way of doing things.
Uncle Bob: the ultimate goal is to minimize the lifetime cost of the system and maximize programmer productivity.
Its benefits
Architecture plays a key role in business models turned into applications. It’s a reflection of the company itself and its ability to adapt to change, a reflection of the continuous improvement of a profitable model that changes and adapts to a dynamic, hard-to-predict environment. That’s exactly why development focused on architecture gives us a healthier application (fault-tolerant) and a scalable one (able to grow). And as you can see, this is nothing more than a summary of everything explained earlier, but here are a few extra things we get out of it:
- Ease of development.
- Less need for documentation.
- Team organization.
- Better testability.
- Error isolation.
- Fewer bugs.
- Higher return on investment (ROI).
- Low technical debt.
- Better communication between teams.
- Etc.
Some day-to-day stuff
I hope I’ve given you a clear idea of what all this is about and what we’re after. Now that that’s done, I’ll show you some problems people commonly run into that can be solved through architectural decisions and good practices:
- Nobody remembers their code or why they wrote it. Even if you do remember, it’s usually a vague, blurry picture with little context about what it’s really about. This has been said a million times, but apparently repeating it is never enough.
- Nobody remembers exactly the business goal the application was built for. The problem here is that we can no longer check our ideas about the application against the purpose of the application.
- Lots of people touching the code. It’s normal for many developers to touch an application, and it’s very likely the original team will never work on it again. That shouldn’t be a problem. But if there’s no awareness of the practices applied during development, how do we transfer knowledge to new devs? Or how do we get them to follow the previous team’s style guide if it was never defined? There you have questions that will pull you into this world, no way around it. If you notice, this is usually the excuse for why a legacy application is in such bad shape.
- It’s easier to understand how it works through trial and error than by reading the application’s code. Has that happened to you? Let me make a side note here: a good developer doesn’t rely on trial and error; it should be kept to a minimum. Why? Because we should understand what we’re doing, simple as that.
- The code is written in each programmer’s own image and likeness… it’s a mess. People think it can’t be controlled, but the truth is it can. A good way to solve this is by using patterns.
- etc…
A good software professional doesn’t rely on trial and error; it should be kept to a minimum.
With these points in mind, how could we solve them? For this I want to bring up some words from Robert C. Martin. In his book Clean Architecture he says “a good design should scream what the business is about”. If it’s a sales business, our project should scream: I’m a sales system! That way you won’t need to set aside huge amounts of time for research; you’ll just look at the classes, names, implementations, contracts, tests, use cases, etc. That’s how you’ll understand the project. That’s how the greats work (with little uncertainty), and we should want to work like them.
Good practices like Clean Code, principles like SOLID, DRY, design patterns, etc. are what end up solving all these typical problems in application development. As a personal recommendation to start improving quality, I suggest learning design patterns, since they’re solutions to recurring problems that will help you reduce the complexity of what you build or have already built.
Spreading the word
Like I told you at the start, this isn’t a technical post in the sense that I won’t teach you how to apply anything, so I won’t talk about a given pattern and how to implement it, but I will leave you the most common ones so you can research and learn on your own, among other things I know will help you:
Patterns
- Factory Pattern
- Builder Pattern
- Criteria Pattern
- Strategy Pattern
- Repository Pattern
- Decorator Pattern
- Prototype Pattern
- Adapter Pattern
- Template Method Pattern
Programming paradigms and code styles
- Imperative Programming.
- Declarative Programming.
- Functional Programming.
Software architectures
- Monolithic Applications
- Isomorphic or Universal Applications
- Microservices
- CQRS (advanced)
- Hexagonal architecture (advanced)
- DDD (advanced)
Recommendation: Study clean architectures.
Principles for building even better applications. These are essential, you can’t not know them!
- The Twelve-Factor App (https://12factor.net). This is really important! Seriously, it’s brilliant.
- SOLID (fun fact: its opposite is STUPID).
- DRY.
- KISS.
Books — in this case I’ll only recommend one. In other posts I’ll publish a list of books I consider really valuable.
- Clean Code. (The book every developer should read)
Extra
Finally, it’s important to stress that architecture is neutral and agnostic to the technology you’re using. Unlike the framework of the moment, this knowledge will absolutely stand the test of time. That’s why good devs write programs that are just as good in Python as in Java. If you think the tool makes the professional, you’re very wrong.
Good devs write programs that are just as good in Python as in Java
Wrapping up
I created this post as a way of spreading the word so you can look up and learn on your own something that already has a lot of material published by excellent professionals, and that I truly believe will take you to the next level if you don’t know it yet. Studying this made me a better professional, so I want to share it with you.
I hope it’s a big help in your career and that you succeed in everything.
References
This article was originally written on Medium, you can check it out here -> https://medium.com/@esteban03/la-importancia-de-la-arquitectura-y-otras-practicas-ef320f631b4f