When Software Developers start thinking about a new small class or solving a big problem, an internal voice tells them how to do it properly, that voice is their Inner Software Architect.
Your Inner Software Architect is better developed if you read some software architecture books, have already solved something similar in the past (experience), or are keen to challenge yourself and define a new development way of doing it (innovation). Sometimes, your Inner Software Architect is so “busy” (or tired!) that they forget some coding foundations and start guessing what you should do. This is the moment when you should stop listening to that voice and refresh your knowledge with new architecture courses, frameworks or even different programming paradigms.
There are some foundations that your Inner Software Architect shall always have in mind; if not, feel free to choose your next Design Patterns course or a book to guide you for the next days/weeks and help them to refresh in some topics.
Consider this when you have a new “problem” on your hands:
- Think: Think about the solution and don’t disperse from it.
We often need to solve a problem, but we start noticing many things we should also fix and others that we can refactor. At that moment, it is time to think only about that problem and solve those issues in the future.
“Do it like a ticketing system”: if you have a ticket to solve, there is an estimated time to solve it, so why should we focus on another topic if the person is waiting for you to fix only that? When you are solving a ticket, this should be your mindset, but… take notes about what is wrongly implemented and the places where you could do better. When you finish solving that problem, transpose it from your notebook into your ticketing system/to-do list or backlog. What you found is essential to be done as well, but only after you have solved your first problem!
- Quality: Please always think about the quality of your delivery.
When delivering code, always think if you would accept that code as a reviewer and follow these steps:
- Check if you can solve that problem better.
- Think about your solution and if you would implement it differently.
- Be assertive, and don’t spend an eternity on that. Consistently deliver your code with Unit Tests that prove it is well done and, more importantly, it’s needed!
- Reusability: You should be able to reuse your code tomorrow or in “2 years”.
Usually, when we deliver a solution, we think about the problem, and with the “pressure of delivering”, we don’t believe we can reuse this code for something else. Id that is your “normal thinking”, that is a huge mistake! We should always think that we are delivering something to solve our problem and someone else’s problem. We are not saying we should generalise everything, but if we believe this problem can also occur in other classes, why not?
- Scalability: If it needs to grow, is your code “elastic” enough?
When writing code, we should always plan for it to be easily modified, but that, sometimes, isn’t that easy. You need to consider these three factors:
- Complexity measures the number of nested conditions in the code.
- Parallelisation solves the problem of adding more resources in a faster way.
- Caching is a high-speed data storage layer that stores subsets of data (typically transient) so that future requests are served up faster than accessing it from its primary storage location.
Applying a design pattern doesn’t solve the scalability problem, but understanding better the problem maybe will.
- Communication: “Communication – the human connection – is the key to personal and career success.” (Paul J. Meyer)
It is a standard topic in many areas, but in Software Architecture, everybody must know how we should progress and sometimes, the Master Architect is who should inform the rest about which direction we are going. Suppose you are in charge, or even if you are doing something that can impact others (as most of us), inform everyone about the upcoming changes. The communication can be of any type: verbal, email, documentation update, messaging, smoke signal, or any other agreed, since that’s effective with your team/project.
- Change: Changes in the code will always be needed!
Just so you know – the code you are doing today or tomorrow will change, and you should prepare it for that. As mentioned in the previous points, if your code is “elastic” enough, it will be qualified for that. The code and tools we use for those changes need to support us on that task. A ticketing tool and a version controller that can manage and control changes will help us with all (or almost all) changes we need. Nonetheless, you also need to be prepared for those changes, sometimes, it is not the right moment (fair enough), but sooner or later, the changes you constantly delay will be needed.
- Modularity: Those small coloured bricks always taught us something!
Modular programming is valuable in the Software Development world. If you split your program into modules, and each module contains everything needed to execute only one aspect of the desired functionality, your code will be more straightforward and more prepared for many of the topics we have mentioned previously. Modular programming is an old software technique (from the 1960s, while the coloured bricks started around a decade earlier) that nowadays is still helpful and simplifies a lot of our code. Each module fits in another, and in the end, we will have an extensive construction where a module (or a group of modules) can be replaced by a similar one that fits as well.
These topics look trivial, but sometimes, this is different from what happens daily. We always forget about something, first because we are humans, and second because we make mistakes. With experience, we start noticing these changes and adopt them better in our Inner Software Architect.
And when you do so, you are growing your knowledge in the Software Architecture area, which is an essential part of your T-Shaped Software Developer:
