Simon Brown > Quotes

“Unlike the medieval building industry though, the software development industry lacks an explicit way for people to progress from being junior developers through to software architects. We don’t have a common apprenticeship model.”
― Simon Brown, Software Architecture for Developers: Volume 1 - Technical leadership and the balance with agility

“As a verb, architecture (i.e. the process, architecting) is about understanding what you need to build, creating a vision for building it and making the appropriate design decisions. All of this needs to be based upon requirements because requirements drive architecture.”
― Simon Brown, Software Architecture for Developers: Volume 1 - Technical leadership and the balance with agility

“a software architect who codes is a more effective and happier architect”
― Simon Brown, Software Architecture for Developers: Volume 1 - Technical leadership and the balance with agility

“You don’t need to be the best coder on the team”
― Simon Brown, Software Architecture for Developers: Volume 1 - Technical leadership and the balance with agility

“Non-functional requirements” not sounding cool isn’t a reason to neglect them.”
― Simon Brown, Software Architecture for Developers: Volume 1 - Technical leadership and the balance with agility

“Software architecture plays a pivotal role in the delivery of successful software yet it’s frustratingly neglected by many teams.”
― Simon Brown, Software Architecture for Developers: Volume 1 - Technical leadership and the balance with agility

“unlike the building industry, the software development industry lacks a standard, consistent way to think about, describe and visually communicate software architecture”
― Simon Brown, Software Architecture for Developers: Volume 2 - Visualise, document and explore your software architecture

“developers are likely to ignore your coding experience if you’re not programming on the project”
― Simon Brown, Software Architecture for Developers: Volume 1 - Technical leadership and the balance with agility

“colour coding to decipher. Can you work out what the colour coding means? Is it related to input vs output functions? Or perhaps it’s business vs infrastructure? Existing vs new? Buy vs build? Or maybe different people simply had different colour pens! Who knows.”
― Simon Brown, Software Architecture for Developers: Volume 2 - Visualise, document and explore your software architecture

“All joking aside, these diagrams do suffer from one or more of the following problems:
• Notation (e.g. colour coding, shapes, etc) is not explained or is inconsistent. • The purpose and meaning of elements is ambiguous.
• Relationships between elements are missing or ambiguous.
• Generic terms such as “business logic” are used.
• Technology choices (or options, if doing up front design) are omitted. • Levels of abstraction are mixed.
• Too much or too little detail.
• No context or a logical starting point.”
― Simon Brown, Software Architecture for Developers: Volume 2 - Visualise, document and explore your software architecture

“Any narrative should complement the diagram rather than explain it.”
― Simon Brown, Software Architecture for Developers: Volume 2 - Visualise, document and explore your software architecture

“As a noun then, architecture can be summarised as being about structure. It’s about the decomposition of a product into a collection of components/modules and interactions.”
― Simon Brown, Software Architecture for Developers: Volume 1 - Technical leadership and the balance with agility

“organisations often tend to see software architecture as a rank rather than a role too”
― Simon Brown, Software Architecture for Developers: Volume 1 - Technical leadership and the balance with agility