[Best of 2023] #122 - Essential Things Every Software Engineer Should Know - Kevlin Henney

Hey, a quick message for those of you who are listening to this episode on Spotify. I have a small favor to ask. Spotify now allows mobile users to rate podcasts. I would really appreciate it if you can take a quick pause to go to the Technically Journal podcast page and leave your favorite show your best rating on Spotify. It will help me a lot to get this podcast to reach more people on the platform. Thanks a lot. So one thing. That I noticed.

When you mentioned. In the beginning, before you read these three things, is. You mentioned the books have been written like 12. Years ago and there are still some things that are timeless and this is something that you mentioned before we had this talk that we can all learn from the past. There are many things that stays relevant. There are many things that stays

true even till now. So what will be some top key lessons from the past that you think we as programmers covering the old programmers and new programmers should know? Why are the things from the past there still stays relevant? So let's go back to origin story. So I read a lot of books when I got into software development was at the end of the 1980s, which is quite a long time ago, and the world has changed quite a lot since then.

The books that my boss had were from the 1980s and the 1970s, and I read a lot of these things, so they were kind of already historical, a lot of them. But what I found was a surprisingly timeless quality to some of the books and their advice. So I was brought up on a lot of ideas about how to think about code in terms of cohesion and coupling. We are losing these message. People have got distracted by guidelines that don't emphasize these properly or have watered

them down in a particular way. Cohesion and coupling. Cohesion, the degree to which things cohere and naturally hold together. Now, sometimes people kind of say, oh, isn't that the Single Responsibility Principle? Well, not really. It the kind of cohesion. It's not about responsibilities. The original quote is the Single Responsibility Principle is actually about single reason for change. It's nothing to do with responsibilities. So naming is hard.

We know that single reason for change, but what does that actually mean? It doesn't really mean much. It's a kind of cohesion, but there are other kinds of cohesion. So why people have got fixated on one kind of cohesion to the exclusion of others, I don't understand. We should be teaching people

about cohesion. And then again, if we look at things like the SOLID principles or many of the principles people describe, they don't talk about coupling, In other words, dependency management, the degree to which things connect. And we have far more dependencies in Co bases now. And for some people when they talk about dependencies, they are talking about external dependencies. And you sort of say, oh, dependency management. Yeah. And they show you all their

external dependencies. Like, yeah, you've got half a million lines of code here. I'm talking about the dependencies in the code base, not just outside the code base. Some people kind of ended up kind of losing track of that. So coupling, cohesion, these are ideas in the 1970s. They do not go away. They are fundamental. There's a lot of things people have been trying to push as fundamental. Those are coupling. Cohesion are for us. They are for our benefit.

But by the way, the code doesn't care. The compiler's just going to compile what you give it. It doesn't care about coupling cohesion. The processor you're running on doesn't care about coupling cohesion. It's just going to execute what you say, coupling, cohesion for our benefit there so that we understand, so that we can maintain, so that we can build. That's what that's about. So for me, these are really old ideas and more appropriately timeless ideas.

They don't go away. We should be building on them, not trying to muddle a message. Therefore, paying attention to this stuff is important and I think that's what a lot of people are trying to do when they reiterate or try and reframe these, they're trying to get that message out. But then there are other things that I think we haven't paid attention to Co quality. So these days the popular way of framing things in terms of issues of Co quality is in terms

of technical debt. Now that's not really quite right, but it's not a bad metaphor, although we do misuse it a little bit. But if you look back at the past, people have been talking about Co quality issues forever since they realized there was an issue. One of the things we've learned is that this really does make a difference to the future of development. So how can we expect people to easily add things in future? Put it another way, most developers are living in the

past. When somebody sits down in front of a piece of code, they are projecting themselves into the past. Maybe it was the past them, maybe it's past somebody else. But when people are working on a code base, they are spending, let's say, in an 8 hour day, they are spending about 7 to 7 1/2 hours dealing with the problems of the past. Oh, I'm trying to add a feature. Yeah, I can see you're trying to add a feature. But actually what you're doing is you're grappling with the way

that the code has evolved. You're actually fighting the past because you know that you want this feature to be different, but you don't understand the code that's there. Or you're fixing a bug. Fixing a bug is living in the past. Trying to understand code that was written that's living in the past, working around something that's living in the past. Writing a test for a piece of code that doesn't have a test

that's living in the past. In other words, these are all things that should have been solved in the past. People spend most of their time living in the past. And I'm not saying that we don't do that or shouldn't do that. We're there's always going to be some percentage. But I think that actually defines most of what programmers do. Very few developers actually spend their time genuinely adding value to code bases. They spend their time compensating for the problems,

the past. And this is a distinction that systems thinker John said and highlights as value demand versus failure demand. The demand for your work. How much of your work is actually spent on dealing with problems that have arisen in the past and more importantly for me, problems that are actually solved problems. So let me bring something more up to date.

So refactoring that I think for many people they just assume that part of the software development landscape, actually until the late 90s, that wasn't really a known term or a popular idea. In one sense, we've done really well here. But if you go back and you look at Martin Fowler's original book on refactoring, or the original writings and terms of Extreme Programming, which really focused trying to bring refactoring as forward to the

front as it were. So refactoring in many people's heads exists in one of two spaces. Oh, refactoring. That's a big work we do on our legacy code base. You know, refactoring is to do with legacy, is to do with bad code. And then the other one is, oh, refactoring. Yeah, that's the shortcut key that gets me to rename things and occasionally Extract method. And it's just like actually refactoring is a design practice and it's not always about bad

code. Refactoring is the idea that your software is supposed to be sought, and therefore when you come up with a better understanding of something, you oh, wait a minute, there's a better way of writing this. I should be able to reshape it easily so that I reflect my current thinking instead of using yesterday's thinking. I've got my current thinking. I keep the code fresh. Therefore it's constantly in the state of improvement and response. Because we're always operating

with incomplete knowledge. We can never know everything. It also allows me to be more forgiving, if you like. Yeah, we got that wrong, but now we can make it right. And that's not a big deal. That's part of what we call software development. It's not a separate thing. It's not a separate activity I have to ask somebody permission for. It doesn't have that idea though. It's just part of the flow. And so I think that although you open up a modern IDE, it's got

refactoring there. Most people don't use that apart from rename kind of have a standard Joe. What I point out to people, it's just like, isn't it great these days? We don't have legacy code because when I joined the industry, we had legacy code. In fact, the term legacy was first used in 1989. So the term legacy applied to code was actually the year that

I joined the industry. And I say, isn't it great these days that we don't have legacy code because we've got the refactoring tools that eliminate most of all the problems, you know, but people used to complain, oh, we've got this method, it's too long. It's so good that we don't have that problem anymore because we have ways of breaking up methods. And people say, Oh yeah, classes that are too big. Again, we don't have those problems because you can extract class.

Eventually, kind of people get the idea that I am joking. And actually I'm asking a deeper question. We have these tools. So why do we still have all of the problems that these tools solve and what that actually teaches us? It was not a tooling problem. That's what it teaches us. We have given everybody everything they need. So in other words, this is the

interesting thing. For most software, we know how to deliver it with low defects, with low unmanaged technical debt, and to deliver it close to being on time. These are solved problems. By the end of the 20th century. Every single one of the problems I've just mentioned was Sol, and yet we still struggle with them. So for me, that's the bit of the past you want to live in. What are the good ideas? We are still not applying consistently.

I still have to discuss with people whether or not they should test. That shouldn't even be a discussion. OK, you write tests if you can get high statement coverage, well done. There's other forms of coverage, but that should be the minimum. When people say, Oh yeah, we've got less, do you have 100% statement coverage? No, no, we're at about 50%. OK You do know that 100% statement coverage is really easy to get and people are always shocked by that.

It's just like, well, yeah, you just do test driven development. That's it. People who do TDD don't worry about coverage. Or rather, they worry about when the needle dips below 100 because that normally means there's some dead code. This statement coverage is only interesting for people that don't do TDD or other forms of continuous testing. The idea if you are doing continuous testing, coverage is not interesting.

It's a figure that you always expect to be high because you're always writing your code and your test together. Maybe you lead with the test TDD style. This is a solved problem. We solved this years ago, but people still struggle with it. They try to justify having to run tests. I was talking to somebody yesterday from Microsoft about this whole thing about why is it that people are not using static analysis and high warning levels more? There are reasons, but they're

not very good ones. Why do people not have clean builds? Once you solve all of these, it leaves you with the real problems that are interesting once you've cleaned up the bad code, Once you've cleaned up all of this kind of stuff, you will still have legacy, but that legacy will be there for a different reason. That legacy will be leftover decisions from the past.

Your challenge is now to deal with like, yeah, we took this decision, but the technology landscape or the requirements of MU. So that decision is no longer appropriate. It's not a bad decision, it's just doesn't fit the world any. And we wrote this code in good faith, but now it's no longer right. So we need a better fit for the code in the world. So don't worry. Once we've solved all the problems, there are still plenty of problems.

But what I'm saying is that most of the things that people have said, hey, modularize your code, use a coherent paradigm, have less state mutability. That doesn't mean you have to go do functional programming. If you're in a functional language, that's absolutely brilliant. If you're in a language that really nudges you in that direction, that's great. But even as somebody who's worked in C and Fortran, I'm going to say you don't have to

have highly imperative code. That's never been a great idea, and you're not forced into that. There are simple techniques you can deal with. Modular as you code use various techniques. A class is a module in this sense. It is a modular construct. Any form of data abstraction is a modular construct. Micro services and modular constructs at a larger scale. But the idea is, if you think that micro services are going to solve your poor modularity in your code, they're not.

When everybody says, hey, we're doing micro services because it's going to improve the structure of our code, well you don't need micro services to do that. Micro services solve a very specific problem related to deployment and scaling. That's what they're really good at. If we have had so many paradigms over the last few decades that are about how to organise your code, you don't need any more. You've got every single tool.

And if you can't do it with that, then you should take a step back, put the mouse down, step away from the keyboard and go wait, what's really going on here? What is it that we are missing as a team collectively to reinforce these practices? So yeah, the past is an interesting place. We get drawn back to our mistakes in the past, but we fail to learn from our successes. So that would be my general

advice on this one. Listening to your explanation is very fascinating because a lot of developers these days chase this hype driven development, right? Oh, there's the new cool technologies, new framework, new libraries, new paradigms like micro services, event driven and things like that. But if we look back to the past, there are probably so many theories that still stays

relevant. And in fact, I noticed some of these thought leaders in the tech industry like Dave Farley, Robert Martin, Uncle Bob. They wrote books titled like Modern Software Engineering and Clean Craftsmanship. But if you look at the things that they are advocating, actually it comes from the past. The same fundamental things that stays relevant even up until now. So I think the key message here I want to emphasize is that for developers, please go back to the fundamentals, don't always

chase the new shiny things. There are still things that we can probably master to become a better developers. Yeah. And I think the value is that when you understand though, it gives you a more solid foundation. And when something new and shiny does come along, you now have a more objective assessment. You can separate out and go, OK, yeah, this is building on foundations. There's nothing new here. And then you can look at the bit that actually is shiny and go,

this is the value of this. Or you may say, wait a minute, there is nothing shiny here. This is just repackaging the past and also it's mistakes. So maybe let's not do this one. It gives you a more objective sense. Of course, most people in technology get into technology because they like the excitement of something. So we have to kind of watch ourselves a little bit on this. We are our own worst enemy at this one.

So one thing that I always find fascinating also because there are tools that are built by developers that makes things easier for us to. Churn out code. But not necessarily comply with this cohesion or this coupling. So think of it like the framework, software frameworks, right? So I think that's also another thing that is fascinating. Like we tend to one, shortcuts deliver something faster, but not adhering to the good best principles that software should be written in.

So Kavlyn, another thing that you're very popular in, it's what people call Kavlyn Haney's screen, right? You can see in Kavlyn Haney's Twitter. Just look at what we call software failure. And these are normally public software failure. And people just send, you know, pictures of these software failures to Kavlyn. So maybe the first thing is tell us what the story is all about. How come people actually send all these things to you? So the story goes back a long

way. I used to take screenshots. Whenever something crashed on my machine, I'd take a screenshot of it, and sometimes I would integrate it into a torque. Then of course, phones have cameras. So I started taking pictures of software failures in public places, because software runs the world, but it doesn't always run it in the way that we wanted to. There's a lot of reboot screens and screens which trace very elegantly the whole text stack that's just crashed.

I started taking photographs of these, and again, I'd incorporate those into talks or I'd just kind of put them on my screen when running a workshop. A good source of entertainment, but also going back to this question of quality as something I've always had an interest. It's a reminder of, like, yeah, in the tech space, we have a certain responsibility. We are creating things that crash. We are creating things that don't work.

A bug isn't personal inconvenience to you or a configuration issue is a personal inconvenience to you, or it just becomes a ticket. The thing is to realize that it exists in the world. It's not an abstraction. It's actually exists in the world. It's amusing sometimes, but also it's probably preventing somebody else being able to do something. So I kind of highlighted these. Then as a result of this, people would then start emailing me these things. Then we hit the social media area.

So it's much easier. They have to e-mail me, they can just tag me. So this was becoming a popular thing on Twitter in particular. What I would do, because that's a very public space, is that I would just retweet these. Then people started making a point of doing this. And in 2016, somebody actually started saying, oh, a kevlan Henny screen because it had reached a particular point. And so that's how my name got associated with it.

From that point, there's even somebody put an entry in Urban Dictionary and there's even a mention in the register of this stuff. So that's kind of an interesting thing. I was also asked by somebody Kevlan, what does it feel like to have your name associated

with failure. So I think it's an interesting way of looking at it. It's just like, yeah, I don't 'cause these screens, but it is interesting because it's a reminder for me that, you know, when we deal with software, when we develop it, and when we deploy it, we are part of a larger system where our failures in software are no longer about us. They are about other people. They become very visible. And in a world that runs on software, that becomes a prominent point.

Some of them are quite revealing in a way that you don't want to be revealing. Like I said, sometimes you get a complete stack trace. In fact, I saw one yesterday which was quite interesting. The stack trace was not visible even though there was an error. Because whoever created this had the wisdom to say, you know what, we're showing our internal structure that can be used against us from a security point

of view. You discover that somebody's using an unpatched version of something, you go, Oh yeah, that's interesting. I've got a new attack vector there. But it also tells us something about the organisations that run them. I still get images of Windows XP boot screens and failure screens. Windows XP has been out of support for a very long time. Again, we're living in the past.

A lot of the world is running on stuff that everybody thinks they left behind, but there isn't it actually all there. We have a responsibility there that we need to get a little better at this, but then we also get the obvious programmer level bugs. It's just like, yeah, we should have perhaps configured that a little more carefully or tested that more thoroughly. It tells us about us. That's what a lot of these things do.

But what is also interesting is that sometimes when people tag me, particularly with something like public transport, they will also tag the public transport company. And some of the time the public transport whoever's on Twitter at that point will sort of say, Oh yeah, sorry about this, or yes, we saw this problem. It's been resolved. Or please tell us more because, you know, this is embarrassing for us. So it's also a public service at

that level? I hope you all the programmers who build systems, never had a chance for your systems to be sent to Kevin Haney for. Failures. But I think the story that you just told, right, I think there's a lot of things here that are insights. So when you deploy software, especially for public systems like public transport, airports, sometimes I see all elevator. So there are a lot of responsibilities. Software failure can impact a lot of people.

These kind of things are definitely for one thing is funny, yes, but at the other end it's something for us to ponder about software failures to be treated more seriously. I hope you enjoyed this short clip from Technically Journal Favorite Playlist. If you find this episode useful, please help share it with your friends and colleagues who you think would also benefit from listening to this episode.

And if you want to listen more from this conversation, please go back and listen to the original full conversation with my guests. Stay tuned for the next Techly Journal episode, and until then, goodbye.