PostHole
Compose
Login
SE Radio 566: Ashley Peacock on Diagramming in Software Engineering
Ashley Peacock, author of the book Creating Software with Modern Diagramming Techniques, speaks with SE Radio host Akshay Manchale about diagrams in software engineering. They discuss the power of diagramming and some reasons we don't fully use it as often as we should. Ashley contrasts historical use of UML diagrams versus modern diagrams, which don't have hard rules about representations. The episode examines different types of diagrams through an example application and how it could be built with modern tools such as Streamy to simplify the building, versioning, and maintenance of diagrams.
Ashley Peacock, author of the book Creating Software with Modern Diagramming Techniques, speaks with SE Radio host Akshay Manchale about diagrams in software engineering. They discuss the power of diagramming and some reasons we don’t fully use it as often as we should. Ashley contrasts historical use of UML diagrams versus modern diagrams, which don’t have hard rules about representations. The episode examines different types of diagrams through an example application and how it could be built with modern tools such as Streamy to simplify the building, versioning, and maintenance of diagrams.
Show Notes
Related Episodes
- 226: Eric Evans on Domain-Driven Design at 10 Years
- 228: Software Architecture Sketches with Simon Brown
- 495: Vaughn Vernon on Strategic Monoliths and Microservices
- 539: Adam Dymitruk on Event Modeling
Links
- www.plantuml.com – open-source tool that uses textual descriptions to draw UML diagrams
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Akshay Manchale 00:00:16 Welcome to Software Engineering Radio. I’m your host, Akshay Manchale. My guest today is Ashley Peacock and we’re going to talk about diagramming and software engineering. Ashley is a staff engineer and architect working in the UK tech industry with over 10 years of experience. He has experience across the tech stack with particular focus on backend technologies. He’s an avid user of diagrams and a huge advocate for the power and conveying ideas, documenting architectures and whiteboarding problems. He’s the author of the book Creating Software with Modern Diagramming Techniques. Ashley, welcome to the show.
Ashley Peacock 00:00:48 Thank you very much for having me. Glad to be here.
Akshay Manchale 00:00:50 To get started, I want to get a sense of why you think diagramming is important in other forms of engineering. Diagramming maybe a requirement if you are a civil engineer, maybe you know, you’re adding diagrams as a requirement by law, but in software it’s not so much so that it’s required. It’s nice to have, but I know you’re a huge advocate for diagramming. So why do you think it’s important and why don’t we use it more often?
Ashley Peacock 00:01:18 I think the power from a diagram comes from the ease with which it can make information digestible. So I’m sure you’ve experienced someone sends you a document to read and you’ve opened it up and it’s just a huge like wall of text and the chances are you either left in the tab and thought, I’ll read that later because you don’t want to read it or you read it and you skim read it, you don’t read it properly. But it can just be really hard to digest, just a wall of text or if you’re a conference there’s a reason that you have slides for a conference speaker. It’s because there’s something on the screen for you to read. Something you can digest that’s easy for you to digest. Now if you talk about software engineering, documenting your architecture or explaining something to someone with some sort of visual diagram that can really help them to understand the problem, understand your architecture, that kind of stuff.
Ashley Peacock 00:02:12 In the company that I work for, it’s got to the point now where, I hate to use the word famous but like I’m slightly famous within the company that I work for, for diagramming to the point that people find it so useful and so much easier to understand problems and information. I would go to meetings, there wouldn’t be my meetings and they would be like, oh I’m sure Ashley’s got a diagram that can explain this to us. And obviously I did not have a diagram available to them because it wasn’t my meeting. But it kind of shows the point of they weren’t necessarily used to diagrams but once they saw the power in them they were kind of, they were much more open to them. And another example, my CTO at the time, he kind of shouted out one of the diagrams I used because he wanted people to use diagrams. He’d seen the power of diagrams and I’d create a rather large system design kind of architecture document. And it really kind of pushed my career forward because I was able to express myself through diagrams, my ideas, my proposals and I can make them digestible for anyone that wanted to read those documents.
Akshay Manchale 00:03:11 Yeah, you make a great point that it’s good for communicating ideas and I think it makes it easier for the readers. From a writerís perspective, at what points do you use diagrams in general software engineering life cycles?
Ashley Peacock 00:03:25 So I split diagrams into two types of diagram, I call them kind of short-lived diagrams. The more ad hoc and long-lived diagrams that you want to typically commit along with your source code. So the short-lived ones are used during a brainstorming session or during pairing to help explain something to someone. So if we are pairing together and I’m trying to explain to you the problem we’re trying to solve or a piece of code for example, I can just quickly whip up a diagram to help explain that. If you’re not quite understanding what I’m saying with my words, I can try with a visual approach instead. It’s not always required, it’s more, it’s something you can reach for like an extra tool in your tool set that you can help explain things to others easily. And the long-lived side is a stuff you put along with your source code in your repository and that will be things like your architecture. So anyone who wants to understand about a given systemís architecture, there should be a place they can go, they can read that document and understand at a glance rather than reading a whole a huge rule of text or relying on asking someone who’s got information in their brain they can just go read it. That’s a really common one.
Akshay Manchale 00:04:35 I want to get a sense of why you think people don’t use it more often. There’s a clear usefulness to it when you are the reader and you’re the consumer for any sort of software architecture that’s represented in the diagram makes it simpler, easier to understand but we don’t really use it as often. So what’s the friction here?
Ashley Peacock 00:04:54 I think there’s a few different factors that go into this one. I think some of it is there are older technologies or older standards, one of them being UML which stands for the Unified Modeling Language. It was kind of traced in the nineties as a way to standardize creating software diagrams. And I think it’s kind of got a bad reputation. They made some maybe choice decisions. I think they tried to make it almost too standard and or too restrictive. They want things done in a certain way rather than focusing on the power the diagram could bring. They’re focused on the notation for example, which is not so important. So I think people have got used to hearing from someone oh, old it’s not good anymore or they’ve had, someone’s had a bad experience with it and it kind of almost like Chinese whispers of this thing is not valuable because someone they’ve heard someone who doesn’t like this thing.
[...]