Juixe Techknow

Effective Java was the first book I’ve read whose table of contents had read like programming commandments. The rest of the book provided commentary and examples, but the section headers read like axioms to program by. I found a similar book in 97 Things Every Software Architect Should Know. 97 Things is a collection of 97 short essays from a number of architects on topics such as soft skills, leadership, and software architecture. The table of contents for 97 Things also reads like commandments or axioms.

97 Things Every Software Architect Should Know is a collaborate effort from numerous contributors. The project wiki is available here. Below are 101 axioms taken from the different essay titles from the project. The axioms have been rearranged from the original order provided online to provide context, and in cases edited for legibility.

• Prefer principles, axioms and analogies to opinion and taste.
• Don’t put your resume ahead of the requirements.
• Requirements are not the measure of success but the beginnings of a conversation.
• Simplify essential complexity; Minimize accidental complexity.
• Make sure the simple stuff is simple.
• Chances are your biggest problem isn’t technical.
• Warning, problems in mirror may be larger than they appear.
• Communication is king; clarity and leadership its humble servants.
• Lead by influence.
• Skyscrapers aren’t scalable.
• You’re negotiating more often than you think.
• One line of working code is worth 500 of specification.
• There is no one-size-fits-all solution.
• Commit-and-run is a serious crime. Respect your colleagues.
• Continuously integrate.
• Understand the business domain.
• Business Drives.
• Use uncertainty as a driver.
• Prioritize challenges to drive architecture decisions.
• Change is a constant; architecture needs to be adaptable and the architect needs to be a change driver.
• The user interface drives the user experience.
• For the end-user, the interface is the system.
• Architects must be hands on.
• If you’re unwilling to be hands-on, maybe you should keep your hands off.
• If you design it, you should be able to code it.
• Before anything, an architect is a developer.
• The title of software architect has only lower-case ‘a’s; deal with it.
• Architects focus is on the boundaries and interfaces.
• Software architecture has ethical consequences.
• Architecting is about balancing.
• Share your knowledge and experiences.
• Take responsibility for your decisions.
• There is no ‘I’ in architecture.
• Work on thy soft skills just as much as on your hard skills.
• An architect’s responsibility never finishes after the architecture is created.
• It’s never too early to think about performance.
• Application architecture determines application performance.
• It’s all about performance.
• Give developers autonomy.
• Value stewardship over showmanship.
• Find and retain passionate problem solvers.
• Empower developers.
• Don’t control, but observe.
• Scope is the enemy of success.
• “Perfect” is the Enemy of “Good Enough”.
• Challenge assumptions – especially your own.
• Simplicity before generality, use before reuse.
• Reuse is about people and education, not just architecture.
• Get the 1000 ft view.
• Programming is an act of design.
• No, the goal is not the code nor the design.
• Avoid scheduling failures.
• Time changes everything.
• Everything will ultimately fail.
• Context is king.
• Engineer in the white spaces.
• Choose frameworks that play well with others.
• Try before you choose.
• There can be more than one.
• Prepare to pick two.
• Heterogeneity wins.
• If there is only one solution, get a second opinion.
• One alternative is a trap, two are a dilemma, three are freedom.
• Fight repetition.
• Don’t stretch the architecture metaphors.
• Stretch key dimensions to see what breaks.
• Record your rationale.
• Start with a walking skeleton.
• It is all about the data.
• Control the data, not just the code.
• Focus on application support and maintenance.
• You have to understand hardware too.
• Your system is legacy, design for it.
• Understand the impact of change.
• Don’t make worlds, make containers for worlds.
• Great content creates great systems.
• Choose your weapons carefully, relinquish them reluctantly.
• Shortcuts now are paid back with interest later.
• Your customer is not your customer.
• Dont be clever, be delibreate and thoughtful.
• It takes diligence.
• Software doesnt really exist.
• Software should be invisible.
• It will never look like that.
• Pay down your technical debt.
• Great software is not built, it is grown.
• You can’t future-proof solutions.
• Know all the rules – so you know which ones you’re breaking.
• Design for needs, not wants.
• Consider application failures, and design for ease of recovery.
• Not all problems are solved with a layer of abstraction.