Software Architecture Principles From 5 Leading Experts

I think that on the whole we software developers don't talk enough about software design which is rather strange really because ultimately that's what it is that we do for a living software development is about an awful lot more than merely translating a detailed set of instructions in English or another human natural language into a detailed set of instructions in code software design is what makes it more so what extra is it that we need to add and how do we begin to approach this problem that is so difficult that we barely seem to be able to talk about it sensibly at all let alone focus on it as the core of our [Music] profession hi I'm Dave Farley of continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and if you enjoy the content here today hit like as well where are are the boundaries between software architecture design and code and why is design so often left out of the conversation it seems to me that I've spent pretty much the whole of my career focusing on and agonizing over the design of software systems at all different levels of detail sometimes at the level of whole massive systems but more often at the scale of a few lines of code that are currently my focus right in front of me yet we don't seem to be able to do a great job of talking about the ideas that matter in these contexts I talk about modularity cohesion separation of concerns abstraction and coupling Bob Martin talks about solid Kent Beck talks about yagy and tidy first we have design patterns Simon Brown has the C4 model for software architecture Eric Evans has domain driven design we have lists of admonitions like tell don't ask or don't repeat yourself but we've added over the years but often quite a lot of the code that I see has little sense of design at all really I think that all of us that talk about design are trying to address much the same problems we're trying to find better ways to express what software design is really all about what it's for fundamentally mostly though it seems as an industry we'd much rather argue over whether object Orient is worse than functional or whether the Ides are better than text editors just in case you're wondering no it's not and yes they are let me pause there and say thank you to our sponsors we are extremely fortunate to be sponsored by eal experts tricentis and transic all these companies offer products and services that are very well aligned with the topics that we discuss on this channel here every week so if you're looking for excellence in continuous delivery and software engineering in general click on the links in the description below and do check them out the problem is that software design is difficult to talk about it's a lot like writers talking about writing we can have a naive narrow interpretation of writing in the sense of adding characters or words the literal Act of encoding symbols I think that this is analogous to what many people mean when they talk about coding it's not what I usually mean when I talk about coding or writing though there's another way to interpret these words they represent the creation of some sort of sense symbols organized with some meaning the crystallization of my ideas in the form of words or code but it is their meaning and their utility that really matters not the symbols themselves so I can write words or code and if I'm bad at it or if I don't try hard enough these convey little or no meaning to the reader or if I'm good at it they may make my meaning absolutely plain to the reader spelling and grammar Checkers are the writing equivalent of our compilers and interpreters they don't say anything about meaning they only report on the basics of syntax really they aren't going to tell me whether or not my writing is useful or entertaining or meaningful to the reader so stretch my analogy further if design is the equivalent to this act of writing in the broader sense of conveying meaning that means that design like writing is in addition to and much more important than only laying out the correct s syntax or spelling nevertheless I'd say that coding is design in the same way that writing other than the basics of inscribing symbols is uh writing writing also so suffers from similar problems to software design it's quite difficult to teach people to write or to design well some people seem naturally better at it than others and some seem not even to see the basics very clearly I think it's unlikely that only the naturally talented can succeed though so I assume that we haven't really found the best ways to teach these things yet another problem is that every writer or software designer thinks that they're great at it in addition software also adds several problems that make it harder still to do well it has to work in text I can write all kinds of rubbish uh and you can still read it even if it isn't syntactically correct or spelled correctly or have correct grammar but software has two consumers us the primary consumers who need to read and understand the code and a computer which will process it however messy and poorly designed so software needs to be functionally correct as well as readable in the way that conveys real meaning to human beings and so allows us to continue working on it as developers we don't consume software in the same way that we consume writing so when someone says good software is readable what does that really mean well I agree entirely that readability is vital I'm pretty sure that we often interpret readability in different ways when we talk about software design in this way do we mean readable for writing or do we mean readable for software do we just mean syntactically correct in the software when I say aim for readability I mean readable as text ideally a non-technical reader can infer what the software is doing even if they miss may miss some of the nuance and details now this isn't a good guideline for every piece of software sometimes it makes sense for the code to be uh more Cod like but I think that a good guideline for good design is that my my code is as expressive as I can make it and the ultimate in expressivity is that a non-technical person can read it and this means that even a poorly skilled technical person can read it too and gather meaning and an expert expert can read it with almost no effort at all this is my real goal I like my software and my writing to be easy to read of course this is subjective this is at some level a matter of taste but for example I'd prefer this to this I'm certainly stretching my definition of readable by non-technical people a little bit with these examples but I think that they could get the gist if only I explained what rendered mean in the in the context of this piece of code my point here is that the structural parts are kept simple and the words I've chosen are descriptive the other part of good design that seems absolutely fundamental to me is that good design maintains our ability to change the code this is true at all scales and for all Technologies the technical quality of our system is defined by one thing our ability to change it so we have two ideas that characterize good design here understandability and how easy it is then to change the code fundamentally I'd argue that understandability readability only matter to the degree that they're important to our ability to change the code but for the purposes of today let's stick to these two ideas as the principles that we're trying to strive for both of these ideas are fractal they operate at all levels and scales of the system readable for the architecture of a planet spanning distributed system will take on a different meaning but the goals and actually mostly the techniques are still fundamentally the same we'd like to be able to find related Concepts that change together easily so that when we need to change things how we change them is easily fit into fits into our heads so that if we need to increase the capacity of the system in in some way all of the things that are related to increasing the capacity we are interested in are in roughly the same place or at least close together in the code this is cohesion when we change these things we'd like to be confident that now our system has more capacity that hasn't stopped us being able to sell things or that the planes that the system controls don't fall out of the sky that's about modularity and separation of concerns when we wanted to be able to locate the those cohesive values that allowed us to increase the capacity of the system we'd also like to have a way of find them EAS easily that doesn't rely on us having to have have perfect memory of every piece of code in the system so our system will be better if we adopt some conventions or consistency in terms of naming and maybe structure we need a model for how we are going to organize things that helps us when we have no idea what the thing that we need right now is called oh it's available on the admin bus and it's part of the dynamic config service try searching for capacity dynamic dynamic config or just go to the dynamic config surface and take a look either will work this is about abstraction and another form of readability the the use of naming conventions but these are the same ideas really that we use at the small scale in our day-to-day coding at this larger scale read ability starts to take on a slightly more abstract meaning but our writing analogy still stands here too in books we have chapters sentences paragraphs indexes and so on these are tools to help us navigate the book a different level of abstraction to when we're actually reading in software we have Services layers components and naming conventions that are all to do with helping us to navigate around a now much bigger and more complex space these are the tools that we use to provide a higher level of structure to the systems that we build allowing us not only to find our way around but also to communicate Roots around the system to other people I've long thought that the sign of a well-designed system and a good team is that if you ask any team member to add a new feature they will answer with very similar Solutions because the system has some structure there's a natural home for each feature a big picture model for how the system works that the team all understand and rely on to help their decision- making as well as um keeping the system nice and readable B with bite-sized sentences of code there are lots of systems and teams that can't pass this test but the good ones do this gets us up to the last level of what I think of as the reading ability of a system I want my systems to be easy to understand at this level too I think that this is mostly about the stories that we're able to tell about our system to describe it I've mentioned several times before on on this channel that I like to use something that I call a whiteboard model of the system the aim is to visualize that shared understanding so that any member of the team certainly any senior member of the team can recreate the Whiteboard model on a whiteboard from memory that puts a cap on the level of detail that can be in this model and that's important we want these things to be high level abstract these are a little bit like tourist maps of the system they they're not precisely accurate but they are correct enough to allow us to do useful work these are these work really well for me and I tend not to be too prescriptive about how you draw them whatever works is okay with me a more formal take but I think a very similar idea is in Simon brand C4 model Simon def defines four levels of diagram context containers components and code I do something similar my whiteboard models are usually mostly at the level of the containers in Simon's uh C4 model but with particularly interesting parts of the component model being called out two and then there's the code this is the main whiteboard model for the elac system for from when I was there I no doubt it's changed now this is a slightly a mix of context and containers and the most interesting part of the system was how the comms between the services work so we also used this model to describe how messages were processed I used to describe these models in some detail to everybody that joined the development team and I used the first model to describe the system to anybody that was interested in how our system worked this model was also used for example to describe our architecture to The Regulators in the finance industry it was clear enough to be understood by non-developers to the extent that you could play scenarios through at this level when explaining how things worked or when envisaging how to implement even complex new features sometimes the tools of managing complexity aren't just just about code but are equally applicable at this system level too working to always keep our system easy to change forces us to think in terms of readability and allowing ourselves a bit of latitude with what we mean by readability means that we can use these principles to guide our decision making at the biggest and most complex scales of all thank you very much for watching I hope you enjoyed today's episode and if you enjoy our content in in general please do consider supporting the channel by joining our patreon community thank you again and [Music] bye-bye

Channel: Continuous Delivery

Views: 33,653

Keywords: software architecture, software design, design and architecture in software engineering, architecture in software, uncle bob, bob martin, kent beck, eric evans, simon brown, dave farley, software architecture experts, software design expert, software engineering, software development, continuous delivery

Id: SYtkbv8LNv0

Length: 15min 43sec (943 seconds)

Published: Wed Nov 08 2023