Book - 97 Things Every Software Architects Should Know

In this post I am going to share my opinions about the book I just finished to read. Till now, I simply limited myself in reporting the most interesting sentences from a book but starting from now (thanks to the constructive feedback of a friend) I decided to give more personal opinions and explaining what I really think. This is surely more difficult to do and more time consuming, but will allow me to deeply think and reflect about the books and set the stage for interesting discussions.

I am currently a software developer at the beginning of his career and I am willing to learn everything about software development and how to write better software. The role of the software architect fascinates me in some way and for some reasons is still a little bit unclear what are actually the responsibilities of one of them. Assuming this role could be a possible decision in my career so it is good to learn more about it. In addition, for personal projects like mobile applications you typically need to take architectural decisions and take care of all of the stages of the software development and the advices in the book can be useful.

Let's start to report the most interesting sentences in the book followed by my opinions.

A great software architect needs to master both sides of the architect's coin: business and technology

The fact that the software architect need to understand the business is very important and this is probably the most important reason why this is a separate role in the IT industry.

While it is important, even critical, to stay abreast of the latest trends and technologies, this should never happen at the cost of the customer. Always put the customer's long-term needs ahead of your own short-term needs and you won't go wrong.

This is a well know thing but it is always worth to remember. The need of our customers are the most important things and technology is only a way to solve a business problem.

Learning to treat people with respect, and learning give them the benefit of the doubt, is one of the core skills that turn a smart architect into an effective one.

Being able to work with people and respect them is a key element of any human being. It is always important to listen other people and be able to receive constructive feedback. This is for me a life principle and I truly believe in it. 

All too often, software architects sit in their ivory towers, dictating specifications, technology decisions, and technology direction to the developers below.

This is surely something that I don't like. As a developer, I would like to participate in discussions and contribute with feedback if I can. I like to know the "big picture", understand it. I like if architects take time (often) in discussing with developers the "big picture" because this, at least for me, help me to be more motivated and be more effective in my job.

Be sure to have a digital camera with you at all times (in order to take a picture of a whiteboard after a meeting).

This is surely something to remember and I have seen people in my company to do this. These days we always have our mobile phone in our pocket so this shouldn't be a big problem. In the future, we could have one of this 82'' LCD Multi-Touch Display in every meeting room :)

One thing most software architects fail to realize is that a software architect is also a leader. As a leader, you must gain the respect of your co-workers to work in a healthy and effective environment. Keeping developers in the dark about the big picture or why decisions were made is a clear recipe for disaster.

Same as a previous point. Everyone should know the "big picture" and surely the architect has the responsibility to simply share it.

By asking for the intended value of a requested feature or requirement, architects are able to address the real problem, and hopefully provide a better and cheaper solution than that suggested by the client. Arrange workshops and meetings where the architects focus is on customer needs - helping the customers to answer the "why" question.

One of the most important thing I learnt last year is the importance to start with why in everything you do. As an architect, you must care about the why of your customers in order to build the right solutions.

Experienced architects understand that they need to "sell" their ideas and need to communicate effectively in order to do that. Standing up automatically communicates authority and self-confidence. You command the room.

Because the architect is the bridge between business and technology there are often lots of trade off involved and the ability to communicate is key. This is an area where I need to learn a lot especially considering that I need first to master the English language.

No design is perfect from the start; all designs need to be modified as they are implemented. If you are also a developer on the project, value the time you spend writing code, and don't believe anyone who tells you it's a distraction from you work as architect.

It is important to accept that you can't design everything upfront in a perfect way. Adopting an iterative process is mandatory. In addition, a software architect is still a developer and I believe he should never stop writing code.

Commit and run is a crime because it kills flow. It's one of the most common ways for a developer to try to save time for himself, and it ends up wasting other people's time and is downright disrespectful. Why? Usually because it takes too long to build the system properly or to run the tests. Invest time in making the system fast to work with.

This is true and I have to admit happened to me sometimes. With very big projects sometimes the build time is very long and you need to do as much as you can in order to speed up the system but it is not always possible. At least, you shouldn't commit at the end of the day with the risk of breaking the build and create problems for your team.

The architect, in conjunction with development management, must create and nurture the means for regular, ongoing information feedback loops. A way is doing frequent releases of working software to the business starting early in the project.

I agree. When possible, involving the customers early and continuously in the project can be very beneficial.

A good architect should lead by example. He should be able to fulfill any of the positions within his team, from wiring the network and configuring the build process to writing the unit tests and running benchmarks. It's difficult to imagine how team members can have confidence in their architect if the architect doesn't understand the technology.

I believe that this is something theoretically true but practically extremely difficult to achieve.

"Fast" is not a requirement. Neither is "responsive". Nor "extensible". The primary reason why not is that you have no objective way to tell if they're met.

This sentence want to remember the importance of having requirements that can be measured (example: "Respond under 5 seconds").

Specifications alone have no value. The ultimate goal of a software project is a production system. A software architect must always keep an eye on this goal, and remember that design is merely a means to an end

Interesting. It seems that when you become an architect you love so much your design that you tend to consider it like the end result.

It is perfectly respectable for an architect to ask for help from the team. The team should feel it is part of the solution, but the architect should chair the discussion and identify the right solution(s).

The architect does not have to make the decision, he or she merely orchestrates the decision making process.

When I went to DevWeek 2012 I had the opportunity to discuss with a speaker (that was an senior architect) and I remember very well how much he underlined the importance of his team. As usual, it is all about trust.

Negotiating skills and a knack for influencing people can be valuable resources.

It is always good to learn more about psychology and it usually fascinate me.

Every software architect should know and understand that you can't have it all. It is virtually impossible to design an architecture that has high performance, high availability, a high level of security, and a high degree of abstraction all at the same time. There are several tools available to architects to determine what the tradeoffs should be when designing an architecture. Two popular methods are:

• Architecture Tradeoff Analysis Method (ATAM)
• Cost Benefit Analysis Method (CBAM)

I didn't know about this popular methods. Good to know.

Most software developers are optimists. Natural pessimists on development teams are often unpopular, even if they are consistently right.

I have one of my co-worker that is very defensive during programming. At the beginning I didn't understand some of his reasons but in the long term, I understood many things and he actually taught me a lot. If you want to design and develop rock solid products, you have to be a little bit paranoid (this is the word he like using), consider edge cases and test the system as much as possible. Never overlook the details!

Architects pour themselves into each design. Criticism of your creation feels like criticism of you. Defensiveness is easy. Learning to stop it is hard. Pride in our accomplishments is easy.

This is again obvious psychology. I think that it is extremely important to be able to accept constructive feedbacks and be open to suggestions.

How can we see quality? Aggregates large amounts of data and multiple metrics, such as method count, class fan out, cyclomatic complexity. Once a suitable view is available, software quality becomes a little less subjective.

Software quality is such an interesting topic and many organizations have lots to learn I think. I don't have strong knowledge about metrics but it is something I should look at more closely.

The post is getting longer than expected so I now simply share the remaining interesting quotes that are quite self-explanatory.

Accepting the fact that programming - or more precisely software development - is a processes of discovery and learning not a process of engineering and construction, is fundamental to bringing software practices forward.

As a developer you rarely get the time to sit back and really look at how the whole system fits together. AS an architect, this is your main focus. If you are doing a great job of being an architect, you really shouldn't have enough time to interfere with developers. You do need to watch closely enough to see that the design is being implemented as intended. It is reasonable to make suggestions when you see people struggling, but it's even better if you create the environment where they come and ask you for suggestions.

We say it to ourselves: keep it simple, stupid. We say it, but we don't do it. When an architect enters a project, there is an understandable desire to prove his or her worth. Showmanship, the act of appealing to your audience, is important in marketing, but it's counter-productive to leading a software development project.An architect must act in the best interests of his customer and not pander to the needs of his own ego. The simple problem-complex solution trap can be an easy on to fall into because we like to demonstrate our knowledge.

Never forget that you are playing with other people's money.

Software architecture is a craft, and it certainly takes practice and discipline to achieve success in the field.

Every time I make a decision about how a program behaves, I am really deciding what my users can and cannot do. It's not ethical to worsen the lives of others, even a small bit, just to make things easy for yourself. It's OK to release an application that only does a few things, as long as users value those things enough to pay for them. In fact, the earlier you release your application, the greater the net present value of the whole thing will be.

To be an effective software architect you must understand the basic architecture and design patterns, recognize when those patterns are being used, know when to apply the patterns, and be able to communicate to other architects and developers using them. It is also important to be aware and understand the various anti-patterns as well. Don't let your desire to exhibit design pattern knowledge could your pragmatic vision.

Sometimes the most important decisions are not about what you put in, but rather what you omit.

The architect should concede to good ideas and cultivate an atmosphere for ideas to grow. It is an open mind that will succeed in architecture. To the extent your responsibilities allow, you should do everything possible to empower your developers. Protect developers from non-essential parts of their job. Too much paperwork and too many office chores add overhead and reduce their effectiveness.

It should be made clear to you, your managers, developers, and other software stakeholders why one solution was chosen over another and what tradeoffs this entailed. Benefits:

• It forces you to be explicit about your reasoning in order to verify that your foundations are solid. 
• It can be used as a starting point to re-evaluate a decision when the conditions that influenced it have changed.

Assumptions should be visible and explicit for the sake of posterity and for future re-evaluation. It is even more critical to make sure that any assumptions that aren't based on relevant empirical evidence be validated before a decision is finalized.

The best and easiest way of working through it is to attempt to explain it to another person. We really want to share our knowledge and experience to help the industry progress; we also realize it helps us to understand and correct it.

Since over 80% of an application's life cycle is spent in maintenance, you should pay a lot of attention to the problems of support and maintenance when you're designing. Make the support lead a core part of the team. Involve a support lead with the planning for the application support. Design such that the learning curve for the support personnel is minimal. Traceability, auditing, and loggin are crucial.

Remember this: when you try to guess at future requirements, 50% of the time you're wrong and 49% of the time you're very very wrong. Get the application out the door on time and wait for feedback to generate real requirements.

Don't give in to the temptation to make your design, or your implementation, perfect! Aim for "good enough" and stop when you've achieved it.

The business is our reason for existence. Show the business domain experts the respect you expect to receive.

Don't use a pattern in your design that you haven't personally implemented before. Don't rely on a framework that you haven't coded against before. Don't use a server that you haven't configured before. If your architecture depends on design elements that you haven't personally used, there are a number of negative side effects: you won't be able to give good estimate, you will not know the pitfalls to avoid when using the elements and you will lose the confidence of your developers. When they ask questions about the design and you aren't able to give solid answers, they will quickly lose confidence in you and your design. Before anything, an architect is a developer.

Ingenuity is a key trait of successful architects. However, an equally important characteristic of the activities of a successful architect is diligence. It is an exercise in perseverance and paying the right amount of attention to each task and each architectural goal of the system.

You should not claim that an architectural decision has been made until the following two conditions are met:

• A decision has been put in writing because architectural decisions are rarely trivial. They must be substantiated and traceable.
• A decision has been communicated to the people who execute it and the people who will be affected directly or indirectly.

Clever software is expensive, hard to maintain, and brittle. Don't be clever. Be as dumb as you possibly can and still create the appropriate design.

You need to carefully select your development team and diligently protect it once assembled. Good developers are often strongly motivated by recognition. Use this fact to your advantage and acknowledge stellar performances. Finding great developers is difficult; letting people know they are valued is not. Don't miss simple chances to build morale and boost productivity.

I would like to finish with a quote from Grady Booch:

Grady Booch: "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change".

An effective architecture is one that generally reduces the significance of design decisions.