** This article has been ported over from my Medium blog. - Original time of writing: Dec 14, 2017 **
If you stumbled upon this page by accident, chances are real you either know why you need an architecture and otherwise it’s only a matter of time before you find out. Software architectures are (in my personal opinion) one of the most underrated aspects of software development, and I am really pleased to see both Google’s Android team as well as the community engage into discussion about this topic more often in recent times.
So remind me again, why do I need one?
To address the need for an architecture, we can best start with an example of a situation that both old and new developers have likely been in touch with. I think most developers remember a time where they just started working on an app without asking too many questions and they arrived at a primary version/minimal viable product by using a few dirty workarounds, implementing some nasty circular dependencies and skipping writing unit tests (because hey, why waste time on writing tests when that time could be used to write features right?). So you deliver that product with pride and you know it’s not perfect, but ‘it just werks’ and you’ll be damned if that’s not good enough.
Your managers/colleagues/stakeholders are all thrilled to try it out, and during alpha testing they suddenly come up with a new feature which could in their opinion DRASTICALLY INCREASE BUSINESS VALUE. They ask you to give them a rough estimate, and you shoot an arbitrary number off the top of your head. Management nods happily, and the feature has been approved.
So drop everything else you might’ve planned to work on, it’s time to scale! They chase you back to your seat and have you open up the codebase again to start working on the new future of the company. While you start digging through the code, you see some prenatal issues arise. Your train of thought switches into higher gear, and you suddenly realized you forgot to apply the lying weasel factor to your initial estimation. Your mind starts going through a crisis and leaves you with some memorable quotes such as:
“Damn, maybe I shouldn’t have just copy-pasted this block of code 8 times”
“Oh god, I forgot what {INSERT THIRD PARTY LIBRARY NAME} even does”
and one of my personal favorites:
“Why did I name this class CoolFeatureController when it doesn’t handle that cool feature, nor does it control anything. What the hell does a controller do anyway?”
In a state of inner turbulence, you start clawing through StackOverflow topics hoping to find a ready-made solution which will fix everything and make the pain go away. Time flies by, and you have managed to fix a few issues but for the 5 issues you fixed, 7 blockers have been introduced by the new feature.
Considering you’ll have to report your progress to management today, you gaze around in the room to see which profile is best-fit to be sacrificed as a scapegoat for your failure. When it turns out that everything traces back to you, you swallow your pride and decide to face management with an impressive explanation of the ‘inherently intrinsic and complex’ technical problems of the new feature…
But what if I told you that you don’t ever need to go through this situation again? Well I can’t promise it will never happen again, but I can help you reduce the odds drastically. If you want to avoid similar situations to the one above, you’ll have to start thinking about what you’re going to create. More specifically, you have to start thinking in architectures.
Right… But what _is_ an architecture actually again?
If we ask google for a definition of the word, the most relevant result is the following:
The complex or carefully designed structure of something.
This does seem to pretty much align with our previous statement of “start thinking about what you’re going to create”. And the beauty of this definition is that it already addresses one of the pain points of software architecture: “complex OR carefully designed”.
Architectures don’t have to be inherently complex in nature at all, as long they address the current & potentially future needs of your product. But let’s keep latter remark for a later topic.
Ironically, software architects usually don’t deal with software code architecture but rather with a higher-level abstraction. (http://dilbert.com/strip/2017-07-18)
An architecture is a plan, a blueprint for your application. It’s a testament or an ode to the amount of thought you’ve invested in the application. If handled properly it should address typical pain points (some of which have been mentioned in above example) such as: code reusability, (unit / instrumented) testing, scaling, separation of concerns, concurrency, state management, user feedback, error handling, …
All of these topics (and maybe even more!) will be handled in the course of the following chapters. And to top it off, I have even more good news:
You don’t even have to start thinking about it from scratch. A lot of smart, experienced and plain heroic engineers have already left their architecture sagas waiting for your eyes to feast upon.
So an investment of a few days of research could potentially save you from a lifetime of awkward conversations with management. And not only that, in general I can promise the following:
It will make you a better software developer/engineer
Developing will be more enjoyable
You’ll spend less time on maintenance and more on new features
Your market value & desirability as a developer will increase
The more you use architectures, the better you will get at recognizing, adapting and applying them
Talk about ROI! And the best news is that even if it doesn’t work out for you, you can always just go back to writing spaghetti code like nothing ever happened!
Okay you’ve got me convinced, where do I go from here?
Read the next release of IAA where we start with the basics and tackle project structure & clean code in a lightweight manner, in a way that I personally wished I could’ve found all that info centralized.