Quotes about software architecture

Interesting quotes that can inspire you as software developer or at least make you think :)

"In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers."  Ralph Johnson

"A complex system that works is invariably found to have evolved from a simple system that worked." John Gall

 "Architecture is the decisions that you wish you could get right early in a project." Ralph Johnson

"So you might end up defining architecture as things that people perceive as hard to change." Martin Fowler

"I think that one of an architect's most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs." Martin Fowler

"Complexity is what makes software hard to change. That, and duplication." Ralph Johnson

"irreversibility was one of the prime drivers of complexity" Enrico Zaninotto

"If you don’t actively fight for simplicity in software, complexity will win…and it will suck." - @HenrikJoreteg

References about Evolutionary Architectures

After my talk El arte del patadon pa'lante / Libro de recetas (Spanish) at the Pamplona Software Craftmanship 2017, some colleagues ask me about references for evolutionary architectures. This post tries to give the best references I know about this concept...

To have context for the other references, I find the following resources essential:

• Who needs an Architect? (Martin Fowler)
• Competing On The Basis Of Speed  (Mary Poppendieck)  Optimizing for speed, flow, and waste reduction. Lean Software Development

As general resources:

• Agile Architecture Keynote Molly Dishman & Martin Fowler
• Evolutionary Architecture & Micro-Services Rebecca Parsons
• Evolutionary Software Architectures Neal Ford
• Clean Architecture Robert C. Martin
• Embracing Uncertainty Dan North
• The art of destroying software Greg Young
• Lean Software Development
• Lean Principle #4 – Defer Commitment

You also need techniques to make changes to things that traditionally are "hard to change"... For this Martin Fowler bliki is a gold mine:

• https://martinfowler.com/bliki/SacrificialArchitecture.html
• https://martinfowler.com/bliki/Yagni.html
• https://martinfowler.com/bliki/ParallelChange.html
• https://martinfowler.com/bliki/BranchByAbstraction.html
• https://martinfowler.com/bliki/FeatureToggle.html
• https://martinfowler.com/books/refactoringDatabases.html
• https://martinfowler.com/articles/evodb.html

To document all the decisions you make to gain the sharing understanding of the design:

• lightweight architecture decision records

We also need a lot of tricks for our bag of tricks to have different approaches for different problems... Related with this, I think is important to have knowledge about:

• DDD mainly the strategic patterns and the bounded context concept
• Microservices (once you are a master of the monolith of course)
• CQRS
• Continuous delivery (and all the things that require)
• Reactive systems
• Enterprise integration patterns and Patterns of Enterprise Application Architecture
• ...

El arte del patadon pa'lante / Libro de recetas

Presentación preparada entre Luis Artola y yo mismo para la para la Pamplona Software Craftmanship 2017

Video

video scpna2017-el-arte-del-patadon-palante-libro-de-recetas


Muchisimas gracias a Autentia por el Video (AutentiaMedia youtube channel) (Post de Autentia con todas las charlas Pamplona-software-craftsmanship-2017)

Slides

scpna2017-el-arte-del-patadon-palante-libro-de-recetas

SCPNA2017 El arte del patadon pa'lante / libro de recetas de Eduardo Ferro Aldama

Referencias:

• CAS2016 El arte del patadon pa’lante
• CAS2016 Problemas vs Soluciones. Carlos Blé
• Real options
• Embracing Uncertainty
• The art of destroying software
• Lean Software Development

Relacionado:

• El arte del patadon pa'lante / posponer decisiones
• References about evolutionary architecture.

Construction engineering is NOT a good metaphor for software

Metaphors can be a useful way to explain complex concepts to others. They can stimulate interesting conversations and help us to expand our knowledge by drawing connections with ideas from other fields.

In the software industry, one commonly used metaphor is the idea of building software like building houses. This analogy is often used to introduce the topic to newcomers in universities.

However, in my opinion, this metaphor is not only inaccurate but also potentially harmful. Thinking about our profession as construction engineering leads us to believe that:

• There is a distinct construction phase that is separate from the maintenance phase.
• Maintenance is less expensive and longer lasting than the construction phase.
• With sufficient documentation and schematics, we can simply follow a set plan.
• There is no incremental value; construction progresses from "not done" to "done".

Even if you think this metaphor is helpful, please reconsider it.

Using the metaphor of software development as construction engineering can actually cause more problems and confusion than not using it at all.

In software development, features are considered "done" when the last customer stops using them. Maintenance is typically more expensive than the initial development of a project. There is no clear separation between the construction and maintenance phases in software development.

Software is flexible, dynamic, and constantly evolving. It requires continuous adaptation and is not a one-time construction project. The widespread adoption of agile methodologies in software development is a recognition of this reality.

Software is not delivered on CDs anymore; it is developed, grown, and runs like a living organism that evolves over time.

While it is true that there are different phases in the development of digital products and that different trade-offs must be considered, these phases are determined by evolutionary steps rather than a fixed construction plan. Change is the only constant in software development.

We can do better by seeking a more accurate metaphor for explaining what we do and how the software works. 

One potential comparison might be with the field of medicine:

• It is a knowledge-based profession
• No one wants medicine or surgery if it can be avoided
• Clean code is like eating healthy or exercising
• Pairing and code reviews are like a second opinion
• Making changes to a live system is like performing surgery on a patient while running.

While medicine may not be a perfect alternative, it is a better comparison than the original construction engineering metaphor. Construction engineering leads us to believe that the construction phase requires a significant investment, while in reality, the cost of software development is primarily in the ongoing evolution of the system.

Software is never done, it is always evolving. Software is not done until the last customer logs out and the servers are shut down.

Notes:

• Some projects have very well-defined phases, which is okay. Hopefully, we will have fewer and fewer of these types of projects each year.

Thanks:

Many thanks to @keyvanakbary for the feedback.

Interesting technical Talks/Podcasts (May 2017)

From the tech-related talks I've heard/seen lately, these are the most interesting:

• Must see for anyone interested in our profession and in real sustainable pace:
• Rafael Lopez Diez at The Lead Developer New York 2017 
• #NoEstimates  Allen Holub
• Agile Metrics - Velocity is not the goal Doc Norton

• Other interesting tech-related talks:
• lean customer development with Cindy Alvarez Ep: 512. hanselminutes podcast
• Immutability Changes Everything Pat Helland, "Accountants Don't Use Erasers"
• Demystifying DynamoDB Streams  Akshat Vig and Khawaja Shams
• why software development is an engineering discipline Glenn Vanderburg 
• SE-Radio Episode 284: John Allspaw on System Failures: Preventing, Responding, and Learning From 
• Serverless Architectures and Continuous Delivery Robin Weston
• Hexagonal Architecture meets CQRS Alistair Cockburn. lightning talk with a very good explanation about CQRS and the relation with Hexagonal architecture  (great 5mins)

"Learning & experimenting takes time, and we are always in a time crunch!" -- especially if you're not learning & experimenting ~@tottinge

— Woody Zuill (@WoodyZuill) 12 de mayo de 2017

Focus on verbs, not on names

In my experience, a good strategy to understand deeply a system or a product is:

• Focus the research and conversations on identifying behaviors (actions, verbs, business flows, and events). 
• For these behaviors, we should identify the dependencies, concurrency and parallelism requirements (what depends on what? what actions can happen at the same time? what actions don't depend on any other action? what are the sources/inputs for each action? etc). 

Understanding the concurrent behaviors, allow us to design the system using small pieces that encapsulate state and communicate using messages. A good match for OOP, Actors, Microservices, etc.
Is easy to see that this strategy try to identify the interactions that the users have with our system and the corresponding actions (verbs). It does not focus on the entities used by the system (names).
However, the most used analysis strategy try to identify the entities first, losing all the context about the behavior (messages, flows, rules, etc). This strategy derives, not necessarily, but typically, on anemic and poor models. This is a common approach for people who have misunderstood OOP/OOA.

Conclusion:

I value the process of identifying the entities (names) of a system, but I value more identifying the behaviors (verbs) that define how is used our system and what actions provide to the user.

We should remember that the customer DON'T want software/systems. The software is only a liability, not an asset. The asset is the actions provided to the customer.

Additional notes:

• This strategy can be used at different levels... It helps us to identify bounded contexts, domain events, microservices... And at the low level can also help us to see the concurrent behaviors of each application or service. This allows us to design more reactive and concurrent systems. 
• Focusing on identifying names first, make very hard to fulfill concurrency, parallelism and scalability requirements. 
• In the real world, things happen concurrently. 
• Event storming seems to be a good exercise to identify the domain events, the dependencies, and the behaviors. 
• Any strategy for the analysis should be used continuously. For me, development is always iterative, I don't see it any other way.