Expert Talk: Web Development & Its Failures

What’s next for web development? In this GOTO Unscripted episode we talk with two web development experts about current practices, influences and where we are headed. Watch the full episode or read the article to find out what yogurt and code have in common.

 

Intro

Lars Jensen: Hello, I'm Lars from the GOTO team, and I'm here at GOTO Copenhagen in person finally. I am joined today by Stefan and Kevlin. So if you wouldn't mind just say a few words about yourselves so that the audience can get a feeling for who you are. Stefan, maybe you go first.

Stefan Judis: I'm Stefan. I do web development now for 10 years. I am based in Berlin, Germany, worked at several startups and will do a rant about web technology today.

Lars Jensen: Sounds like fun. Kevlin?

Kevlin Henney: My name is Kevin Henney, I work for myself. I've done so for many years, and I help teams through training, workshops, and consultancy, to improve their development, perceptions, architecture, the way that they code. And today, I have just done a rant on errors in code, but the kind of failure screens that we see in public or the failures that affect people in software.

 

Kevlin Henney screens

Lars Jensen: And that's actually what I wanted to talk to you about today. I looked you up online, and your name is in the urban dictionary. Can explain what a “Kevlin Henney” is?

Kevlin Henney: Many years ago, I started taking pictures of failure screens. This was when phones started getting cameras, and so you know, you go around, you see, "Oh, there's a failure screen there, there's a public sign." I also noticed often things failed on a browser, "Here's a webpage that's giving me some kind of garbage." And so I started taking screenshots of that. And occasionally, I would include them in a couple of talks or I'd present them in workshops. In the break, I'd put up a rolling screen of this. And then people started emailing me these, and then we hit social media, and they started sharing more directly, particularly on Twitter, they would @ me, and then I would start retweeting them.

And this also has become a slight public service, particularly when it's a rail service. Normally, somebody from the rail company will say, "What's the problem? Which station did you see this at?" So it's kind of a public service. But then people started calling them Kelvin Henney screens. And it made its way into the urban dictionary. Somebody put it in there as, “It's a failure.” It's a public screen failure typically. So yes, my name is associated with failure.

Stefan Judis: That's impressive.

Kevlin Henney: Yeah, no. I don't know how I feel about that.

 

What’s the current state of the web?

Lars Jensen: So I think that that brings me to the theme that I wanted to cover today. You have a sort of fondness for broken things is my gut feeling. And Stefan you have opinions on at least parts of the web being broken. So maybe you can explain what your thoughts on the current state of the web is.

Stefan Judis: I started doing web development about 10 years ago. And I started with PHP, jQuery, and Apache server, that was pretty much it. Everything was on the server side. But somehow the industry over the last decade made it that JavaScript and hipster JavaScript developers like yours truly here took over the world. But also what we did is we increased complexity and things that we shipped to all our users tremendously. And as we've covered, kind of, these broken screens that are everywhere, and very often what we see right now is that people are building applications and websites that are, first of all, shipping double the size of what they need to ship. It is like shipping HTML, but also a half-megabyte of JavaScript, just to repeat yourself again to build the same thing.

And then we also have the problem that, for example, JavaScript is not a failsafe language. If something happens on the network, or an exception is thrown, you can ship all your HTML, and then you have this blank screen, you saw some HTML, but it just falls, everything falls apart. I think somehow we messed it up over the last 10 years. And we're swinging back eventually to building something good.

Lars Jensen: Do you think we are swinging back? Have we hit the rock bottom and we're slowly trying to climb our way back up?

Stefan Judis: I do think that the big factor here is web performance. And so I'm more annoyed about the complexity that we're shipping. Because I see a lot of people entering the industry and they're learning like, "Hey, yeah, great, reactive, da, da, da da, da," and they start building things. But when you ask one question, people are usually stuck because they don't understand what they're actually doing. This is what frustrates me a little bit. And it's not the fault of the people, it's just where we are at right now. For the complexity reason, things probably won't change. But what is happening right now is that Google with Lighthouse is pushing for the last three, four, or five years the Google search results just for performance metrics that are affecting your bottom line as a business.

So when you ship a half-megabyte of JavaScript, eventually you will be punished for that. And this is why I think that we're slowly seeing that people are like, "Well, maybe we don't need that much stuff." Because you want to be on the first page on the Google search results, and if you're not, that's a big problem.

Lars Jensen: Okay. What about you, Kevlin, do you think that we're moving in the right direction?

Kevlin Henney: I'm not entirely convinced. I think it's a complex system. There are a number of factors at play. The question is which one springs out? There are a lot of things nudging. As Stefan mentioned, a really good point about complexity is something that really bugs me, I see it in backend systems, I see it in frontend stuff, it's just like, "Well, what's all this stuff doing here? Why do we need this?"

Stefan Judis: Exactly. What is going on?

Kevlin Henney: Do you understand what you have? When I talk about dependencies, and dependence management, one of the simplest things I say is, "Okay, you think you understand your dependencies. But when I ask you what dependencies are, you actually miss out half of them," because you're saying, "Well, there's a bunch of stuff we've got from NPM." And then your horizon stops there. It's just like, "No, no, that's where the real story begins. That's where your vulnerabilities begin. That's where your surprises begin. Do you truly understand what you bring in?"

I had one JavaScript developer say to me, something like, "Do you mean I have to understand it all?” and I said, "Yeah, if you wanna say we understand our application, we know what it is that is running. And therefore we are aware, from a security point of view." I think that's one of the most interesting ones. We have been building up complexity and not paying directly for it, but we are seeing the consequences of it. 

And it's code bloat, it's surprising failures. When people come to improve performance, they don't know what they're looking at, the bigger something is, the harder it's gonna beat the performance tune. You really don't know what you're looking at and we have made it more complex than is necessary, which draws on our time, or it makes us go say, “Whatever.” So we're not gonna look at that. 

But it also has implications for maintenance, not just performance and security. It has implications for, as it were, the evolution, the agility of the codebase. Agility is a word that has often been hijacked. But that's the thing that we want. We want to keep our software soft. The agility I'm referring to is that simple dictionary definition. You wanna be able to do something quickly and easily if something changes direction, "Can I reflect my change of understanding in the code? Can I do that quickly?" And if the answer is, "No, this is like turning an oil tanker," rather than, "No, we're gonna flip around on a skateboard," then my software has lost its softness, it's no longer soft, it's hard.

And that has consequences for the business. We see that the effects are kind of all over the place, but also tells us what the forces are. If you're not going to be where you are on the search engine rankings, then you might feel inclined to change that. If you are going to be more frequently exposed to security issues, you might want to change that. If you are aware of the fact that perhaps your development is decelerating through this aggregated complexity, you might wanna change that. In other words, I think all of those forces are there. It's just which ones are dominant. And I don't think it takes much to tip us in the right direction, but I don't know that we're there yet.

Stefan Judis: Yeah, I agree. I think the dependency part is an interesting one. Two weeks ago, I read something that really resonated with me. And it was like, if you're installing a dependency, you should be willing and able to debug what's going on. And in my ecosystem, which is the NPM JavaScript ecosystem, you install one dependency and you have an indescribable mess on your machine.

Kevlin Henney: Yeah, there's a phrase I heard for this one, years ago from Michael Stal, Siemens, was, "You reach for the banana, you get the whole gorilla."

Stefan Judis: You get everything. And the question is, where are we going with that? Because security is a bigger thing. In my talk, I will quote statistics that of all the websites out there, 60% of them are actually shipping with security vulnerabilities. And it's just because the ecosystem right now is “Package, package, package,” for developers, at least in my ecosystem. This means I can make a lot of ground in 10 minutes. I just installed 10 packages and can move it along and ship it, right? But if people are not updating it and not understanding what they're doing, I think there's a big risk in not shipping good things to the web.

 

How did we end up here and where to next?

Lars Jensen: Yeah. So who do you think has the responsibility for this? Is it the individual developers? Or is it NPM, the package managers? Is it the Java ecosystem at large?

Kevlin Henney: I don't think there's an easy answer to that. I think ultimately, everybody has some kind of responsibility. Tool vendors and site providers have some kind of responsibility because they're providing a user experience, in essence. I actually find it interesting enough that our language has devalued the value of certain things, we often refer to things as like, "Oh, that's just a repository. It's a repo." A repository is a place you dump stuff. I want something a little more active and intelligent. Somebody is providing me with a kind of service. I wanna think of it from that point of view.

And therefore, as a developer, I'm gonna have an experience. I am a user of that and therefore what's my user experience? So I think it’s all along the chain. You can't be responsible for everything. But there's something you can probably add or a question you could ask that perhaps you didn't ask before. And collectively, again, it's these little nudges, I think that that could make a bigger difference. I don't wanna say you the developer are responsible for everything, but because of the way that we structure things these days, with all of the dependencies, perhaps we should look at things from the point of view of supply chains and supply lines.

And there's somebody who's gonna be more customer-facing than everybody else. And unfortunately, at one level the buck does stop with them. Because when, as a customer you say, "Hey, look, I've got this problem." Occasionally where I live gets incorrectly classified. The postal address is a very small thing. I get listed as living in a county that cease to exist at the end of the 20th century. It has not existed for a quarter of a century, there is no County of Avon, I live in Bristol. And then you can't go back and say, "Oh, by the way, your data is not up to date. That county doesn't exist, that's not a real county." And they say, "Oh, well, that's from our data provider," as if that's not their problem, but this is the county. And it's like, "No, it is your problem. I'm getting a service from you. And you're telling me you don't have good data. That's what I'm hearing. What else is not good?"

So at one level, there's a confidence thing. But another level is, unfortunately, you do kind of have to take some responsibility there. So I think if we're able to move the needle from zero to something and don't worry about that we've all got to be responsible for everything, I think that will make a significant difference.

Stefan Judis: Yeah, I do agree that it's probably also engineering culture in certain companies. I work in a typical software as a service company and there are 50 to 100 engineers, I won't move the needle. But it is kind of lobbying for, "Hey, we want to ship fewer dependencies, we want to update everything, we want to have good security in place, we want to have a good user experience." And these kinds of things have to be decided collectively so that everybody is moving into the same direction,

Kevlin Henney: And moves it from the individual. I think that's a really important point because that's also where we learn. You know, that's one of the great things that humans learn by imitation, it's one of our great strengths and our great weaknesses. But you know, it gives us useful stuff like civilization, writing systems and stuff like that.

Stefan Judis: Numbers.

Kevlin Henney: Numbers, yeah. We were talking about numbers beforehand. But these things, they're not always perfect, but that's how they get spread through. And that's that cultural osmosis. You see it very positively in some locations. If a developer starts working there, they acquire certain habits, not through conscious effort, but because of the culture. But the opposite can also be the case. So, therefore, there is a collective sense. An individual can try and swim against the tide. But really, the question is if you have the right culture, then that's gonna lead to this, that you're raising questions about systems and just moving things gently in a different direction.

But yeah, there's the human bit now. We love to point to code. Here's a box, it depends on this box, let's work on these things. But it's all the fuzzy stuff, that people stuff. The most complex system in any software system is the humans. And we keep pointing at the screen going, "That's really hard." Yeah, you should see what's on the other side of the keyboard.

Stefan Judis: For sure. I do think there was a lot about education. And this is why conferences like this probably matter because these conversations have to happen inside of teams, inside of companies. I want to believe that we ship and we develop things with a good user experience. This is what, at the end of the day, I'm paid to do. I'm paid to code things for certain people. And for that, we need to have a certain level of understanding, what does it actually mean? Does it mean that we ship new features quickly? Maybe. Does it mean that they're secure? Maybe, but all these kinds of things have to be on the radar of engineering managers, of developers. And this is where this cultural part comes into play so that we are all running into the same direction.

Lars Jensen: Right. I think some of the arguments that I've seen is that maybe the building blocks that we use very frequently should have more responsibilities. I think what happens right now is that you start a React application or a Vue application, any framework of the week, you unknowingly get all of their dependency graph along for the ride, right, without necessarily knowing. And maybe they should be more responsible in implementing more things themselves instead of depending on things that depend on things that depend on things. So maybe having some kind of verification process that yes, this particular framework has been a good citizen, so to speak.

Kevlin Henney: Yeah, I think that that makes a certain amount of sense. But also, we have within reach the same feedback loops that allow that because a lot of these things are indeed open-source. And so, therefore, there is a feedback loop there. And one of the points I made in my talk was that people often talk about this idea of, "We learn from failure, we learn from our mistakes," and actually, we don't. History suggests that this is not as common as it should be. We can learn from them. That's different a statement. But that requires a little bit of effort. Sometimes we have to go in and go, "Oh, I wonder what we could do to change this?" And one of the examples I didn't include today was the Left Pad incident in 2016.

Stefan Judis: That's a good one.

Kevlin Henney: You know, it's a good one because it's a textbook. It's very, very simple to run through and see the chain reaction of effect go into play. And it raises many, many different questions. And I'm not entirely sure that we've all learned the lessons of that. Because of the growth rate of JavaScript programmers, the statistic is that the number of people who are currently programming JavaScript is many times more than actually know about the NPM Left Pad event in 2016. And that's a really simple public example that reveals many things. It's not subtle. There's not a complex case study here. It's really simple. And it kind of highlights like, "Yeah, we should be more aware of deploying things not quite as dynamically. You shouldn't pull it off the way."

You should say, "Here is what actually goes live, we control the boundaries of this." But also within that saying, "How clean are our dependencies here? What are we pulling in? Are we pulling something in that's actually a simple coding problem? You know, let's try to have our frameworks and our services off of the things that are the hard things and not just try and pull in small bits just because it has a dependency”. It's like, "Actually, you know, that's a simple coding problem that could have been done in there, it could have been self-contained." And that idea, I think, is simple self-containment. You don't wanna end up with “We provide you the whole platform and everything was written by us”.

So somewhere between these two extremes lies where we probably want to be. And that's enough that a developer could individually say, "I can account for our dependencies, I know what we are running." And a simple statement like that would be I think, such a great move. At that level of knowledge, we're on most of the way to heading in the right direction.

Stefan Judis: Totally. I was discussing that with the maintainer of the Preact framework two years ago. Preact is this React alternative. I was just building a side project. And what did I do? I used Cloudflare workers, set up a JavaScript framework, I got into this whole tech bubble, installing everything. And then I was like, "What are you doing? All you need is a hamburger button that opens something and closes something, right?"

And I spent already three days "crafting," crafting this software here for this hamburger button. I started chatting with the maintainer of Preact and he was like, "Yeah, well, Stefan, you were right, that's not a use case for this framework." And ideally, eventually, we as framework maintainers offer you a way to not think about that, but rather tell you, "Hey, look, you have interactivity for, like, two events, you don't need a framework here right now." And that's a wish, right? Maybe we end up there that framework maintenance eventually will give the developers that have not much experience yet, the solutions on a framework level because this is what people will do. NPM Init, NPM Install, whatever. And we won't change that. I don't think that that's gonna change. It took even me a few days to realize that I'm doing entire nonsense here.

Lars Jensen: Yeah, I guess we have a tendency to reach for the most advanced tool possible. I guess the real-world equivalent is like, I think I need to dig a hole in the ground. Let me go get the excavator, instead of starting with a shovel.

 

What do yogurt and code have in common?

Kevlin Henney: I need the most general purpose thing. I think that's the story we tell ourselves. That is a point that I made in my talk just now. I sort of said that we often talk about, you know, "We got to generalize this and generalize that. But look customers don't have general problems, they have very specific problems." They already have a universal computing machine. Here is a machine that can do anything, they don't want to do anything. Of all the universe possibilities, what they want you to code up is a narrowing of the possibilities that it does this."

That's not to say we cannot find generality within that. But so often, we think the generality is the end goal, rather than, "Okay, let's take it to: What do they actually want?" And then take a step back and go, "You know what? I've seen this before. Actually, the way I've written the code, I can simplify it. There's a generalization that I had missed previously." Again, that goes back to the softness of code, and I want to give myself that opportunity. People don't want general stuff, but we tell ourselves they do. And so we go, "Yes, we're gonna need all the scale." It's just like, maybe you will, but maybe you won't. And then what happened? What have you brought on board? What cost are you paying?

There's a trade-off here. The English word trade-off actually works quite well here, but to the point it becomes invisible, we forget it's a trade. I trade something in order to get something else. So what's the quality? What is the thing you're giving me if I trade the simplicity of my code or I trade the obviousness? In other words, everything that you need is in this piece of code. Well, actually some of it's brought in from outside. Now, that's not yet a good thing or a bad thing. What's the trade? "Oh, you know what, when we did this, it saved us so much trouble. We could deliver faster, we were shipping fewer bugs, we wrote less code to achieve the same things." That seems like a good trade.

You've, moved the balance of the code a little bit outside your codebase, a little bit outside your control, but you're trusting somebody else. And the benefit is, "Oh, yeah, there's a clear trade. That's a good trade." The problem is, I don't think we're doing that a lot. We're giving up an awful lot. And then in return what are you getting? Well, yeah, we're shipping half a megabyte of stuff with every simple request, and we have no idea what our dependencies are and we keep getting vulnerabilities reported. So the point is, I'm calling it a bad trade. It's like we give this and then more is taken.

In other words, I think that we really need to get into that work and say, "Okay, there is a trade, every little decision is like: Which side of the line does that fall on? What am I getting if I do this? And what am I getting if I don't?" And to think of that, just pausing again, we may say, "You know, I'm not at this stage where I need the machinery of this framework. I can't justify that. I can show something to a customer right now and it's gonna be good enough for our conversation at the moment." Maybe they got visions of scaling in a couple years' time, and all the rest of it. But let's just build up. Let's sense our way and pay attention to what we're doing. And then make some point that nudges us to say, "You know, what? Now is the time, and maybe the framework we had in mind is not the one that we should be doing. There's something else that solves that more specifically”. I guess all I'm saying is slow down, we need to learn to slow down.

Stefan Judis: Yeah. And be aware. I like the idea of a trade. It is like, sit down, consider your options, and don't go necessarily always with the default path. Don't go with the latest and greatest, the cutting-edge thing. Maybe it's not needed at that moment in time, and maybe you don't have the skills to deal with it. Now, what I see a lot of times, it's that people just want to play with tech. And there's nothing wrong with that. But maybe not when it's a commercial product that is going to customers. Maybe that's not the right situation.

Kevlin Henney: And I think the trade is also something that its value changes over time. What was a good trade-off last year may not be right now. That doesn't mean you were wrong last year. I think we like the idea that it's a simple thing. It's like, "Oh, wait, we took a decision. And that decision is somehow timeless and forever." It's just like, "No, actually, the world has changed around it in technology, but also in the business." That was a good thing, that piece of code was good for the world it lived in. And that world's gone. I think that we take a very simplistic view. I see it when people are talking about how to manage technical debt or legacy code. Half the time they're saying the code is bad. Actually, no, it isn't bad, it was good. But it's not it that has become bad. It's the world that's moved around it and the code has stayed the same place.

The trade-offs that it made are no longer valuable. Somebody did certain things and I deal a lot with people at the backend where the nanoseconds and the megabytes matter a lot. There are all kinds of trades we make at various points that just a few years later are like, "Yeah, we've got more memory, or we've got multi-core that it was only quad-core when we wrote the original code." But now all of this stuff, it's changed the landscape. And all of those trade-offs, we did every single thing for the right reason, they no longer matter, but they add complexity to the code. That's the cost we're paying. And we're paying, we're not getting anything in return. So it doesn't mean it was a bad decision. It just means we need, again, it goes back to that awareness. It's just that you got to watch out that the things that you thought were solid that may not be any longer. Things have changed.

Stefan Judis: Maybe not. Maybe it was good a few years ago, but maybe there are better solutions now.

Kevlin Henney: Before I came to demo here this week, I can tell you about my fridge. There is some yogurt. Now, that yogurt, when I left, was good. When I return home, it is entirely possible that I may need to throw that yogurt out. Now the point is that doesn't mean it wasn't good, it doesn't mean it never had value. But there is a point and we are used to this in other walks of life. Things go off, they have a best before or sell-by date, and we even have it with some of our devices and our technology, credit cards have an expiry date, and so on.

Kevlin Henney: We have the idea that something is not always forever, that there's an opportunity that we may want to revisit it. And I don't think we have that idea with code or decisions, the idea that that decision was good, maybe we want to revisit that because, the nature of the business, the nature of the technology around the ecosystem we've drawn in may make this no longer relevant, and it may make it actually a problem. And we should think that that is normal rather than, just accumulating, going back to what you were saying, people accumulate. And again, that's a culture thing, they learn to add. I think a lot of what we are missing is the art of removal, and it exists in other parts of our lives. So it's not like we don't know how to do it, I think we just haven't framed that in the software space.

Lars Jensen: I think that's a good point. I very much agree with you that I think it's a good habit to be deliberate about the dependencies you do take on. A metaphor I usually think about that might be fitting, might not, is that taking onto dependency is a little bit like adopting a puppy. You should consider, do I want to look after a puppy? Is it potty trained? Will I need to put it down eventually? Instead of just needlessly adding dependencies, think about the trade-off, as you mentioned.

Kevlin Henney: And what you're describing very explicitly there is a sense of responsibility. People get puppies because they're looking for a certain kind of enjoyment. But there's another side to that, there's this other aspect, you've got to look after it. This code, if we use this framework, it's gonna save us this much time. But what is the other cost? And if anybody ever tries to sell you something, and they never give you any liabilities, or what I think of as boundaries, every good idea has a boundary. It's not universally good. There is a point at which you cross and then you go, "This is no longer the right thing." I apply it to advice as well as to code. “This advice does not apply universally. It has a boundary. Inside here, it's really good. That's what makes it good advice. Outside it, we wouldn't apply it”. So our question should always be, "At what point does this become a burden? What is the trade that we're making?" There are lots of these things. But they're all awareness, they're checks and balances.

 

Duplication and the human instinct

Lars Jensen: How much of this do you think comes from our profession sort of being afraid of duplication? I think, at least in the JavaScript ecosystem, I have the impression that people are afraid of duplicating themselves in code. They feel like if they write the same code twice, that's a bad thing. So someone else wrote that code, I should take it in and use that instead. 

I think a really famous horrible example I've seen is that there's a JavaScript dependency called is-even that checks for whether a number is even or not, then you have the equivalent is-odd that depends on is-even so that it can negate that condition. 

So do you think that we as an industry are too afraid of duplication? Is that a bad thing to write the same code twice? And how does that tie in with taking on too many dependencies because we don't wanna write a code that someone else has already written?

Stefan Judis: It probably depends, I would say. I think JavaScript is a little bit of a unicorn in this context because it just evolved so much in the last five to six or seven years. And there are so many new people coming in. So a lot of people don't know how to write the best code and do refactoring or solve a dependency or how to structure a JavaScript codebase. These are also not trivial questions. In JavaScript, we only have a module system for a few years now that comes in browsers. Before there was a wild, wild west, and people were reinventing and inventing JavaScript patterns. JavaScript is also a very dynamic language for other programming languages I'm sure. I think the NPM ecosystem is a tricky one because there are so many new people that are just developing new things, and they're trying to give the best and they install is-even maybe because they just came from a JavaScript course yesterday. 

Kevlin Henney: I always consider myself a JavaScript tourist for the majority of the time. So I can't say that I know a great deal about the JavaScript culture, except that I do see plenty of duplication, and there's no shortage of duplication. I think that with any culture, you're gonna get certain extremes. And people will learn by imitation. If I come off a course and somebody said, "NPM is the center of the universe, everything you need is there." And then I'm seeing, "Okay, so this is how they do it," because normally you wanna fit it. And if you're new to a culture, you wanna fit in, you wanna do the things the other people are doing. So it's very natural, that's just a human instinct.So we're gonna follow that. 

But I also see it in other cases. We seem to inhabit both extremes. It's like, we are both afraid of duplication and overdo it. We don't seem to have a kind of coherent story about that. And so, therefore, we see both at the same time. I've seen a server-side codebase years ago. A very performance-sensitive, very memory-sensitive, C++ codebase, and I started noticing this code feels really familiar. This code feels really familiar. And I started thinking, "It must be the jet lag." And I just mentioned haven't we already seen this code?

I said, "No, no, no. We've got the same thing in however many places and it's like being copied and pasted all over the place." It's like, "Oh, okay, you know, maybe that's not a good idea." This was an opportunity that you can take advantage of, and yet in the same system, they wrote some incredibly complex code because they even said, "Oh, we don't wanna duplicate that." It's just like, "You're the same people that did all of this." We will embrace this paradox. It's like this idea, like sometimes we concentrate on one thing so hard, we can't see we're contradicting ourselves in another case.

And I don't think it's just different systems. Sometimes it could be the same people who are both duplicating and they're making something complex because they're trying to eliminate duplication, but probably they're concentrating on one and they don't notice the other. So I think it's a difficult one. And I think that that's an area where tooling can certainly help us. A more deliberate approach to reviewing, you know, that episode where I always pointed out, "We do this a lot of times." What it needs is for somebody to go, "That's interesting, why are we doing it? Why are we duplicating it everywhere? Why is this? Is this necessary?” Not everything that is duplicated is necessarily bad. It's just that it should raise the question of did we mean to do that? It goes back to the deliberation in that I'm making a decision here to duplicate this. What is my justification?

And that is just a simple hesitation, a pause, a question that one person can ask of another. And I think that that goes back to this other idea, again, we were talking about this individual versus collective aspect is group intelligence, that is humanity's strength, we also are remarkably good at group stupidity. And we are capable both at the same time, but as a software development team, you can't know everything. Software is so complex, the ecosystems but also the domains that we're deploying them in. But that's why you have people, people plural, not just one, you have group intelligence.

And so perhaps we're not making the best use of that there's more than one brain on this team. And that other brain can probably see things that I simply can't see no matter if I call myself a senior or whatever. And so perhaps we need to get a little better at that group intelligence aspect. And I think that answers the duplication question because when we bring our collective intelligence to bear, we go like, "Yeah, we're trying too hard over here. And actually, there's no benefit to this, we've only used it in one place. But over here, under the radar, we've got all this duplication and the same piece of control flow that we now got to touch in multiple places because we've changed our minds about something.” And rather than taking a step back going, "I wonder why that's the case, I wonder if we can consolidate that," what we're gonna do is say, "Right, I will touch the code in 50 places before lunch, and I will focus on getting that done," rather than, "Hang on, there's something deep going on here. I wonder what that is?"

Stefan Judis: I really like the idea of trades. If you have a bigger team, and one person decides today to copy and paste certain lines and just change one thing, leave a comment there. Because if you ship it tomorrow, there are reasons there, but this person may or may not be aware at that moment in time. I'm trading something around, I have to ship tomorrow, I'm not refactoring 50 places in the entire codebase right now, here and now. But it comes to this awareness part, and you briefly touched on tooling and I think tooling is a big, big part of that. It should be your linters, your something, telling you, "Hey, you have the same five signatures across these files. Should you do something around that?" And tooling plays a big, big role in these kinds of awareness things, to keep the quality high. But just saying duplication is bad all the time? I think it’s the usual “It depends.”

Kevlin Henney: Yeah, it's not enough to point that out. Communication is interesting. And so is the whole thing with tools. There's a book that I edited a few years ago, "97 Things Every Programmer Should Know." And there was a couple of things in there that are interesting because we had both the advices in there. We had the "Don't Repeat Yourself.", the DRY principle in there. Steve Smith wrote that piece. And then we had another piece from Udi Dahan, "Beware the Share," where he talked about an episode where he had removed duplication and it had caused problems.

So, in other words, I had a counterbalance in there because it raises both questions. In other words, you should be asking these questions. It's not a, "Always do this. Never do that." It depends. And we're gonna show you what it depends on. But there's another piece where Keith Braithwaite talks about this idea of the tooling and the idea of historically, as human beings, we extend ourselves. A nail. Our fist is not a good way of driving a nail in, but if I extend the idea of my arm with a hammer, then suddenly it makes sense. And that's what tools are. They're extensions of us, that allow us to do things.

And perhaps sometimes we don't approach tooling with the right mindset in software development. They are extensions of the things that we desire and want. I don't want the tool to tell me what to do. But I want it to point out things that I'm gonna miss. I can only see so many things. I have incomplete knowledge, and I'm never gonna have complete knowledge. I would like something that helps me with that, that helps me work with my colleagues, that says, "You know what? You do have those five signatures. Is this something you care about?"

And then I would like another tool to say, "Okay, here are your options." But you are still driving. You are making that decision. And you're aware of that. But also, as human beings, we can relate to one another. And it's just that maybe I'm not sure, and I go and ask you, and I say, "What do you think? I've not seen this before. I'm not familiar with this codebase." And that is the bit that is very, very soft, but it's the bit that is the driver, and I think sometimes we don't concentrate on that. It's very easy to say, "Here's a framework solution. Here's the thing. This will solve all of your problems. We use this."

Nobody ever puts on the CV, "We use people power. We use people stuff. We use talking.”, whatever it is. And that's the kind of superpower that we have. There are all these things. And our tools are supposed to help us reach further than we simply can and it would just be nice if we recognize that, whereas we seem to think tools define the way of working. They are the universe. No, they extend human reach. Still comes back to us.

Lars Jensen: Just to weigh in a little bit on the duplication part. I think my preference these days is to start with duplication, and then see where that takes me. Because often, I find that abstracting things too early is more harmful. It's harder to back out of the wrong abstraction than it is to abstract something that was duplicated. And usually, it's only once I've duplicated things a few times that I start to see where the abstraction actually is. So I think my usual approach is, to start duplicating things and when I'm about to write the same thing for the third time, that's when I know enough to actually do the proper abstraction. And I think people might have an aversion to doing that. They think that "Oh, I should never repeat myself. It's not good."

Kevlin Henney: Our challenge is to learn what is it that is being repeated? And as you say, it's that idea that sometimes the first time we encounter it, we can make an observation. We can't yet make a judgment. We can make an observation, "Oh, that's interesting. I don't know why it's interesting." An example from a codebase a few years ago. I introduced an abstraction, it was a toke, and then I started thinking, "This doesn't feel quite right. Okay, I'm just gonna replace that with a string."

So I just went back to a string. And then, after a few more days, I started seeing the repetition gathering around the string, the way that it was being used. And it was like, "and now I understand." So I reintroduced a class called Token. But you might say, "Well, you put it back in again." Well, no, I didn't. I put something of the same name in, but now its interface was completely different because now I had seen how I was using it. In other words, it's like you have an idea. You sense there is something here, but I'm not yet sure what it is. I don't yet know enough to commit to the sharp lines of a curly bracket. But, you know, there's something. I'm gonna keep my eye on that.

And it's exactly that. The fact that I put something in, prematurely, took it out, string, and then there's a recognition. "Now I see and understand. I did not understand before." I knew that I needed a thing, but I didn't know what the shape of that thing was yet. You kind of need to let time answer your question for you. And again, we're not very good at that. Because we think, we make that decision, it's good forever. No, give it a week. Give it a couple of days. See how this one plays out. But you've kind of got your eye on it. You've got a watch on it. Just as we have watches and debuggers, maybe we need to have that in the development time as well. It's just like, I'm gonna keep my eye on this. I think there's something here, but I don't know what to call it yet.

Lars Jensen: I completely agree. I think we're getting close to the end, so I'm wondering if any of you have any last-minute questions you wanna ask each other, maybe? Or maybe you saw a funny Kevlin Henney on the way here? What was the last Kevlin Henney you saw?

Kevlin Henney: I've been tweeted a couple this morning. A lot of these are actually operating system startup screens. And supermarkets are increasingly popular these days.

Lars Jensen: Right, with all the self-checkouts. That must cause some new ones?

Kevlin Henney: Yeah. That's a really good opportunity for that one. But no, actually, in my experience from the hotel to here, I did not see anything. 

Stefan Judis: Only construction.

Kevlin Henney: Only construction.

Lars Jensen: Only construction. Lots of that. You know.

Kevlin Henney: Yeah. In fact, all the issues I dealt with are real-world issues. It's like, Google Maps say, "go this way." Okay, no. That's not happening. 

Stefan Judis: Your world was a broken screen.

Kevlin Henney: I messaged my wife I said, "This area will be really nice when it's finished."

Lars Jensen: What about you? Do you see any Kevlin Henney's on the way?

Stefan Judis: I don't think so. But I will definitely check them out right after our conversation here. See if I can bring some into my talk later.

Lars Jensen: That'd be fun. It has been a pleasure talking to you. So I just wanna say thank you for taking the time, and thanks to everyone reading.