About

This series of article threads start off the discussion using "Clean Architecture: A Craftsman's Guide To Software Structure And Design", by Robert C Martin, with contributions by James Grenning and Simon Brown.

Architecture Appeal

The appeal behind Architecture is simply about structure.

Why structure?

Structure permeates and dominates the paradigms of Software Development. It encompasses complex topics for discussion over,

• Components
• Classes
• Functions
• Modules
• Layers
• Services (Micro/Macro)

Too many software systems all into a grotesque structure, where many aspects are beyond belief or understanding. In many ways, we do not think of building Software Architecture as our intuition goes when it comes to building structure does.

Building Architecture & Software Architecture

Buildings exist physically, in stone or concrete, with arches that are either high or wide, large or small, mundane or fascinating. There is the constraint of gravity and the materials used.

But how is software architecture analogous to building architecture? In many ways, it's hard to define as such.

Buildings have stone, bricks, wood, iron, metal alloys, glass.

But what does Software Architecture have? More software components, which are made of further software components, which are made of more software components ... you get the idea. Software is recursive and fractal in nature. We can't talk about physicality in software, but it can be helpful to talk about interlocking contributing to components helping each other.

Can we thus argue that there is more architecture depth of design in software in building, in a virtual setting than a physical setting? To not have something in front of your eyes, but to still think in components, boxes, and interlocking mechanisms.

Talking About Architecture

We humans crave something to be in-front of us physically so we can understand it better.

Although appealing and visually obvious, the boxes on a PowerPoint diagram are not a software system's architecture.

It's not doubt they represent a particular view of an architecture, but they do not represent the entire big picture.

Software Architecture may not look like anything.

A visualization is a choice, but not always a given. It is decided on a further set of choices: what to include, what to exclude; what to emphasize by shape or color; what to de-emphasize through uniformity or omissions. There is nothing natural or intrinsic about one view or another.

As for the physical constraints, there is definitely discussion around,

1. Processor Speed
2. Network Bandwidth
3. Memory
4. Storage

Physical World Constraints

In the real world, our companies and our economics live. This is another calibration where we can put our architecture on. Less physical forces and quantities through which we can talk and reason,

Architecture represents the significant design decisions that shape a system where significant is measured by cost of change - Grady Booch

Grady Booch is an American software engineer, best known for developing the Unified Modeling Language with Ivar Jacobson and James Rumbaugh. He is recognized internationally for his innovative work in software architecture, software engineering, and collaborative development environments

Time, Money, Effort

Time, money, and effort gives us a sense of scale to sort between the large and small, to distinguish the architecture stuff from the rest.

Good architecture not only meets the needs of its users, developers, and owners at a given point in time, but it also meets them over time.

If you think good architecture is expensive, try bad architecture - Brian Foote, Joseph Yoder

Typical Changes

Changes made to a system typically should not be something that is costly, hard to make, turn into complete managed projects, but should folded into daily and weekly flow of work.

How do we know what those typical changes will be so that we can shape those significant decisions around them?

How do we reduce future development effort and cost without crystal balls and time machines?

Architecture is the decisions that you wish you could get right early in a project, but that you are not necessarily more likely to get them right than any other - Ralph Johnson

The Darkest Path

Because predicting the future is non-trivial, the darkest path comes from the idea that strong and stable architecture comes from authority and rigidity.

If change is expensive, change is eliminated - its causes subdued or headed off into a bureaucratic ditch. Its mandate is total and totalitarian, with the architecture becoming a dystopia for its developers and a constant source of frustration for all.

Speculative Generality

There is a strong element of Speculative Generality. A route filled with hard-coded guesswork, countless parameters, tombs of dead code, and more accidental complexity than you can shake a maintenance budget at.

The Cleanest Path

The Cleanest Path recognizes that we operate with incomplete knowledge, but it also understands that, as humans, operating with incomplete knowledge is something we do, something we're good at.

We create things and we discover things. We ask questions and we run experiments. A good architecture comes from understanding it more as a journey than as a destination, more as an ongoing process of enquiry than a frozen artifact.

Architecture is a hypothesis, that needs to be proven by implementation and measurement - Tom Gilb

"Tom Gilb is an American systems engineer, consultant, and author, known for the development of software metrics, software inspection, and evolutionary processes."

This path requires care, attention, though, observation, practice, principle. This might at first sound slow, but it's all in the way that you walk.

The only way to go fast, is to go well. - Robert C. Martin

Getting Things To "Work"

You don't need specific architecture knowledge to make things work.

Young men and women in college start billion-dollar businesses based pm scrabbling together a few lines of PHP or Ruby.

Hoards of junior programmers in cube farms around the world slog through massive requirement documents held in huge issue tracking systems to get their systems to "work" by the sheer brute force of will.

Getting it right is another matter entirely. Getting software right is hard. It takes knowledge and skills that most programmers haven't acquired. It requires discipline, dedication, most programmers have not thought of.

It takes passion for the craft and the desire to be a professional.

And when software happens right, you don't need massive documents and huge issue tracking systems. You don't need cube farms and 24/7 programming.

When software is done right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between. Effort is minimized, and functionality and flexibility are maximized.

As a question, have you experienced the opposite? Have you worked on systems that are so interconnected and intricately coupled that every change, regardless of how trivial, takes weeks, and involves huge risks? Have you ever been to programming hell?