30 of the 97 most important things to be a software architect.

For my software architecture class our professor asked us to read a book by O’Reilly called 97 Things Every Software Architect Should know. I chose 30 of the points I thought were interesting; I hope you learn something from them as I did. I’ll try to keep it as brief as possible.
1. Chances are your biggest problem isn't technical

Let us remember that most projects are done by people and for people. Maybe there is someone that did not follow the rules and that’s making your project to be difficult to implement. Communication is key when dealing with other people. Attitude is necessary when you’re about to have a conversation, and have the ability of agreeing with other people’s point of view.

2. Communication is King; Clarity and Leadership its humble servants

Being a software architect means that you are a leader for a group of people. You are in charge of their work, and you will be leading the project to its end. When you are talking to your group you have to be sure that they understand every single word you’re saying. Just as in any other relationship, communication is the key of success. Find the way to be clear and concise, solve doubts as soon as they are presented, and be around for your team.

3. Seek the value in requested capabilities

If you are an architect, you are probably the most prepared person in the room to solve a software problem. The clients may think they know what they need, but most of the times you will be finding a clearer idea by listening to what features the users need. They could bring up a crazy idea on how to get a specific feature, but as an architect, by using the super power of Active Listening, you may find a better and cheaper way to achieve the same result.

4. Stand Up!

This is a pretty straightforward advice. Imagine you are having a meeting with a huge development team. They could be distracted or talking, and an architect is a leader. The action of standing up from your place shows “superiority”, the corporal language is very important when sending a message to people. When I was the captain of the Leadership associations in high school, they told us that our voice, tone, posture, and body language could transmit up to 70% of the message that we actually wanted to tell.

5. There is no one-size-fits-all solution

We all have our silver bullets ready to shoot, but this should not be practiced on our daily routine. Our industry is extremely diverse and broad. We have to understand that, as much as we like to solve problems in one specific way, there could be better and more precise ways of dealing with them. As Tec students, we are used to try to solve any programming problem with Java, and I’m not saying that it is a bad programming language, but as an architect, we should be open to explore the context and look for better ways to solve our problems.

6. It's never too early to think about performance

I laughed a little when I read this one. When I was in my Algorithms Course, we discovered the magic of complexity, and we kept experimenting with the concept in the Operative Systems course. When we got to the Advanced Programming course, the professor told us “Forget everything you learned about performance, just create working code”. So it’s nice to see that I didn’t waste my time studying performance. Start thinking of performance from the beginning of the project, and we can solve a problem before it happens.

7. Commit-and-run is a crime.

For my Management course Ken once brought a Start-Up CEO to the class to talk to us about the industry. They told us that he had an awesome way to stop this horrible crime. Whenever someone made a push to the main branch on the repository that wasn’t tested and fully functional, they had to have a Jesters Hat on their office until the next person made a mistake. If every piece of the code is tested and functional prior to integration, it will make everything else easier.

8. There Can be More than One

Just as we cannot judge every animal by the same rules, we cannot expect our models, formats and transportation work for every one in the company the same. It could be time consuming, but it’s not bad to have 2 solutions ready for the same problem if it is presented. It’s not needed, but we should not be completely closed to the possibility.

9. Architects must be hands on

Being an architect means more than just giving commands to the team, it means to be involved in a project. If a problem is presented, the architect should be aware of it, and should be able to find a solution. I’m not saying that he should be an expert on every single area of the development, but he has to have the tools to lead a team that is actually an expert.

10. Try before choosing

Choosing the technology to be used should be like going shopping with your friends. You are able to try a specific piece of clothing before buying it. Maybe you think that it would be a nice idea to use Java for creating a web application, but you can soon realize that there are better and more effective tools to solve this project. It doesn’t matter if the decision is big or small, testing it before making a decision will save the team a lot of time.

11. Time changes everything

As an architect, you have to be aware of the tendencies around the industry. In the past 30 years we’ve developed more information than in the 2000 before that. Some things have surpassed the test of time, but some others are now outdated. As the architect, you have to find the simplest way to solve the problems you face, also it’s nice when you are comfortable with the choices you made. There might not be a perfect way to solve a project, but you can make it your perfect way for your tea, to work on it.

12. Warning, problems in mirror may be larger than they appear

When you are having an appointment with your team, it’s important to discuss the problems everyone is facing with the code. Talking the problems with everyone present could make them to look smaller, and easier to find a solution to. Trivial issues, bad smells, risks; If the team is aware of them from the beginning, they won’t cause trouble after.

13. Context is King

We live in 2018. Context matters. You can’t take advantage of a piece of a conversation without listening to the full context of it, and this could be troubling. The context is not something fixed. It is always changing, and it is the responsibility of an architect to keep track of all the changes made. The context can influence the architecture, and funny enough this sentence doesn’t limit itself to software. In the past, the World context has made the Architecture of buildings to change with time and space.

14. It's all about performance

Remember how I talked about thinking of the performance from day 1? Here’s why that’s very important: today the only thing limiting us from becoming The Jetsons is that we haven’t been able to get the performances we need to create flying cars and personal assistants. The world spins around the performance the electronic & software engineers are able to obtain.

15. Talk the Talk

In Mexico we all speak Spanish, but I would say that we speak 50 different versions of it. In Guadalajara we use expressions that could mean something totally different in Culiacán. It’s important to know the “language” of the place you are living and working at. If you were to go to a Software Architects convention for some reason, if you know all the common terms used by them you will have a more useful conversation.

16. Fight repetition

This is an advice I always get while getting a project done. Let us imagine the world “Duplication”, now, add some little horns on it. That’s the way it should be. As an architect you have the responsibility of setting the pace of the project, if you plan for your code to be clean, and following patterns, you will help your team to save some time.

17. Welcome to the Real World

Never forget we are part of a bigger world. We as software engineers can get used to Boolean answers to all our questions, but in the real world things can change in a snap of the fingers. Try not to lose it, and go with the flow. Most of the problems in the real world can be solved being a human being. It’s the responsibility of an architect to try his or her best that these problems don’t affect the team a lot.

18. Don't Control, but Observe

The next two are very connected with each other, the software architect should know what’s happening around him, you can use the metrics that can be achieved by the tools that the programming languages have. It’s useless to try to control every single action happening around a project, and can be exhausting. Try to focus on the big picture, while being alert to possible red flags that could appear.

19. Empower developers

Whenever you decide to lose the “control freakiness”, you will have to learn how to trust your team. They have to feel like they are able to take decisions that could affect the entire project. If they are on your team, they are probably experts on what they do, if they are not experts, just be sure they have the capabilities to make a wise choice.

20. It is all about the data

The other day I was talking to my friends about how did Facebook made money at the beginning of the web page. They didn’t have any advertising, or admission fee; and then it hit us. Facebook had tons of information and they could sell it to other sites, to understand their clients. Information is everything! If it is bad managed, then you will have an overwhelmed team. But when it is on your side, then it’s going to be great.

21. Prepare to pick two

I found this point very interesting, sometimes you have to find yourself in a scenario where you won’t be able to satisfy them all. Perhaps you’ll have to pick between satisfying Linux, Mac or Windows; or maybe Android, Iphone, and Windows Phone (?). But it’s going to be extremely difficult to do everything. It’s part of your work to be realist, and to measure the abilities of your team.

22. Make sure the simple stuff is simple

With the time, we become aware of more tools to solve the problems around us, but we forget the simple ways to solve easy problems. Just as chefs, when they become experienced, they stop cooking beef, and carrots, even though everyone likes those ingredients, maybe looking to the past will help you in the future.

23. If there is only one solution, get a second opinion

I’ve always thought that Computer Science is a team-based major. If you meet a great team, that can give you good advice on how to code better, you are going to have a great time studying this. If you have a problem, probably someone knows a better way to do so. It’s okay to ask for advice, and whenever you get some, please let everyone to know that another human being help you.

24. Shortcuts now are paid back with interest later

As you may imagine, there is not an easy way to do something hard nowadays. Just follow the advice of the old tale of the rabbit and the turtle; it’s better to go slow and steady than fast and risky. The first stages of a project are always the most important ones. Designing greatly helps you to not have more problems in the future. Remember than the sooner we identify a problem, the cheaper it gets to solving it.

25. Avoid "Good Ideas"

We all know a guy named Steve (Or Francisco) who will always say something unachievable. Some days they could be helping to finish the projects, but other days they could be trying to convince you and the boss that we could use some hover boards and penguins to travel faster around the company. When everything is defined, it is important to stick to the plan, if a project suffers a lot of changes, it could die or get too complicated.

26. Stretch key dimensions to see what breaks

I think I started to understand how to be a better UX-er after someone told me this great piece of advice: “Think of the average American person, got it? Now remember than half of your audience is less smart than they”. Sometimes people will do something impossible to understand and break your program. It’s better if you break it yourself in the testing areas than let other people to break it for you.

27. It Takes Diligence

Not all days will be bright while leading a team. You could be having the worst day of your life, but remember, your team needs you to be their leader! Maybe you are dealing with a difficult customer, or something is not going as planned in the development area, be around so you can solve the problems and make everyone’s life a little less complicated in time of need.

28. Take responsibility for your decisions

This is an advice that we got when we were in elementary school; yet, everyone seems to have forgot it. We are not perfect; we can make mistakes and the important part is to take responsibility and find a way to solve the problem. Never forget the importance of communication and become the psychologist of your team. Listen to all their problems (at least the related to the code) and try to leave everything clear as water.

29. Choose your weapons carefully, relinquish them reluctantly

It’s common that the Software Architects are the most experiences (and older) developers of an enterprise. The are surrounded by technologies that they have worked with for years. It’s important to choose the tools you will use and then, be proud of your choices. Everyone must be aware of what tools the team is using and support the decision. #GoTeam!

30. It will never look like that

It’s extremely important to plan, but also to know how to let go. Sure, you took 3 weeks on designing how the upper button will look like, but some of those things like that are disposable. Never get attached too much to stuff, because maybe in the process the team could discover a way to do something better.