Season 3 Episode 2 Nov 18, 2020

Demystifying Architecture


If you're writing code, you're doing architecture


In this episode, we talk everything to do with architecture with David Whitney, independent software consultant at Electric Head Software, and author of the DEV post, "Architecture for Everyone."


Ben Halpern

Forem - Co-founder

Ben Halpern is co-founder and webmaster of DEV/Forem.

Jess Lee

Forem - Co-founder

Jess Lee is co-founder of DEV.


David Whitney

David is the founder of Electric Head Software, working as an independent software consultant based in London focusing on IT software delivery, developer mentoring and cultural change - mostly working with London-based organisations and start-ups. David is the author of the best-selling kids programming books Get Coding, and Get Coding 2, a Microsoft MVP, and a frequent conference speaker. You can get in touch by visiting:

Show Notes

Audio file size







[00:00:01] JL: Triplebyte is a job search platform that allows you to take a coding quiz for a variety of tracks to identify your strengths, improve your skills, and help you find your dream job. The service is free for engineers and Triplebyte will even cover your flights and hotels for final interviews. So go to today.


[00:00:19] RudderStack is the warehouse-first customer data platform built for devs. It is open source and built API first. So it is easily customizable and fits into your existing development processes. RudderStack’s multitude of SDKs, sources, and destinations make it easy to instrument, adjust, and route customer data from all of your digital touchpoints. Start building a better CDP for free today at




[00:00:50] DW: I realized that reading through the job spec, it was just a bunch of the worst possible jargon and language that technology could concoct.


[00:01:09] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all our lives as developers. I’m Ben Halpern, a co-founder of Forem.


[00:01:17] JL: And I’m Jess Lee, also a co-founder of Forem. Today, we’re talking about architecture for everyone with David Whitney, Independent Software Consultant at Electric Head Software. Thank you so much for joining us.


[00:01:27] DW: Thank you.


[00:01:28] BH: So David, before we get into this topic of architecture and everything you’ve written about it, can you tell us a little bit about your development background?


[00:01:36] DW: I’m an independent software consultant based out of London in the UK. And I have a background in doing kind of stereotypical, boring, big stuff. So I’ve had various potential sounding job titles, like chief technical architect and head principal engineer and all that kind of stuff. But ultimately, what I really like doing is just finding people that like building things and helping them build them better. A lot of that involves training and taking some of the maybe traditional cruft out of software architecture and design and development. It’s an interesting job and every different role I’ve done is different and that’s kind of why I love it. I wrote a couple of books about JavaScript for kids. Yeah, I kind of just love what I do and I’ve been now seemingly doing it at tremendously terrifying long time.


[00:02:26] JL: How did you get into programming to begin with?


[00:02:28] DW: When I was a child, my mother always tells the story that I needed attention a lot of the time and I think that whole thing where some things never changed. I think I discovered computers and discovered they were the thing that would always give me attention without any human input, which is kind of ironic because the thing I think is the best in technology now is the people, honestly. So I came from a random council state in Manchester in the North of England moved to Hong Kong as a kid and then this was kind of late ’80s and I was totally obsessed with the Game Boy when it first came out. Like it seemed like magic to the point where my mother used to lock it away in a cupboard in the house. So obviously, I learned how to unlock the cupboard and replace the Game Boy before she ever noticed. And it kind of started this lifelong obsession with computers, but it was really, really surreal because no one in my family really understood anything about it. So I kind of was lucky enough that I learn the long way as a teenager on the nascent internet in the ’90s. So kind of hanging out on horrible used net message boards with probably a bunch of 40-year-old dudes from Wisconsin. Honestly, I love the fact that, to me, programming is this kind of creation that we can do it. So it’s akin to arts or literature. It’s a way you can make things. And I think that kind of fun of making things never left and it’s kind of kept me writing software since, as opposed to disappearing into some nebulous management role somewhere that the fun is the doing.


[00:03:58] JL: I bet that you’re capturing a lot of that fun into the children’s books that you’re writing too. What kind of projects are you working on now?


[00:04:05] DW: Okay. So especially with 2020 being what it is, there’s some kind of bingo card there for 2020, I think in February this year, I took a break from all my professional work because I was feeling burnt out and I feel like there’s this really important thing about being authentic in the work you do. I wasn’t there. So I took a step back and thought, “You know what? I’ll do some conferences. I will travel a bit. I’ll see the world. I’d be in a different country every two weeks.” That was the 1st of February, 2020, which as far as timing goes, is possibly the worst timing I could have ever made that decision on. So what I did, when faced with the four walls of my home office, I decided to try and reconnect with all the things that got me into programming in the first place, to be honest. So I’ve been working on my third book, which is kind of about, I suppose, programming and philosophy and ethics, which is very much for adults. And I started just building things for fun. And I know that sounds like a really surreal thing to say with a background in relatively corporate software development, but I’ve built a Game Boy emulator, I wrote 3D raycasting engine in JavaScript. I hacked an exercise bike because I was stuck in my front room and I want to drive Google Maps with it, just doing all these kinds of things that you have to remember to do when you realize that not all worthwhile software comes from your day job. I think it’s very, very easy for people to get really, really bogged down, just doing the day job stuff, and really leading into that career of getting numbers from databases and painting them on webpages. You kind of forget that all this other stuff exists that uses the same skills. So for the past, I don’t know, eight months, I’ve just been building weird little browser games and anything that I thought that I couldn’t do before.


[00:05:46] BH: You wrote a popular post on dev this year titled, “Architecture for Everyone.” Can you give us the gist of this post and what the impetus was for writing it?


[00:05:55] DW: I think the background is more important than anything, really. I was sitting in a cocktail bar. It’s like the start of a very bad song. I was sitting in a cocktail bar with a friend and she was interviewing for new front-end roles and she’d seen this job spec and I’d never seen anything like it. They were asking for successful candidates to be aware of all these various architectural patterns and different languages and runtimes. And I looked at this specification and I said, “I’m not being funny, but what, to write HTML?” And she was like, “Yeah, to write HTML.” I felt really, really bad for her because I realized that reading through the job spec, it was just a bunch of the worst possible jargon and language that technology could concoct all thrown down together on a piece of paper. And obviously, there’s the revulsion inside of me, which is like, “Oh, well, these people don’t deserve people applying with writing job specs like this.” But there was also this really kind of practical, pragmatic reaction of, “God! This stuff is really scary.” And we do not make it easy for people to do well or to learn when we write job specs and articles covered in a bunch of language that basically looked like some PhD wrote it in 1930 and hasn’t really gone back and thought about since. And she was quite worked up about it at the time. I went home and I thought, “You know, I’m going to answer all of these questions.” Not because I think they’re good questions to put on a job specification on a CV, but precisely because I think they’re bad questions. And actually it’s all of the horrible gatekeepery stuff that stops people who are perfectly talented, exceptional programmers, technologists, creative thinkers for applying to things because it’s that very traditional old school gatekeepy, “Well, if you didn’t read this one book on comp sci in 1990 that’s been out of print for the last 10 years, you’re actually not good enough for these jobs.” That’s the thing I hate the most in technology. We’re way better when we actually get people from different backgrounds, with different perspectives and different opinions, and we build more interesting and more varied software. So I ended up, like, “I started at the top of these questions for the job spec and I just started writing and it was just like, “Okay, cool. People are going to ask you questions full of jargon about web applications. Let me try and explain what all that stuff is. Let me try and explain what hardware is. Let me try and explain what design patterns really are.” And all these things that people use to kind of judge other people’s competency without actually really thinking, “Is this stuff important? What are the reasons that we talk about these things? Why does someone think these things are important enough to put in a job specification?” And I kind of wanted to pull that apart a little bit, because anything that chips away at that horrible gatekeepy ivory tower of “ARCHITECTURE” is probably a good thing in my opinion, because I don’t think that’s a really pragmatic or productive way to build software. Certainly not today.


[00:08:44] BH: What is it about architecture that the concept that necessitates seemingly this ivory tower mindset?


[00:08:52] DW: Well, I think there’s a wonderful joke in the bottom of it is because architecture isn’t really a well-defined job. And I think when the job is so ill defined, there are so many different kinds of roles, both good and bad, positive and negative, that can hide under the blanket title. I’ve worked with enterprise architects who were never programmers. I’ve worked with enterprise architects that were only programs. I’ve worked with architects who were kind of systems, design, operations-style people, and all these things just kind of have the same job title and it defends those job roles from scrutiny in a way that maybe actually once you start explaining what the activities of architecture should be in a well-functioning team, they start to unravel around them.


[00:09:40] BH: So if there’s an organization with someone who’s entitled head of software engineering versus software architect or maybe principal software engineer versus software architect, et cetera, like if the architect’s job is sort of to guide the efforts, is there a major difference between a software architect and otherwise like predominantly senior folks within an organization?


[00:10:09] DW: I think there’s a little bit of like a what and a how division. There’s a simple truth that a lot of application architecture should and does happen on the front lines by tech leads or senior engineers or just programmers. Every day programmers are making architectural decisions. I think in larger organizations, I very much am a big proponent of the principle engineering model, which, to anyone that isn’t aware, is very specifically people may be individual contributors of significant technical proficiency who work horizontally across an organization to kind of try and ensure coherence. And people hear me say that, and they think it’s like a programming role, but mostly it’s a people role. It’s about communication. It’s about elevating practices from different teams. It’s about sharing knowledge. It’s about making sure things are, I think Spotify coined the term “Aligned Autonomy”. And the role of principal engineers and architects, I suppose the architects set a direction of travel and archetypes for implementation and great architecture teams will provide consumable working software. They won’t just say, “Oh, hey, everyone’s got to use messaging.” They’ll say, “Hey, we want you to use messaging for the design of this system.” And we built a library illustrating how to do it, and you can use it in your code, other devs. So that it’s all about running that little bit ahead and taking some of the friction away and more of the technical decisions, whereas the principle engineering track is more about how you do that, how do you engage with quality inside your teams, how do we take teams that maybe have specific individual pockets of technical excellence and raise their voices and their expertise across multiple teams in an organization. So I think they’re complimentary roles and they’re very, very similar, but I think the commonality in the two versus maybe where architecture was in the ’90s is I see both principal engineering and architecture today as being a collaborative effort with people working in building software. Because ultimately, if you claim to be in some kind of design role or an architecture role and you’re not on the frontline, you’re going to screw up. You’re not going to do a great job. There’s a wonderful thing I’m probably going to misquote that I read about the shooting of like the first or second Star Wars film of all things. And apparently, the Star Wars scripts are not renowned for their quality script writing. We’ll go with that. During the filming of one of the Star Wars movies, Harrison Ford was given some lines to read and they’d done like hours and hours of retakes and apparently stormed off stage at one point off the set and he just said, “George, you can write this stuff, but you can’t read it.” And I think a lot of architecture has to be very, very conscious of that kind of thing. It can fall into kind of these anti-patterns of design that looks great on paper, but no programmer would ever implement because maybe the patterns that they’re promoting don’t have good developer experience. So maybe they’re not very debuggable or traceable or all these other qualities. That also makes systems good and stable and changeable actually can get lost in your hypothetical target architectures if they’re drawn in isolation. So I think that like the really, really important theme is bringing all this stuff right up close with implementation. And I think that’s the biggest change maybe in the last 20 years of what architecture really means to me now.


[00:13:24] JL: What is some of the jargon that really tends to intimidate people about architecture? We talked a lot about how there’s gatekeeping in different ways. What is something you’d like folks to know to be less intimidated by the area?


[00:13:40] DW: Everyone should know to ask what the word they don’t mean is. And I know that sounds like such a mundane response, but I think one of the most useful roles anyone can play in the room is being the person that stands up and says, “I don’t know what you mean.” Because especially in my role, as a consultant, going to different organizations, I’m always the idiot in the room. That’s the feeling I always have because every different organization has different language and different internal idioms and jargon. And I think the domain of computer architecture has the exact same problem. The gift I would give to someone would just be to stand up and say, “I don’t know what that is. Can someone explain it to me?” Because you can guarantee you’re not the only person in the room thinking that. Actually a lot of things once they’re explained are triflingly simple. And that was kind of part of the motivation of writing the piece in the first place was most of these things that sound scary often aren’t. The one that always comes up and people often have asked me, “How should I learn design patterns?” And it’s almost the wrong question, because a design pattern is a category of things, it’s a collective noun, and all design patterns are the equivalent of a well-accepted Stack Overflow answer. They’re just something that people have done enough times that they kind of remembered them and then someone wrote them down. It doesn’t give them this anointed quality where they shouldn’t be contended with or explained or discussed, much like in any kind of subculture and really programming is a subculture in industry. Internal language and jargon becomes kind of a defensive gatekeeping thing by default. And actually in other interview questions. Anyone that’s worked in programming for long enough knows that most programming interviews are garbage. They’re either like whack-a-mole pop quiz questions, some things you may have remembered one time or things that you could Google triflingly in two minutes, right? They’re not really good indicators of how people actually work. And I think things like design patterns and especially whatever the trendy thing of the day is gets wielded as kind of a tool to discriminate against people that could actually be really, really talented. Kubernetes for instance, if you can’t go through the glossary of silly, made-up names named after parts of boats, then maybe you couldn’t deploy some software on the web. And I think it’s just garbage, honestly. It’s kind of a ridiculous notion that your ability to rote memorize a bunch of dictionary thesaurus style words dictates how good you are at critical thinking and communication. I find this fascinating because I have this like thoroughly deep held belief that programming is communication. When you take three steps back from all the stuff we do, like what do we do really? We articulate solutions to problems in a constrained language, in a limited syntax. It’s more like writing. And the fact that programming where you spend more time reading code than you do writing it and the actual job is to communicate complex problems in a simple way comes with its own emotional baggage of jargon and big words that mean nothing. It almost tickles me in this irony.






[00:17:00] JL: Join over 200,000 top engineers who have used Triplebyte to find their dream job. Triplebyte shows your potential based on proven technical skills by having you take a coding quiz from a variety of tracks and helping you identify high growth opportunities and getting your foot in the door with their recommendation. It’s also free for engineers, since companies pay Triplebyte to make their hiring process more efficient. Go to to sign up today.


[00:17:25] RudderStack is the warehouse-first customer data platform built for devs that builds your CDP on your data warehouse with support for cloud data warehouses like Amazon Redshift, Google BigQuery and Snowflake. RudderStack makes it easy to collect, unify, transform, and store your customer data as well as route it securely to a wide range of common, popular marketing sales and product tools. Start building a better CDP for free today




[00:17:57] JL: One of my favorite tags on Dev is the explain like on five tag where we challenge people to, yeah, explain complicated concepts to a five-year-old. So instead of asking the definition of five different types of design patterns and when you would use them, what would you suggest people ask to assess whether or not somebody is a critical thinker, and if they’d be a good fit for an architect role?


[00:18:26] DW: The most important thing in the modern era in software architecture is your software is built with the ability to change. That’s the commonality, right? Especially when most people are building web applications of some kind, yeah, sure, there are other kinds of software out there, there are apps, but mobile phone apps are kind of deployed with the same kind of patterns as well applications are anyway. I would probably ask people, firstly, how they would go about building an application so they could deliver it quickly and how they can roll it back quickly. And a lot of the stuff kind of got rolled under dev ops, but how they would architect an application so that they could deliver it and observe it safely. I think that would be the first kind of question I would ask them. I would also ask, what kind of architecture that they would build based on different kinds of usage scenarios? Because one of the common mistakes I see people make when they think they’re going to get into architecture is everyone presumes they’re going to be the next Google or Facebook or #web-scale enormous company. And they will design architectures or cost hundreds of thousands of dollars to operate for no meaningful benefit when they don’t have any users. And there’s kind of this really, really interesting truism that I look for and it’s people that will design software architectures and application architectures for the kinds of user size and scale that they’re realistically expecting because I think that makes the difference between companies that hemorrhage, money building stuff that nobody uses and actually building size appropriate, changeable meaningful applications. And I think those are the things I look for when I’m looking for architects and then principal engineers, as people that understand the trade-off, understanding the truth that for every order of magnitude of growth in your application that your architects show will change probably. And often significantly, there is no shame in building something for the five uses you have now, and then having to throw it away when you have 500. That’s totally, totally appropriate. And I think people struggle to internalize that, which I find quite interesting because obviously if you asked me, “What’s the most popular architectural style of today?” Well, everyone was will wave a flag around and say, “Oh, it’s microservice architectures.” Despite the fact most people don’t really understand what they were originally meant to mean, which was complete vertical slices through an application that could scale and be disposed of independently. And the idea behind a lot of the original microservice architecture writing was that things could be disposed of when they no longer fit at purpose and replaced with something more scalable and more interesting or more robust. I like to see architects that have a patience and a thoughtfulness around how many people have to work on a thing, how many users are going to use it and how they’re going to deliver the thing, rather than just, “Hey, I can draw four boxes and call them services on a piece of paper and let’s use Kubernetes.” I think there’s a big difference in the thoughtfulness to design applications. Honestly, people can afford to run.


[00:21:37] BH: How would people answer the question of what architecture is in software development today versus 35 years ago in the 1980s when a lot of the code was the same, but I think maybe the answer to this question will have changed? What are your thoughts on that?


[00:21:53] DW: The interesting thing to think about is how we delivered the software and I think that’s actually the thing that’s changed the most. And it’s not actually about how we’ve written codes or stylistically and aesthetically code has changed a little bit. There was kind of the mid-90s pushed towards managed programming languages and maybe a little bit more abstraction away from the bare metal. Fine. Is that significant architectural shift? Probably not really. There’ve been a couple, right? In Windows lens in the late ’90s was a big shift originally. We kind of had mainframes of the ’70s and then desktop applications and microcomputers in kind of the ‘80s and ‘90s and then push towards kind of service-oriented stuff on the desktop and then towards the web in the early two 2000s. But actually the commonality between all of that is how we delivered software, how that changed, and I think the kinds of architectures we need now need to be appreciative of that and that’s the real driving force. So for instance, if we were writing some software in the 1980s, so we’re writing a video game for, I don’t know, an Amiga and then we’d put it on some floppy disks and that’d be gone. Right? So there’s a focus on being perfect on getting it right first time, and actually, as we’ve moved away from that, that’s less important. And that was part of the stuff that like the original Agile Manifesto kind of embraced. And it’s funny because you can trace it back even further if you like. So forget the ’80s. I’m using C. How about like the 1950s or the 1940s? Where to write software in the ‘40s or ’50s, there’s like a really great mental picture here. When you get to like a big building, that’s like the size of an entire street and you look for the programming room, you find it and it’s a lot of women because it was seen as secretarial work, writing out programs on paper. And then they would go and go down the hallway and they would file the programs and there’d be some kind of punch room where someone would transfer the programs on to punch cards and then they would file it in the cabinet. And then they would come back in like a week’s time because they’d have been given a slot on a mainframe and those cards would have been executed. By the time they got their program printout, they would have to really, really pray that it didn’t just say error because the feedback cycle on that process was measured in like a week. So actually the whole way through the evolution of programming, what we’ve really been doing is backlinks drive that feedback cycle down, down, down, down, down. So taking it from there. So modern-ish programming environments with ripples and tools where we can see immediate results. So now the next step along is software continuously delivered to the internet where we see changes with our customers immediately. There’s a journey there, but it’s all about the feedback cycle that’s changed. So I think everything that we should do architecturally should be there to support improve continuous delivery, improve signals and improve feedback because that’s actually how we know whether we’ve done something that works or didn’t and that’s kind of where I try and guide people down. There’s a current trend for people to be now focused on observability over just metrics and actually understanding how the software runs in production. And there’s also like this truth that people are starting to understand that actually we’re all testing in production anyway, whether we like it or not. And actually, I think that’s really, really interesting and it’s almost that’s another seismic leap and understanding that our customers and our users are actually the people that are going to be finding a lot of the errors before we do because no automation is ever really enough. So I feel like everything we’ve done through distribution on disks to CDs, to binaries over the internet, to now kind of web applications is driving us to these architectures where we can easily change and fix our software, which means we can be a little bit more experimental in the things we build. And that’s kind of awesome.


[00:25:44] JL: So I know that the jargon is secondary, but with this thing with another guest the other day at some rapid-fire definitions and I’m wondering if you’d entertain us on that, but perhaps define these terms so that it’s digestible to an eight-year-old.


[00:26:05] DW: Perfect.


[00:26:06] JL: What is load balancing?


[00:26:08] DW: Load balancing is when four people all have to do the same job and you throw a ball at them and the first one to catch it does the work.


[00:26:16] JL: Oh, I love that. Okay. Distributed caching?


[00:26:19] DW: If one computer has an amount of memory, 10 computers can all share their memory.


[00:26:25] JL: HTTP APIs.


[00:26:27] DW: A program on your computer lets me talk to it by a well-known what they call protocol and all that really means is I say, hello, you send me a file.


[00:26:38] JL: GraphQL.


[00:26:39] DW: Something that people that want everything to look like JSON wrote instead of a REST API.


[00:26:45] JL: And let’s actually go into some of the architecture patterns. So what is MVC?


[00:26:50] DW: Model View Controller. And this is the thing people will be most commonly familiar with because, well, Rails changed the internet and made MVC really popular, but all it really means if you’re new to programming is put all your HTML in one folder, put all your logic in another and put some files in another one that says, “What data are you going to draw on the pages?” That’s basically all it is wonderful.


[00:27:16] JL: Object-relational mapping.


[00:27:18] DW: Database is only like things that look like Excel spreadsheets and you have objects. So instead of having to write lots and lots of boring code, we’re going to give you a library that really opaquely and confusingly converts one of those things to the other.


[00:27:31] JL: And what is a dependency injection?


[00:27:34] DW: The Hollywood Principle, “Don’t call me, I’ll call you.” Or if you have some software that needs to use a library, something magic in your framework gives it to you so you can use it.


[00:27:45] JL: All right, David, I think you passed the test. Do you want the job?


[00:27:47] DW: Perfect. That’s all you need to know to be an architect, right? Files go in folders.


[00:27:55] JL: I know you touched on Kubernetes earlier. Can you tell us more about that and just what your general thoughts on it is?


[00:28:00] DW: Yeah, the most expensive, complex thing that most people don’t use, but somehow our industry is in this collective delusion that because Google requires it to scale, everybody’s software should run on Kubernetes. Kubernetes is a wonderfully sophisticated runtime hardware, virtual hardware management thing that lets you auto scale, right? We’ll file it as that if you’ve never come across it before. It’s not to be operated by mere mortals. It’s quite complicated and it has lots of sharp edges and I really wouldn’t recommend it to anybody who just wants to like put a website on the internet, but apparently the collective brain trust of internet thought leadership suggests that everybody needs to scale like Google. I was doing a project last year and this is a true story that I’m going to hide the numbers from. And that project before I arrived had three entire Kubernetes clusters, a team of 12 dev ops people to maintain them, to build a new software platform. And I was like, “Okay, cool. You’re doing this to scale. How many users do you expect is going to use your application?” “Oh, in the first year, maybe a hundred.” I was like, “Okay. So the salaries of 12 full-time employees, plus the minimum costs for running these three Kubernetes clusters is how much exactly?” And it was multiple tens of thousand pounds, thousands of pounds a month. We didn’t have a single user for nine months.


[00:29:23] JL: Wow!


[00:29:23] DW: Not one. Not one. And at one point, that whole architecture was replaced with a single Google app engine web application and we managed to take the multiple tens of thousands of pounds’ bill for the month down to, I think it was something like three pounds, like three actual pounds. And most of my experience of using Kubernetes involves people doing terrific exercises and over-design where they think they’re going to have three million visitors a month, but actually they’re building some line of business application and they can see all 1,000 of their users, and it’s just a thoroughly inappropriate scale and size of a solution for that problem. Honestly, most people don’t need much more than Heroku, Azure App Services, whatever AWS is doing in that space, Elastic Beanstalk or whatever it is. Most people don’t really need much more than that tool to scale their applications.


[00:30:18] BH: We’ve been expanding our systems architecture because as we transition as a company from supporting Dev to we’re building out this product called “Forem Cloud” because we want other people using our software labeled Forem. And so we are moving off of Heroku because we want a little bit more control over things, and I think we’re making good choices and I’m pretty happy with how things are turning out. We’re not using Kubernetes or doing anything overly complicated. So I feel like we’re on a good path, but it also really makes me appreciate Heroku that much more. As we have our own like specialized version of a system similar to Heroku that allows other folks to host their open source, social networks and stuff, yeah, it really makes us appreciate Heroku.


[00:31:07] DW: And what it does for free for you as well. Right? Like all that stuff is amazing and probably industry leading. And it’s funny. There’s an interesting trend here where a lot of organizations of a similar size to where I suspect you all are go through this similar journey of like, “Oh, we’re provisioning something that looks a little bit like a platform of multitenancy and we have to do data segregation and safe harborage of data.” And there’s all these other concerns that come in when you grow out of, “Oh, this is just our web application that has our stuff in it.” Often, people will go onto AWS or on Amazon or on Google and you end up building software that is very similar to a lot of the stuff they provide as a platform because you realize actually there’s a lot of smart people that got a lot of that stuff right and there’s a reason that all this stuff exists. It’s the hard path, but you should only take it when you have needs that require it. It’s good that you’re having that inflection point and thinking, “Okay, we are building our own kind of platform thing on top of a lower level abstraction.” “Oh God, we got to build all this stuff now.” That’s terrifying. Debuggability, always the one.


[00:32:20] JL: Do you have any parting advice for our audience who might want to dig into architecture more?


[00:32:25] DW: You’re already doing architecture if you’re writing software. I was recently asked a question, which I thought was very, very prescient, which is, “What advice would I give to a younger version of myself?” The thing that I landed on was I wish I had just spent a little bit more time being thoughtful, just about everything I wrote. I wish I hadn’t rushed to open that PR or make that commit and just spent 10 minutes more on every bit of code I ever wrote, just that extra 10 minutes of being thoughtful and thinking, “God, who is the next person that’s going to see this? Does this make sense? Does this read like a book? Does this admit to meaning? Is it clear? Does it feel good? Does it look right?” And I think that took me probably 15 years to learn to just take those three steps back from the dripping paint wall and go, “Ah, I’m going to consider this.” But actually I feel like everything I do now benefits from me having that extra little bit of patience. So all architecture is really being concerned with the way that you write code. So be more thoughtful, give yourself the time and the brain space to actually think and don’t beat yourself up about things being wrong. You never know, you might be stumbling across something that’s brilliant and beautiful that just nobody else has done before.






[00:34:01] SY: Hi there. I’m Saron Yitbarek, founder of CodeNewbie, and I’m here with my two cohosts, Senior Engineers at Dev, Josh Puetz.


[00:34:08] JP: Hello.


[00:34:09] SY: And Vaidehi Joshi.


[00:34:10] VJ: Hi everyone.


[00:34:11] SY: We’re bringing you DevNews. The new show for developers by developers.


[00:34:16] JP: Each season, we’ll cover the latest in the world with tech and speak with diverse guests from a variety of backgrounds to dig deeper into meaty topics, like security.


[00:34:23] WOMAN: Actually, no. I don’t want Google to have this information. Why should they have information on me or my friends or family members, right? That information could be confidential.


[00:34:31] VJ: Or the pros and cons of outsourcing your site’s authentication.


[00:34:35] BH: Really, we need to offer a lot of solutions that users expect while hopefully simplifying the mental models.


[00:34:42] SY: Or the latest bug and hacks.


[00:34:45] VJ: So if listening to us nerd out about the tech news that’s blowing up our Slack channels sounds up your alley, check us out.


[00:34:50] JP: Find us wherever you get your podcasts.


[00:34:53] SY: Please rate and subscribe. Hope you enjoy the show.




[00:35:01] JL: Now we’re going to move into a segment where we look at responses that you, the audience, have sent us to a question we made in relation to this episode.


[00:35:09] BH: The question we asked was, “What are your burning questions about software architecture?” Here’s our first response.


[00:35:16] EM: Okay. Hi, I’m Ender Minyard. Why do people use frameworks? I have been reading Addy Osmani’s book about Scalable JavaScript and that’s literally the only reason I now understand why frameworks exist is that you need modularity in your code so that it’s reusable, but then JavaScript has modules built in modules in the browser. And all you need is HTML imports for modularity. So why isn’t that enough? Why do people need frameworks?


[00:35:48] DW: People clearly don’t need frameworks because if you’re looking for modularity, it’s totally built into the language. It’s fascinating, isn’t it? Because it’s like there’s this healthy tension between using libraries and using frameworks and it’s all about constraints. So when you use a library, you’re doing all the orchestration work, you’re designing your software, and you’re using something. So you can write a program that does anything you like, which uses a little bit of the functionality of a library. When you use a framework, you’re constrained by the design of the framework. You can only do what it was designed to do. But by taking those constraints on board, you often get a lot of things for free. So it’s not necessarily because of modularity, often modularity kind of gets conflated with frameworks because in order to plug into different framework capabilities, you need to build things in a modular way. But actually it’s more that frameworks are much like design patterns, common answers to problems that people solve frequently enough that they wrote them down.


[00:36:48] JL: Here’s our second voice memo.


[00:36:50] ANDRES: Hello DevDiscuss Podcast. This is Andres. And for today’s session regarding my morning question about software architecture is now everyone is working with microservices and distributed systems, but when it comes to deciding how small or how to split those services, there’s no defined guideline. So the question is, how can we make that decision more precise?


[00:37:18] DW: I always feel like when they say, “Hello,” we should respond like, “Hi.” I have one golden rule there actually. What changes together and is used together is the same thing and should be deployed together and lived together. So it’s all about change frequency and interdependencies. One of the biggest crimes against microservice architectures is when you see someone take something that looks like a logical subsystem and split it down to like four or five or six or seven different “services” with a single function call or HTTP endpoint or method on the end. And then you just know that if you go and kick one of them over, all of them will fall down. If you can remove one thing and everything falls down around it, those are not microservices. Those are one cohesive piece and they should probably be the same thing with the same failure criteria and the same deployment cadence. So yeah. What changes together lives together.


[00:38:17] JL: And here’s a call that we got from our Google Voice.


[00:38:20] GP: My name is Glenn Plunkett from Ontario, Canada, and I have four questions. The first one, “What are things that need to be considered? As in what questions should you ask yourself for every project that you plan?


[00:38:37] DW: What questions should you ask yourself every project that you planned? Why? And I know that sounds like the really silliest thing to say. Most technical projects are so obsessed with what without stopping to think why. And the why often leads you to a better technical solution once you thoroughly understand it, which is a really long-winded way of saying, “Understand why your business is making the decisions it’s making. Otherwise, you may just do a silly thing without really knowing.”


[00:39:09] GP: Two, what are some red flags that point to potential problems that should be addressed?


[00:39:15] DW: That’s a very, very broad topic. I will namedrop a book I read, which is very, very good. It’s a guy called Adam Tornhill who wrote a book called Your Code as a Crime Scene. And he was a former forensic psychologist who wrote, I think he’s written two books in this topic now, around looking at source code as if they’re crime scenes and looking for signals in the code base to see where changes should be made. He started a web application in the last couple of years called, I think, which you can connect to your Git repositories and run analytics. It’s really, really cool. But the things that I often look for, I look for frequency of change in a project. So I look for files that change a lot. I look for large pyramids of messy pieces of code. So things that change a lot and look ugly and feel a bit, for want to a better word, icky are probably my biggest red flags. And for architecture, the things I look for are completely based around unnecessary complexity. So if people are buying big things or trying to use big things, when I feel like we only need small things to start with, I would always try and pull them back and tell me exactly why they think the thing that they’re trying to do is better than just doing the simple thing.


[00:40:36] GP: Three, what is something you wish you knew as a beginner, a change you wish you would have made that would have made your project easier where it saved you from problems down the line?


[00:40:47] DW: Again, just do the simplest thing that can possibly work. And I guess I can sound a little bit militant when I say like actually go read the Agile Manifesto. Start at the beginning and do the simple stuff. And also don’t believe your own hubris. Literally, one of the most important learnings I’ve had in my career is that just because you feel like you’re relatively smart and you did some good things once doesn’t mean you’re right about everything. And it’s really important to stay humble and listen to everyone and raise everybody else’s voices up. A friend of mine said something good to me this afternoon, actually, which is a lot of technical discussions should be prefaced with the sentence, just because you’re the biggest expert on the one thing you know doesn’t mean you have to be the loudest voice in all the rooms. And I think people could do well to listen more and be a little bit more empathetic.


[00:41:37] GP: Four, how to deal with opposing opinions on architecture from your team? For example, an SQL database versus a no SQL database, a Node versus Go, et cetera. In my experience, it seems like everyone has opposing opinions of what is best. How do you deal with that?


[00:41:57] DW: You let people debate amongst themselves until they make themselves feel kind of sick. Either one or the other of them will seed at some point. You try one. You measure it. If it works for you, you don’t waste time thinking about what could have been. If it doesn’t work for you, try the other and you measure it and then you compare the two things. I know that sounds like a really trite piece of advice, but the amount of bike-shedding that happens around choices often derails projects. And when I say bike-shedding, it’s the phenomenon of people trying to build a bike shed and they will find a small piece of detail, like for instance, what color the bike shed is, and everyone will have an opinion on it and you will waste months just debating the color of the bike shed rather than like how many bikes it can store and whether it’s useful. So if people have these really conflicting opinions, I will often defer to just choosing one and making people measure it after some reasonable due diligence. For smaller scale things, you could always prototype and measure against each other. For even smaller scale things, you could just do both if you could afford it and measure which one seems to feel the best. Like which one is more maintainable, which one produce less friction. So opposing opinions are horrible because programs are not like to argue, which is wonderful.


[00:43:13] JL: That is some sage advice. Well, I think that that wraps it up. So David, thank you so much for joining us today.


[00:43:19] DW: Well, thank you very much.


[00:43:29] JL: I want to thank everyone who sent in responses. For all of you listening, please be on the lookout for our next question. We’d especially love it if you would dial into our Google Voice. The number is +1 (929) 500-1513 or you can email us a voice memo so we can hear your responses in your own beautiful voices. This show is produced and mixed by Levi Sharpe. Editorial oversight by Peter Frank and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, please email [email protected] and make sure to join our DevDiscuss Twitter chats on Tuesdays at 9:00 PM Eastern, or if you want to start your own discussion, write a post on Dev using the #discuss. Please rate and subscribe to this show on Apple Podcasts.