This will be my list of the 30 out of the 97 that I felt most identified, if you want to read all 97 here is the link of the book.
So, let’s begin
1) Don’t put your resume ahead of the requirements
This first one is kinda obvious (most of them are tbh) but not really. The important thing to underline here is that it is more important to use the technology that fits better the user, even if it is not the most challenging, it is better to have something that works perfectly done with an “easy” technology that doesn’t look that good on your resume, than something complicated that looks “pretty” on your resume.
At the end of the day, it is way better for your career to have happy costumers, than an “impressive” CV. I mean, if you have happy costumers, they might tell their friends about you, and before you know it, you have more work and a better reputation.
2) Chances are, your biggest problem isn’t technical
It is very easy to blame the technical aspect when a project fails, buuuuuut in most cases it didn’t fail because of it, it failed because of the people that were involved in such project. Because, well, people are what make the project and if you can’t communicate with the ones that are not performing as well as the others, then your project will probably fail. Conversations are key, and that’s what I’ll talk about next.
3) Communication is king; clarity and leadership its humble servants
To have a good communication between the Software Architect and the Developers, the first thing to do is be there, with them, don’t sit on top of the tower, as if you were more than them. Next, you will need to use clarity and leadership to communicate whatever you need to communicate.
I mean, if you’re not clear no one will understand what you’re trying to say; if you don’t have good leadership then no one will believe or take you seriously; and if you have neither, well, let’s start working on getting those servants, because without them your projects will end up failing.
4) Stand up!
This one also talks about communication (what a shocker) and how important is to be heard, to stand up and say what you think, also stand up if you’re the one talking (like literally stand from your seat) so you look like you’re in charge of the situation, you’re the man (or woman) with authority with self-confidence.
So, now communication needs you to stand up, and to have clarity and leadership as servants.
5) Everything will ultimately fail
This sound very apocalyptic and like hell will break lose, but it is important to understand that software and hardware can (and most likely) fail. So you have to be prepared for the worst, you have to be prepared and have a plan in case something goes wrong. Designing for failure is being prepared for the worst, and as they say: “A prepared person is worth twice as an unprepared one”.
6) One line of working code is worth 500 of specification
While having specifications is great and all let’s be careful with how you write them, because it’s one thing what is written in paper and what can be done with code. That is why it is important to always keep in mind that the end result of the project is the product, not the specifications. It is better to have specifications that the coder can understand, rather than something so convoluted no one will get the point.
7) There is no One-SizeFits-All solution
This should be one that is pretty obvious, but sometimes people forget the importance of diversifying solutions. Trying to solve everything with the same way, the same technology, the same resources is virtually impossible. That is why you have to keep learning new ways to solve problems, or to have in your team people with diverse knowledge.
8) Commit and run is a crime
Lesson one: never commit without testing first. Lesson two: create an atmosphere where testing can be done easily and without wasting much time. Lesson three: never commit without testing first.
9) Use uncertainty as a driver
This is something that I hadn’t thought of before. We make decisions all the time, starting with what to wear that day, ending in the time we want to go to bed. For architects it is the same, the difference here is instead of choosing, we have to ask ourselves “why are we choosing?” and “how can we make the decision less significant?” Because if we can take uncertainty from the equation, things can be better solved along the way.
10) Warning: Problems in mirror may be larger than they appear
As mention before failure happens, things break, but sometimes the sign of it appear early on; but few people catch it, or no one really pays attention to it…until it is too late. That’s why there has to be an organized approach to tests, also, believe in the “bad smells” just try to find a way to back it up with tests.
11) Get the 1,000 feet view
Software quality, it is so important and yet sometimes we don’t really know how to do it. In most cases we check the source code, which is like looking at something from the ground; or at the whole project, which is like looking at something from really far up. That’s why we need a middle ground, the 1,000 feet view, so that we can see a lot, and yet be close to see details.
12) Time changes everything
Yes, time changes everything, including you. It is important to have this in mind when looking back at certain projects, because the way you think right now is not the same as the one you had last year, then years ago, and that is okay, you just have to embrace the change, because at the end: time changes everything.
13) Skyscrapers aren’t scalable
When creating any software project you can’t just do everything at once and expect it to survive in the real world. It is better to develop component by component, as if you had mini projects, that way each component will be able to survive on its own and when you add all of them, there won’t be much problem with integration.
14) Talk the talk
Everyone has its own way to communicate, that’s why Software Architects have their own, and to be able to talk their talk it is important to understand the basic concepts of software architecture and design patterns, so that when communicating with each other, both parties understand what is being said.
15) Context is king
Well, we found another king: context. The importance of this one, is that there is no one solution (as stated before), because the context of each project helps to figure out how to solve it. Not only that, but also the surroundings matter: emerging technologies, leadership strategies, etc. That’s why you have to keep all context in mind.
16) Welcome to the real world
The real world is not like the one we see during school, outside things constantly change, promises are broken, you don’t always get what you expect. In school, everything is simple, you either do something or not, pass or fail. Outside, things are different, and we have to be prepared for that, because if we’re not, then we’re in a lot of trouble.
17) Record your rationale
This may sound funny, but it is true: keep a dairy. Keep a dairy with the “whys”, “why did I chose this?”, “why am I doing this?”. Keep it close to you, and update it regularly, so in the future you can remember why the decision was made and in that way, it will help you make better decisions in the present.
18) Prepare to pick two
You can’t always have it all, and that is something that also applies to projects. It is impossible (or too expensive) to have the three aspects of CAP (consistency, availability and partition tolerance). That’s why you’ll have to choose only two, but the thing is choosing which two fit better to the project.
19) If there is only one solution, get a second opinion
It is very important to have multiple solutions to the same problem, because in that way you can see how the different solutions apply to the problem and in doing so, the product will be most likely suited to the intended purpose.
20) Shortcuts now are paid with interest later
Imagine that you’re buying something and you have the money to buy it right now, all of it. But instead of doing so, you decide to pay it every month; what you didn’t realize is that at the end of the day you’ll end up spending way more money by paying it monthly, that what you could’ve paid at once. Exactly the same happens with software, if you push things, you’ll end up doing them later, at a higher cost.
21) “Perfect” is the enemy of “good enough”
There is no such thing as absolutes, that’s why I don’t believe anything can be “perfect”. So it is important to know when your project is “good enough” so you don’t fall into the temptation of making it “perfect”. Most of the times, when trying to achieve perfection, we just get stuck again and again, never being happy with our project.
22) If you design it, you should be able to code it
Again, this is self explanatory. It is kinda obvious that you shouldn’t expect that someone does something (or uses something) that you’ve never done/used. At the end, developers are also humans, and they have learning curves, so if you have no idea what the learning curve is, you have no idea how long your developers will take in understanding what you asked them.
23) A rose by any other name will end up as a cabbage
So, in summary if you can’t put a name to what your software does, you are probably doing something wrong. When your name is vague enough, you probably don’t really know what you’re doing and that is a major warning that something is completely wrong. So, beware!
24) Take responsibility for your decisions
Decisions, we’re back to them, but this time, we’ll talk about the repercussion of decision, or well, facing those repercussions and taking responsibility. It is important to take responsibility of our actions because it helps us grow as better software architects. So, don’t be afraid to take the blame.
25) Don’t be clever
Lesson one: be dumb. Wow, those are words that I thought I would never say. But it makes sense, sometimes what you need is something really simple, so in our efforts to see everything with all of our knowledge we create something complicated, when in reality all you needed was something very very simple.
26) It will never look like that
Back to the difference between school and real world. In school, when you plan something, when you design it, the result will probably look a lot like the design; in the real world it won’t, and that is okay. So, don’t spend too much time making the design “perfect” because at the end, it will change.
27) Don’t be a problem solver
The thing is, let’s not rush to solve the problem, but take a step back and ask if the problem is really a problem, I know I sound like Ricardo Arjona, but maybe we’ve been trained for so long to solve problems, that we forget to ask wether they really are problems or not.
28) Learn a new language
By language let’s not think of English or Spanish, not even Java or C++. By language, it is the terms used by Programmers, Customers, Business, Testing. It is very important to know how they talk, so you can talk to them in the same way, in doing so, it’ll be more likely to be understood (look, communication IS king!).
29) The user acceptance problem
When creating new systems we have to consider how the public will react to such new system, even more if it replaces an already existing one. It is not as if you’ll try to have no negative reaction from the public, but you might be able to mitigate it a little bit, or reduce it. At the end of the day, you want your costumers happy.
30) The importance of Consommé
Finally, let’s talk a little bit about requirements and how refined they should be, how understandable, how many times you should spin it around and around. Because requirements are important, they mark what the programmers will end up coding, so it is important to have them clear, concise, but always remember, there’s no such thing as perfection!
Thanks for reading!