The essay “97 things every software architect should know” discuss what it means to be a software architecture. It is a good source for ideas on how to improve your skills as an architect or what skills you need to develop to become one.
In this post I summarize the chapters I found interesting. Currently, only some chapters from the range 65-97 are summarized.
65. Your system is legacy, design for it. – by Dave Anderson.
- you should wish your system will become legacy systems as this indicates that your system bring value to stay in production.
- design for legacy:
- Clarity – code should be clear to support teams
Testability – is your system easy to verify?
Traceability – can Ernie the Emergency bug fixer who has never seen the code before jump into production, diagnose a fault and put in a fix?
66. If there is only one solution, get a second opinion – by Timothy High
- architect should consider several solution before finding a solution and evaluate their different trade offs.
- if you can think of only one solution goes consults more experienced people.
- Watch out from patterns you already know that might block you from finding more solutions – if you are good with a hammer everything might look like a nail to you 🙂
67. Understand the impact of change – by Doug Crawford
A good architect reduces complexity, design practical abstractions
The great architect understands the impact of change
- changes includes changes in :
- team members and structure
70. “Perfect” is the Enemy of “Good Enough” – by Greg Nyberg.
Software designers, and architects in particular, tend to evaluate solutions by how elegant and optimum they are for a given problem
My advice: 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
What exactly is “good enough,”
do not impact system functionality,
do not impact system maintainability
do not impact performance in any meaningful way.
The architecture and design hangs together.
The implementation works
Code is clear, concise, and well-documented.
Could it be better? Sure, but it is good enough, so stop. Declare victory and move on to the next task.
- Remember that application development is not a beauty contest
73. The Business Vs. The Angry Architect – By Chad LaVigne
- you need to listen what other people say to you and not concentrate only on what you have to say. you already know what you are going to say – so you might learn something new from listen to others. This is especially true for architects that are experienced and might think they know what is the next step for any situation.
- The business is your employer – you need to serve it. The business domain experts are your major partners – listen to what they have to say. if you disagree with them that is fine. learn to leave with disagreements. if there are too many and you can’t contain that – look for another business to work for and contribute your experience to its success.
75. Before anything, an architect is a developer – By Mike Brown
An architect of a project should also write code of the project. This will have several benefits:
- Help the architect to estimate how much time coding tasks will take his developer to complete.
- Its fun
- Keep him in sync with latest technologies updates
- His developers will appreciate him more as they will see his high quality code and that he take part of the developing effort.
77. Stable problems get high quality solutions – By Sam Gardiner
- An architect should be able to look at a problem and separate it to chunk of problems that are cohesive and decoupled.
- The splitting to chunks should be driven to create chunks that are stable i.e., chunks the do not change even if other chunks are changed.
- When a problem is stable it cause its design to be stable, when the design is stable – the implementation can be made stable with high quality.
- An architect should develop internal sense for separation that is similar to a good sense of direction that some people have.
78. It Takes Diligence – By Brian Hart
An architect is expected to have ingenuity in his work but less common characteristic is of being diligent.
Effective architects are using daily and weekly check lists to remind them do the things that are necessary but harder for them to do like tracking project status.
They use commitments as for example:
- keeping project’s schedule and budget
- complete tasks that are not fun for them
- commitment to process/methodology
- accepting overall responsibility of the project
Getting better in what you do requires diligence.
79. Take responsibility for your decisions – By Yi Zhou
Here is how you can become a responsible architect:
- each major decision need to be well documented, traceable and communicated to engineers and other stockholders so they can review and have the chance to object it.
- review your past architectual decision. Identify decision that remain valid and those that do not – figure out how you could avoid bad decisions. learn from your mistakes.
- enforce your decisions
- delegate decisions to other who are expert in a domain that you are not proficient. you are not know-it-all-genius.
80. Don’t Be a Problem Solver – By Eben Hewitt
An architect has the reflex to try and solved a given problem instead of asking themselves if this problem is a real problem? can it be avoided?
He should not accept requirements as solid. If removing some of them can have a more sustain design then he should offer that.
81. Choose your weapons carefully, relinquish them reluctantly – Chad LaVigne
- Selecting the technologies we use to attack problems with is a large part of the software architect‘s job.
- architect have a toolbox of technologies they are experienced with, They know the technologies limitations. They know how to solve problems when arise. They are able to estimate project effort accurately.
- technologies improved over time – you need to replace old technologies when new ones proved to be significantly better from the one you know.
- update technologies in your product if there is an obvious improvements to the business
88. Don’t Be Clever – By Eben Hewitt
- Good qualities an architect should have:
- General intelligence
- a breadth and depth of knowledge
- affinity for precision
- Write simple solutions not clever ones. The disadvantages of clever solutions:
- They are not simple
- Hard to fix
- Hard to replace, they stick for ever
90. Find and retain passionate problem solvers- by Chad LaVigne
Putting together a team of outstanding developers is one of the most important things you can do to ensure the success of a software project.
- Building a team
asking someone to explain their approach to diagnosing a performance problem gives you great insight into their methods for problem solving.
ask what they would change given the chance to start their most recent project anew.
Good developers are passionate about their work. Asking them about past experience will bring out that passion and tell you what correct answers to technical trivia questions cannot.
keep the team together
Finding great developers is difficult. Letting people know they are valued is not. Don‘t miss simple chances to build morale and boost productivity.
Keep criticism constructive and don‘t require that every solution look like it came from you.
go the extra mile to keep it together
92. Pay down your technical debt – By Burk Hufnagel
- A fix of bug in a production system might be needed ASAP. This means that it will probably be “quick and dirty” fix.
- such fixes have hidden cost:
- system instability
- increase maintenance cost
- lack of proper design
- lack of documentation
- lack of tests
Once the fix is in production, have the developers go back and fix it properly so that it can be included in the next scheduled release.
95. The Importance of Consommé – By Eben Hewitt
A consommé is an extremely clarified broth, usually made with beef or veal, served as a delicate soup. It is made by repeated, simple, fine-grained straining.
Software architecture requires a continual refinement of thought, a repeated straining of ideas until we have determined the essence of each requirement in the system.
97. Great software is not built, it is grown – by Bill de hÓra
resist trying to design a large complete system
Have a grand vision, but not a grand design.
starting with a small running system, a working subset of the intended architecture – the simplest thing that could possibly work.
it can teach us much about the architecture that a large system, or worse, a collection of architectural documents never can:
It will require a smaller team, which will reduce the cost of coordinating the project.
Its properties will be easier to observe.
It will be easier to deploy.
It will teach you and your team at the earliest possible moment what does and does not work.
It will tell you where the system will not evolve easily
Perhaps most important, it will be comprehensible and tangible to its stakeholders from the beginning, allowing them to grow into the overall design as well.