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.
