Architecture is about intent

The following video is a talk by Robert Martin “Uncle Bob”, one of the graybeards worth listening to. This video from 2011 is wide-ranging and contains a lot of brilliant advice. It’s stuff that we’ve known for a long time now, but every generation of programmers needs to re-learn these things about every 5-10 years. You usually can’t stop people from just reinventing the wheel because who wants to watch videos of or read blog posts written by old dudes, ammirite?

Ruby Midwest 2011 − Keynote: Architecture the Lost Years by Robert Martin by Robert C. Martin in 2011 (YouTube)

At 10:00, he talks about how the top-level architecture of most applications reflects the framework used to implement the web-delivery mechanism rather than the purpose of the application itself. In his example, he shows how a Ruby-on-Rails application is immediately recognizable as such, but that you have literally no idea what the application does.

He urges us to consider what this implies about our priorities as architects and developers. It means that we are much more concerned with the technology than with the functionality. This is not good.

He contrasts it with a high-level. 2-d blueprint of the first floor of a church, where the intent is obvious: it’s a church (he says). Of course, inferring that it’s a church involves applying the appearance of the diagram to a given context—e.g., a very western one—but the point is clear: the standard, top-level view of the design of a church screams out that it’s a church. It says nothing about how the church is to be built—or has been built—it says what it is.

“Architecture is about intent.”

Just to be clear: this presentation is from 12 years ago, and we’re still confronted with the same concepts—still confronted with the same failure to remember these precepts. Our frameworks still push themselves to the fore.

This is, in a way, the problem with LLM-generated code: we are already terrible at expressing the intent of our software in a way that makes it maintainable and qualitative. We are already mostly terrible at designing and building things in a way that satisfy the nearly-always-implicit non-functional requirements, like maintainability, usability, performance, etc.

And now we’re asking another piece of software, whose workings we can’t yet fathom, but which we know we’ve built by feeding it all of these terrible versions of software, and asking it to write software for us. All of the theory that we’ve developed about how to build software will not be respected, except by luck, if the neural net is feeling like that’s a high-probability next token.

On the one hand, I have to admit that this doesn’t sound much different from how software is built today, except that the human builders are potentially capable of following rules, whereas the software-based builders are less trainable. Again, though, we have decades of experience showing that, while people are ostensibly trainable, they are not necessarily practically trainable, at least in the general case for the general type of person who takes part in this field of endeavor we call programming.

Which leaves us with the question: have we achieved the maximum potential in software development? We already knew everything we needed to know about how to do it decades ago. What is missing is the will to do it that way. It’s definitely possible to train people to do it that way. The hangup is, as always, the cost, specifically, the cost-benefit ratio. The perceived benefit of better software is usually far less than the perceived (initial) cost.

And we always perceive only the initial cost because we are super-bad at long-term thinking about complex problems like building software.

At 34:00, Uncle Bob says

“There’s gotta be some better way to do this. […] This is just 3270 programming poisoned with all sorts of crud. How many languages do you have to do know to write a web application? Well, there’s some programming language, but that’s incidental! You’ve gotta know HTML and CSS and JS and Zazzle and Dazzle and … and, you know, the guy over here’s going: ‘let’s build communities by leveling people up. Leveling them up! I mean, what we’re going to do is hand them a … OK, now, hold this hammer. Ok? Good. You got that hammer? Now, here’s another one. Hold that hammer too. Now I’ve got a big barrel you’ve got to hold on your head. We are not helping our cause with this truly terrible mechanism that we have adopted.”

At 41:00, he says

“The database is a detail.”

This reminds me of The UI is an afterthought, a detail, an article I wrote recently[1] about a 7-year-old video I watched that expressed the same sentiments about external systems that Martin is expressing in his 12-year-old video.

“That’s what architecture is: find some place to draw a line and then make sure every dependency that crosses that line goes in the same direction.”

At 55:45, he says,

“There’s an interesting case of the database—the thing that’s so incredibly important—and yet, we took that decision and we just deferred it off the end of the world and then, when somebody needed it, we shimmed it in in a day. Because our architecture had done something right. What is the hallmark of a really good architecture? A good architecture allows major decisions to be deferred.”

“A good architecture maximizes the number of decisions not made.”

At 1:00:50, he says,

“How do you keep the beast under control? You need a suite of tests you trust with your life. You must never look at that suite of tests and think ‘you know? I don’t think I really tested everything?’ As soon as you think that, you’ve lost it. Because now you’re afraid of your code. The reason we write our tests first is so that we know, that every single line of code we wrote was because of a failing test that we wrote. So that we know that every single decision that we made is tested. So that then, we can pull up that code on our screen and say ‘Oh my God, that looks like a mess’—and clean it!…without any fear.”

Great talk. Add it to the pile of things that we know—or should know—better, but don’t.