At Craft Conf, there were some presentations about software architecture. I visited all of them and also searched for this subject in other talks. It was interesting to hear the same concepts from more places and to put together a picture how software architecture looks like in the mind of the presenters of today’s conferences.
Stefan Tilkov: Architecture War Stories. It was indeed about weird stories from real life. I wrote down two things: If something is sophisticated, probable you shouldn’t do it. And having many architects is wrong. Many people liked this talk very much but I’m not really interested in real stories. I’m rather interested in the causes behind the stories to be able to avoid situations which head to weird architecture. Luckily for me, other talks were more abstract.
The title of Rachel Laycock’s talk contained the very fashionable word combination “Continuous Delivery” beside “Architecture” so I anticipated it will be great, and it was. Rachel came with the same mindset what I heard two years ago at Devoxx from Kirk Knoernschild. She used the phrase: Architecture is the stuff which hard to change. Architecture isn’t how the big parts fit together as some older sources say. She listed the five most important principles:
- Last responsible moment. - defer decisions if possible. (Managers demand a stake in the ground approach because it’s more comfortable for them but it’s in violation with modern architecture principles like ‘last responsible moment, defer decisions’.)
- Architect for evolvability - don’t try to fix everything.
- Postel’s Law, a.k.a the robustness principle: - Be conservative in what you do, be liberal in what you accept from others. In other words, code that sends commands or data to other machines (or to other programs on the same machine) should conform completely to the specifications, but code that receives input should accept non-conformant input as long as the meaning is clear.
- Architect for testability - (good design is testable)
- Conway’s Law. - The Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”. Another thought about Conway’s law from Fred Brooks (mythical man-month): “Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organisation is important to effective design.”
I’ve heard an important aspects about Continuous Delivery at other talk: Don’t use branching but use flexible runtime feature flags.
Title of Simon Brown’s talk operated with the other fashionable word “Agile”. I didn’t like this talk as much as Rachel’s one, maybe because I didn’t hear what I wanted. Simon said, that one architect should be enough in a company, or at least very few. It was said by Stefan Tilkov also, but in other articles I saw opinions about being all developers some kind of architect is the good way. I think the truth might be somewhere between. The other thing which I didn’t like the need for a proper UML diagram of the system, although, sometimes I also print a diagram for myself of the currently developed software, but it’s not necessarily standard UML and far not proper. It’s not maintained together with the code. He mentioned C4 which is also in connection with diagrams. In his definition: Architecture is the significant structure elements or architecture is the structure down until component level. Further advices were: Just enough upfront design is enough, never do Big Upfront Design. He recommended this book. I liked he mentioned that there’s something between monolithic and the very fashionable microservice architecture, it’s impossible to make it in one go, it can be implemented by a continuous transition.
In Nat and Steve’s presentation’s title there were no Architecture just SOLID. I liked very much the different kinds of pasta they showed for us, especially because we were before lunch. So, basically there is the spaghetti code which we know all, it’s the good old procedural legacy code. But OO code is all nice and clean? Well, maybe not. There is lasagne code, which is OO but it’s just layers on top of each other and you never get to the bottom. Ravioli code is also OO but you can’t get how and why the different objects and classes piled up on each other, possibly by the dependency injection framework. And there is OO spaghetti code which is made by events and event handlers and it’s similarly hard to unravel it’s behaviour like the procedural code (if not harder).
Michael Feather’s talk’s title was very specific because it contained the “Conway's Law”. He recommended to read the Leaky Abstractions from Joel. Mentioned Feature vs. Component teams. In some corporation teams may work on features or components and it’s reflected in the software itself. Further terms or recommended practices were: oscillating teams, production coverage, silent alarms, ownership.
Other very popular subjects of the conference was Continuous Delivery and Functional Programming which both have some connection with architecture. Though reactive programming and functional idioms very low-level stuff, not how the big parts fit together and not component-level design, they play an important part in architecture. So yes, I could cite some other talks where architecture was concerned but it’s time to stop here. I learnt a lot, everybody should learn a lot about it, and it’s not the last post from me about this subject.
And don’t forget, that quality means many different things, but customers are interested in functionality.