I came across this book due to it being popular on a top 10 list somewhere.
Usually I take these "xxx you should know" or "Top 100 essential things" with a pinch of salt.
Everyone is different and everyone has an opinion. Nonetheless I wanted to read this book and see what it is about.
I’ll put the 97 things in headings and have a short summary of each.
Don’t Put Your Resume Ahead of the Requirements
Also known as Solve the problem you have, not the problem you want to have
It is suggesting a tool because it is cool and hyped instead of it being the bet for the job.
Customers being happy with your work is much more important than a new, shiny tool or paradigm.
Also you need to spend a significant amount of time finding out what the tool does and if it is suited to a job – that is always a good idea. More knowledge will let you choose the appropriate tech from a more informed standpoint.
The right solution allows for a happier team, happier customer and far less stress – allowing you more time to do more research.
Always put the customer’s long term needs first.
Simplify Essential Complexity, Diminish Accidental Complexity
Essential complexity – the difficulty of each problem.
Accidental complexity – complexity arising out of existing systems or ways of doing things, things that are suppposed to decrease essential complexity but rarely do…
Overenginnered frameworks add more complexity than they relieve
Developers are drawn to complexity like moths to a flame…
People are your biggest problem
Most projects are built by people, and those people are the foundation for success and failure
You need conversation – treat people with respect and give them the benefit of the doubt. It should work both ways.
Remember conversations, not confrontations.
Communication is king, clarity and leadership – it’s humble servants
Clarity – how you communicate. No one on your team is going to read a 100-page architecture decisions document.
Being clear and concise in the way you communicate your ideas is vital to the success of any software project.
Being unclear and verbose is a huge smell.
Keep things as simple as possible – starting with a long word document is another huge smell.
Application architecture, determines application performance
Switching software vendors rarely solves applicatoin performance issues
Seek the value in Requested Capabilities
The customer or end user shouldn’t think up the solution. They should tell you the problem.
Ask for the intended value.
Collaboration – ask why?
Stand Up
You need to sell your ideas and communicate effectively to do that.
When more than one person is coming for advice – stand up – it communicates authority and self-confidence.
Slow down when making important points.
Everything will Ultimately Fail
No automated system can respond to the same range of situations that a human can
One line of code is worth 500 of specification
Unfortunately it’s far too easy to get wrapped up in the process of design.
The ultimate goal of a software project is a production system
There is no One size fits all solution
Developers should exercise contextual sense to each problem
Make Tests Run Fast
There can be more than one
In technical domains we can force uniqueness. Very convenient for us. In business domains the inconsistent, multifaceted, fuzzy, messy world intrudes.
Why not face up to the reality of a messy world and allow multiple, incon- sistent, overlapping representations, services, solutions?
But let’s take a hint from the world of data warehousing. The schemata data marts are often (relationally) denormalized, mix imported and calculated val- ues arbitrarily, and present a very different view of the data than the underlying databases. And the sky does not fall because of the nonfunctional properties of a mart.
The ETL process sits at the boundary of two very different worlds, typically transaction versus analytical processing.
These have very different rates of update and query, very different throughput, different rates of change of design, perhaps very different volumes.
Simplicity before Generality, Use before Reuse
Most libraries, frameworks and infrastructure code is general purpose without reference to concrete applications.
This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful.
The best route to gen- erality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experi- ence rather than generality through guesswork.
When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intri- cate one that boasts of generality
Although well meant, many things that are designed just to be general pur- pose often end up satisfying no purpose
People do not on the whole pay for (or need) generality: they tend to have a specific situation, and it is a solution to that specific situation that has value
We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overbur- dened (not just overloaded) parameter lists, long-winded interfaces, and not- quite-right abstractions. In pursuit of arbitrary flexibility, you can often lose valuable properties—accidental or intended—of alternative, simpler designs
Don’t Ever Rush, Don’t ever panic
Rushing is cutting corners
Panicing is lack of clear though
Both do not achieve anything in the short or long term
Database as a Fortress
User interfaces, business and application logic, and even employees will come and go, but your data lasts forever
Consequently, enough cannot be said about the importance of building a solid data model from Day One.
While business rules and user interfaces do evolve rapidly, the structures and relationships within the data you collect often do not
It is critical to have your data model defined right from the start
Normalising your data
The database is the final gatekeeper of your precious data
Warning: Problems in Mirror May Be Larger Than They Appear
- Individuals often face resistance when the rest of the team does not share their experience or knowledge. Overcoming this resistance requires unusual courage, confidence, and persuasiveness. It rarely happens, even with highly paid, experienced consultants specifically hired to help avoid such problems.
- Most software developers are optimists. Painful experience teaches us to temper our optimism, but without specific experience we tend toward optimism. Natural pessimists on development teams are often unpopular, even if they are consistently right.
- Every team member has a different view of what is more or less important. Their concerns are often focused on their personal responsibilities, not the project’s goals.
Reuse Is About People and Education, Not Just Architecture
The truth is that even the most beautiful, elegant, and reusable architecture, framework, or system will only be reused by people who:
- Know it’s There
- Know How to use it
- Are Convinced That it’s Better Than doing it Themselves
There Is No ‘I’ in Architecture
Our egos can be our own worst enemy
people who:
- think they understand the requirements better than the customers
- view developers as resources hired to implement their ideas
- get defensive when their ideas are challenged or ignore the ideas of others?
How to avoid it:
- requirements don’t lie
- focus on the team
- check your work, understand others opinions and ideas
Try before Choosing
Creating an application involved making decisions.
Decisions shouldn’t be made from an ivory tower
Delay commitment until the last responsible moment; that is, the moment at which, if the team does not make a decision, it is made for them
I like this…
the later a deci- sion is made, the more information is available on which to base the decision
Understand the Business Domain
Know why a system is needed and how money is made from it.
Insurance lends more to a service oriented approach. FInancial markets are more workflow based.
Programming is an act of Design
software development—is a processes of discovery and learning, not a process of engineering and construction
Give Developers Autonomy
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. While developers are furiously building classes, methods, tests, user interfaces, and databases, you should be making sure that all those pieces work well together.
If you’re doing a great job of being an architect, you really shouldn’t have enough time to interfere with developers
Time Changes Everything
- Pick a Worthy Challenge
- Keep it Simple
- Be Happy with Old Stuff
Software Architect isn’t an Architect
We are not building buildings.
Software architecture is a craft, and it certainly takes practice and discipline to achieve success in the field
Practitioners of software development enjoy considerable compensation for work that is highly creative and exploratory
Scope is the Enemy of Success
Expanding scope is the enemy of success because the probability of failure grows faster than expected
What to do:
- Understand the real need
- Divide and conquer
- Prioritize
- Deliver results as soon as possible
Value Stewardship over Showmanship
There is a desire to prove one’s worth – so you debazzle and baffle the team with your technical brilliance.
This showmanship is counter productive to leading a software development project – architects must win over their team with solid architectural decisions and understanding the environment.
Stewardship is taking responsibility and ownership of a project.
Heterogeniety Wins
Heterogeneous develop- ment affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible
Context is king, and simplicity its humble servant.
For example they needed to choose a database for a tank – all databases achieved more than enough throughput for the systems on the tank.
However the firing of the gun cause an electromagnetic pulse that crashed the DB – so recovery time became the important criteria to base the choice on.
Dwarves, Elves, Wizards and Kings
- Dwarves – hard workers – steadily producing artifacts in their cave
- Elves – elegant, cultured creating beautiful and magical things
- Wizards – immensely powerful and know magic
The architect is the king – must be familiar with the characters and architectures.
A good king will lead through many types of quests.
Architects’ Focus Is on the Boundaries and Interfaces
Divide and conquer – seperation of concerns…
The hard part is finding the natural place to locate boundaries.
With a bondary context map we can see what belongs together and what belongs apart.
Empower Developers
As an architect you should enable developers.
Make sure developers have the tools they need – tools should not be imposed on developers.
Repetitive and mindless tasks should be automated.
Developers should have top notch machines, access and speed to get things done.
If training is required – books etc. make sure they get it.
Record your Rationale
One type of documentation that ages well, doesn’t require much effort, and almost always pays off is a record of the rationale behind decisions that are made regarding the software architecture
Why? Why are you using this tech – what is the reason for this project?
What Assumptions are made?
Quality, time, cost and feature tradeoff.
For example you might choose grafana instead of kibana as it is not locked down to a single datasource (elastic) and has users and orgs in the open source version unlike kibana that you have to pay.
Challenge your assumptions
How often is it that assumptions are made up in your own mind – not backed by any evidence.
Just historical reasons cited.
Quesiton these assumptions…they may not be true.
Share your Knowledge and Experiences
We learn a great deal from success and failure.
Disseminating this experience and knowledge is vital in helping sustain progress.
Pattern Pathology
Design patterns are excellent tools for mitigating necessary complexity, but like all tools, they can be misused
Don’t become imfatuated by them – stamping patterns all over a project usually means overengineering.
Don’t let your desire to exhibit design pattern knowledge cloud your pragmatic vision
It’s our job to identify problems solved by these solutions when they arise and apply design patterns appropriately
As always…be pragmatic.
I don’t think I can name a signle design pattern…they might even be a smell when someone mentions them…
Focus on Application Support and Maintenance
- There is no debugging in production
- Log levels are lower in production
- The CEO is now aware of the bug – mroe pressure
The relationship between developers and support should be good – most problems require a developer.
Make the support lead a core part of the dev team
Prefer prinicples, axioms and analogies over opinion and taste
Start with a walking skeleton
A minimal end-to-end implementation of the system that links together the main architectural components
Its all about the Data
If you stand back a little, a computer is nothing more than a fancy tool to help you access and manipulate piles of data
Data cuts through the crap
Make Sure the Simple Stuff is Simple
Thinking you are smart – and being clever.
Very bad smells.
Before Anything, an Architect Is a Developer
Perfect is the Enemy of Good Enough
My advice: don’t give in to the temptation to make your design, or your imple- mentation, perfect! Aim for “good enough” and stop when you’ve achieved it.
Avoid "Good Ideas"
The really insidious thing about “good ideas” is that they are “good.” Every- one can recognize and reject “bad” ideas out of hand—it’s the good ones that slip through and cause trouble with scope, complexity, and sheer wasted effort incorporating something into the application that isn’t necessary to meet the business need.
The Business vs the Angry Architect
At this point we can draw on our experience to provide many solutions quickly, leaving more time to enjoy the challenging issues. We’re confident in our solutions and we deliver as adver- tised. We have reached homeostasis. This is the perfect time to make a colossal mistake—like deciding you know so much that it’s time for you to start talking more than you listen
You aren’t bigger thant he business – the business is our reason for existence
We live to serve the business.
Remember, when you’re talking you can only hear something you already know. Don’t ever start thinking you’re so smart that no one else has something valuable to say.
Don’t allow yourself to become a disgruntled genius who spends all of his time try- ing to impress others by making witty, condescending statements about how poorly the company is run. They won’t be impressed.
Stable Problems get Higher-quality Solutions
Real world programming is not solving the problem someone gives you, in the real world the best architects work around the hard problem – and find simpler solutions.
The skill is drawing boundaries so that problems are stable and self contained
Seperating into smaller chunks
What is interesting is that if the problem is stable, then when it is solved, it is solved permanently
It takes Diligence
An architect’s job is usually charactierised by ingenuity and problem solving
However an equally important characteristic is Diligence
Take Responsibility for your Decisions
- Decisions should be substantiated and traceable
- Decision has been communicated to people who are affected by it
Don’t be Clever
general intelligence, resourcefulness, thoughtfulness, a breadth and depth of knowledge, and an affinity for precision are laudable qualities in anyone, and particularly prized in architects
"cleverness " implies the ability to quickly get out of a jam but ultimately rests on a gimmick, a shell game or a switcheroo.
Clever software is expensive to maintain and brittle.
Cleverness should never be required, if it is then you haven’t sovled the problem simply.
Cleverness is tricking software into working.
In simple solutions – one component does one thing.
Your customer is not your customer
In a software requirements meeting the customer you are serving momentarily is not your customer.
Your real customer is you customer’s customer.
If you customer’s customer win, your customer wins
It will never look like that
A detailed design can fool you into thinking you have everything covered.
Planning is guessing.
The truth is no matter how in depth the design is – it will never come out how it is imagined in your head.
Minor changes and external factors add up and it never turns out the way it was designed
Choose Frameworks that play well with others
Think about how easily a framework can adapt, change and update as the system evolves.
A system should be designed with mutually exclusive frameworks.
Make a Strong Business Case
- Establish the value proposition – executive summary – how it improves the business
- Build metrics to quantify
- Link back to traditional business measures
- Know where to stop
- FInd the right timing
Control the data not just the code
You need to be able to build the entire application, including the data- base, as one unit
Pay Down your Technical Debt
Do it right or take shortcuts.
Generally business people (sales, marketing and customers) will want the change made as quickly as possible.
Where developers and tested are more concerned with doing things properly.
Technical debt is in the form of system instability and increased maintenance due to no tests or documentation and shortcuts being taken.
Don’t be a Problem Solver
Developers get rewarded for solving programming problems, which are more local in scope than architectural problems
Finding problems and solving them architeturally is what gets you the big bucks and provides the most value
Sometimes the best solution is no solution – it is too easy to jump into problem solving mode – it is how we are conditioned.
Most problems don’t need to be solved at all – they just appear as problems when looking at the symptoms.
We should interrogate the problem itself – not just jump into problem solving mode.
Understand the problem and the context and the value that will be added or removed by solving it.
The Ultimate Tool is the Invisible One
A tool that doesn’t even feel like it is a tool – it is just part of the job
Find and Retain Passionate Problem Solvers
FInd problem-solving skills and passion – deep technical parts are not as relevant.
Asking someone about the process of diagnosing performance issues gives much better insight.
Keep developers motivated and keen.
Beware of negative reinforcement.
Learn a New Language
If you are a programmer – learn the business and testing languages.
It facilitates communication and helps the business do things more effectively
You can’t future-proof solutions
Solve the problem you have, not the problme you want
No one can predict the future – planning is guessing.
Accpet the fact and release yourself from the burden of the future.
Too much analysis and design also has this problem
The User Acceptance Problem
- People don’t like change. There may be a negative reaction.
- People have a fear of losing functionality, influence or power
- People fear unproven tech
- People have cost and budget concerns
Start early and engage with end users.
Consomme – Refine problems and thoughts
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
Many missed requirements and bugs in software can be traced to ambigu- ous, general language
Focus on what can be removed
For the End User, the Interface is the System
There are too many good products hidden behind bad user interfaces
Great Software is Built not Grown
Start small – the bigger the size at the start the more likely it is to fail.
Design small upfront.
More chance of being untestable and fragile.
Give the system a chance to grow – forget the massive spec ast the start.
Think minimal – think smaller.