Welcome to a new episode of the podcast software testing. Today again an episode from the OOP 2024 in Munich. My guest was just now Kevlin Hennay, with whom I talked about the future of software engineering. How will software engineering run in ten years? Will everything be done by AI? Do we even need software developers? How are we going to work together? We dare to take a look at the glass ball. And don't worry, it's not just about AI. Oh yeah, the episode is in English. And now have fun.
Hi Kevlin, nice to have you here on the podcast. Yeah, cool. Excellent. Thank you that you joined here for the OOP. And you have a talk in the afternoon today, I think? Yes. So I have a talk that I'm doing the end of the afternoon with Frank Bushman. Yeah. And then I have another talk that I'm doing at the end of the afternoon with Frank Bushman. And then I have another talk that I'm doing just solo tomorrow, just before lunch.
Ah, yes, yes. Great. Yes. And I read the abstracts in front of the conference and I saw you had one abstract about the future prediction maybe, or some possible future for software engineers. How will we work in 2034 or something? That's right. Yeah, that's the one I'm doing with Frank. We're kind of doing a little bit of crystal ball gazing. Yeah. And it's the Software Engineers Playbook 2034, so 10 years from now. What will we be doing?
And obviously, there's a lot we could put in that talk, but it's only one hour. So we've actually spent a lot of time deleting slides and deleting content. So to come up with a kind of a smaller core message. Yeah, yeah. So I want to talk about this also here in this episode, because the future is always a part. I mentioned also I'm known as the future optimist. And so I'm very happy to talk about what is your prediction? What is your crystal view to the future of software engineering?
Yeah, it's kind of interesting because I may be slightly less of a techno optimist than I used to be. And I think my view of the future, and I think myself and Frank have slightly different paths on this, which I think is going to make for an interesting talk. But one of my perspectives when I look at the data, it's not going to be as different as people think it is. It's going to be different in kind of look at the current trends, see where those are going. Yeah, there's nothing radical.
There's a few things that are going to kind of shift a bit. All you have to do is to think, okay, if now is 2024, what was 2014 like? If you can remember 2014, what was 2004 like? If you can remember 2004, what was 1994 like? Yeah. I have been in software development for longer than that. And so it's interesting to look at the cycles and then start saying, oh yeah, there are real differences between how I was developing now and then.
And there are also some things that absolutely haven't changed or have just moved very slightly. And to look at those. And so if we look at things like in 2034, I mean, one of the ones that I have been going on about to people is just like programming languages. Yeah. They're whatever you're using today. That is going to be 80 to 90%. If you actually look at the data, when we actually look at the data, the top five languages in use, none of them was developed. Sorry, that's not true.
One of them was developed in the 21st century. Most people are programming in languages that were developed in the 20th century. If you look at the top 20 languages, it's still there. If you look at the top 50, it's still there. So in other words, programming language movement is happening. It's actually really not that big. The languages themselves evolve, but the makeup of the languages, no, not really. I get a lot of people say, oh yeah, but we'll be all...
So if I'm programming native, will I be using Rust in 2034? Actually there's a fairly good chance, but Rust is already at this point over 10 years old. So there's nobody that... There are no languages that were developed in the 2020s that are in the top 20 languages of use at this point. So the point there is something's moving. It's moving much more slowly. If we look at other trends in terms of our development, agile development, or at least the name has become very normal.
The number of people actually doing agile development is still pretty low. I suspect that that won't change 2034. We look at other things, other certain technologies. Some people think of 5G as being the future. I think of it as being the present. So we're looking to 6G maybe. And then we have the other areas which... Some of which are hype driven, metaverse, cryptocurrency, and things like that.
If we look at just the last couple of years, trends on those, those are pretty much crashed as a vision of the future. They will have potentially a place, but it's not going to be a dominating place. There's no evidence of that. Web 3, people have been talking about it for over a decade. By that point, if you look at Web 2, Web 2, within the decade of that term being coined, it was a thing 10 years on from Web 3 being talked about. It's still not a thing. And you know what?
I don't think it ever is going to be a thing. There's no evidence to suggest we're moving in that direction. Cryptocurrencies, central bank, digital currency might become a thing. That's quite credible. The rest, everybody's now kind of... It's not treated as currency. So again, we don't see any evidence of change there. Metaverse is fragmented. I don't think we're going to get a metaverse. I think we're just going to get a few more AR and VR things.
And there are certain niches, some industrial applications and gaming. That's where it's going to be. But is it going to be a thing that people use every day in a deep, immersive sense for all of their time? Gaming. And we already have that. So that's a continuation of that line. But the one everybody wants to talk about is AI. I was saving that one. That's the one everybody wants to talk about. I was waiting for this. Yeah, you were waiting for that.
I just thought I could start with that one now. That's the one everybody wants to know about. And there are reasons to... There are certain things. And the broad application of AI that are, at this point, uncertain in terms of the relationship between AI and big data. And therefore, where did that data come from? What are the legal ramifications of that data? What are the existing intellectual property laws that are being enforced?
And that's currently going through the courts, this question of large data training sets and the relationship to copyright. There's a lot of interesting stuff there. I can't predict the future of what courts are going to do. So I'm not even going to try. But that is something we need to watch over the next couple of years, because that will influence the future.
The question of ethical considerations on how much of a relationship we have with checking the results, particularly when it comes to systems that are automated and make judgments that affect human lives. This is a... This is a question not of technical ability. Anybody who is framing it as a question of technology has misunderstood how people work. This is a question of our involvement. This is a question of what do we want and how do we want to shape that. It's very much...
And I don't just mean we in the development space. That's a broad question. And we should not just let somebody who's a tech bro just tell us what it's going to be. No, we have a choice here. And the evidence is that if we don't properly take the choice... A number of people are going to be disadvantaged because that's the very nature of a statistical based approach to AI. It is not a reason based approach. It's statistical.
And the problem with anything that is statistically based is it represents an image of the past. And it represents the most likely, but that means it ignores edge cases or the things that are seen to be less than a majority. So we need to watch out for that one in terms of the social implications. But I think we already... We're already aware of this. Yes. We're already aware of this. We're already aware of the issues. I just think that that now becomes a thing.
And we need to also see how legislation is going to affect it. The EU directive on this is one of the first. The question is, will it be as influential to the world as GDPR was, which has been hugely influential. And it's not entirely clear that it is. It's been a little bit watered down. It's probably not going to really take force until at least next year and from a practical point of view. Perhaps even 2026. So I think that one is too soon to tell.
But we need to see what other governments are going to do. So is there going to be any kind of international kind of consensus? Or is there going to be huge differences? Because that also tells us something about the future. Yes. But obviously, what a lot of developers want to know is, what is AI going to do for me or to me? Yeah. Will I have a job in 2034? And I made a prediction last year. Actually, I made a few predictions. I'm going to rest on these.
Because normally, I always tell people, prediction is a fool's game. And you are most likely wrong. But so I'm going to very definitely cherry pick the ones that I have got right. In 2016, I was asked a question about AI and the future. And I said, do I think we have a job? Yes. But my answer-- and it was at Moby Conf in Poland in 2016. So you actually find this in the Q&A on the video. And I said, yeah. Developers are going to be needed. The concept of development doesn't change.
All those people who say, oh, yeah, we're going to have natural language programming, and that's going to be fantastic. It's like, you really need to understand history. First of all, you need to understand history. Then, you need to understand language. And you need to go and talk to some customers. And then, you will realize how safe your job is. Because programming is not merely the assembly of syntax. It is the application of precision. It is the seeking of precision. And what is the answer?
What is it that I'm trying to find? And the answer is, yes, I think we have a job. But I don't think we have a job. And I'm not sure that we have a job. But I think we have a job. And I think we have a job. But programming is not merely the assembly of syntax. It is the application of precision. It is the seeking of precision. And what is the answer? What is it that I'm trying to do?
And it turns out that if you specify something badly in natural language, it works out even worse than if you did it in code. And we already know, for example-- we can actually take inspiration from the most widely used programming paradigm on the planet, the spreadsheet. What we know from the spreadsheet. The spreadsheet is that most people who use a spreadsheet do not have a software development background.
Yes. We also know that most spreadsheets are unmaintainable, incomprehensible, and buggy. If we are saying that the future of software development is people who are not software experts doing this stuff, your job is safe. Because that stuff will need to be understood and fixed. That's the first point. Spreadsheets didn't put anybody else out of a job. They actually create opportunities. The other thing is, when we look at-- AI assistants of our work.
And a prediction-- so in 2016, one of the things I said was, one of the things we might see is the balance of our time shifts. But I said-- and I made a prediction back then. You're going to need to get good at testing. Because if you are just going to take the first thing that is generated, and you don't know what it's supposed to do, then guess what? You're going to end up being a maintenance program.
I made that prediction again last year on Mastodon, and I've now managed to retweet that for you. So it's now out there in the written form, last April. And my observation was that most generated AI, the way that programmers are going to use it-- we've seen how programmers use the tools they're given. There is no evidence to suggest it's going to be for the better. The majority of developers will create legacy code. They will now just do it faster.
And so in other words, they're going to take away the fun bit. This is what I think is so ironic. Many developers are going to remove the bit of the job that they enjoy, and they're going to create maintenance code. And they are dealing with code that somebody else wrote. They don't understand why.
And so in other words, developers that go all in on generative AI to create their own code, whether it's a co-pilot level or full-on chat GPT, give me this, are going to discover that they are now maintenance programmers. They've taken all of the joy out of their job. Well done. Have they become more productive? Oh, they'll be making more commits. But this is the interesting thing. A recent study has shown that-- already there is a downward pressure on code quality on GitHub.
The study was done by GitClear. They published it a couple of weeks ago, so January 2024. The quality is dropping already. And that's what's happening. Code churn is increasing. What we're finding is there's more duplicate code, more copy and paste code. The quality of the code is already going down. And this is what I would say is early days. But the code churn, the idea of having to go back to something you just committed because it's wrong, that's increased.
And this is kind of stuff like, if you'd asked me a year ago, I would have told you this was going to happen because I know how people use tools. So maybe we need more developer or more quality-- Yeah, we may actually. Yeah. So that's the thing is that we need to understand what the relationship is. And we also need to understand that for some developers, they are going to get a huge advantage. We know these developers. They are a particular percentage.
When they are given a new tool, they will get the best out of that tool. And most developers will be, through no fault of their own, in an environment that doesn't encourage them to do the right thing. And they won't. It won't happen by magic. And so therefore, what you're going to find is increasing number of bugs, increasing code churn, increasing outages, therefore more focus on the development, but not necessarily learning the right lesson, which is maybe we need to focus on quality.
Maybe generating the wrong thing faster is not the end game. Yeah. And I think that by 2034, some companies will have realized this and will be acting on it. Those companies will be doing very well. Most companies won't have that and will just be micromanaging people or putting a lot of pressure on people. And the danger is actually software development in some companies may become very unpleasant. I don't think it's going to be a job that disappears. It may change.
But I think unless we properly observe this, it's not going to be good. So yeah, software development is not going to disappear. I think it's going to splinter. And there will be a real difference between people who work in the quality environments, understanding what it is that they're getting from any tool, which has always been the challenge. And then there are people who are going to be, as it were, puppets of the tool and very poor management processes.
So that's my personal prediction on that particular one. I think we have to mention that the software industry and the IT industry is an industry which has... Has reached a part, they're always creating new jobs and new needs of their job. And I think this won't stop in the future. So the software industry will still get... Need the impact and get new people there to do this stuff. The world runs on software. That is not going to... That's not going anywhere. And the idea...
I'm not going to say it's never going to be a case where somebody is not able to articulate a business need and then have a meaningful interaction with something that's AI. But that's not the AI we have now. That is going to be... That is at least a decade off before people start doing that because that's not where the money is. That's not where the conversation is. It's certainly a possibility, but we're a long way from that. And the need for software is not going down.
So yeah, I think that is relatively safe. What I've been telling people is, you know, your skills at being precise. Your skills at being able to test and your skills at being able to ask the right questions. What is it we're actually trying to do here? Those have always been there. But now we're going to realize that they come up... They're much more obviously the stars of the show. And that's where your skills are.
And honestly, knowing how to work with a programming language or programming languages is still absolutely relevant because those are very different to working with natural language. And that's the bridge that we've always... We've always crossed the ability to work with the kind of the soft, flexible space of humans and business and then say, and this is what we need. And to do so in a concept and notation that is utterly precise and fixed and be able to say, yeah, that's exactly what we meant.
And importantly, we get the same result every time. That's really important. And I can... And importantly, it's empirical. I can show you that. Here's the tests. Yeah. And here's the data that we see from the runtime. All of those things, they're not going anywhere. And if anything... And if anything, those are the ones that are going to differentiate individual developers in terms of skill and also companies. That's where the competition is.
Yeah. What do you think about collaboration in the teams and in the organizations? So we are struggling with Agile doing stuff together, interdisciplinary teams. And so it works sometimes, but not often. What do you think... Where will the trend go on here? I think that this is an interesting one because we have a very much a mix. And this is something that we have some companies and some organizations go in one direction at the same time as other companies going in other directions.
So if you go back many decades, software development was done inside of the companies that were using the software. Everything was bespoke software. And the distance between the business users and the developers was naturally short because you were in the company where you were actually developing the software for. Of course, it wasn't the kind of software that we have these days in terms of scope, but it gives us one baseline.
But in the same era, we also had large companies, institutional-style companies that definitely kept the software. They developed software for other people, whether it was governments or whatever, at scale. And guess what? We still have that, but we also have a lot of spaces in between. So what we find is that companies, there's the natural agility, if you're in a small company. You have the natural agility you just get by being in a small company.
If you are in a company where you are providing software to people in that company, you have an advantage over people who have an organizational boundary. But also, we outsource more. So we introduce more organizational boundaries. And therefore, we need to get over those. So it feels like there's a constant churn and renewal that some companies are constantly being created to serve the needs, the software needs of other organizations. But they're outside.
But agility is about getting as close-- it's about reducing the distance and communication distance. So we both increase and reduce it or find the need to reduce it. So I don't think that's going to change in that sense. I think we are constantly doing that. But I think we have many more smaller companies and perhaps a faster turnover rate of some companies. But we also find companies that are large.
And for them, agility means, oh, we used to be four layers of management before you could talk to somebody. Now we're three. Now we're four layers of management. And that's just like, OK, you guys have still got a long way to go. But I think that pressure is always there. And I think that what we have seen in the last decade, particularly as more companies find themselves pulled into a much more continuous deployment situation, is that the downside of that is a lot more pressure individually.
It's the kind of pressure I was talking about earlier on. You end up being micromanaged. Now it used to be micromanaged on a monthly basis. Now it's on a daily basis. Yeah. And that can, if not understood as a properly collaborative environment, that can actually make for a very unpleasant feeling. And you're constantly just bombarded with deadlines.
But at the same time, I also have some optimism here that I think that when I look at other industries and other disciplines, I think in software, we talk about people issues a lot more than people in other disciplines. I think although we have this reputation-- and I think it's a reputation that sometimes, sometimes other people hold of us, but we also hold it of ourselves. I don't think it's true.
I think we spend a lot of time talking about the people stuff, more so than many other industries, particularly technical ones. We tend to value those. We see it as a problem or a systems issue to be understood. And you find that the fact that business movements now come out of software, rather than software being the consumer of business movements, is now the producer of ideas that transform other companies that don't consider themselves to be software.
You go out there, and people are quite happily using the term "agile" in the broader business context, where it simply didn't have any meaning or traction many years ago. And we see these ideas going out. So I think that we're actually in a very good position. So I have a little bit of optimism there. I don't think it's all suddenly going to change overnight. But I have some optimism there that I think that we focus on people issues probably a lot more than a lot of industries do.
Yeah. Thank you. It was a great, great thought on this topic. What would you recommend for a QA tester, software engineer to learn and to prepare for this future? So I think it's a case of-- whenever I've been asked this question, I think my answer is generally always had the same core. And then the dressing is slightly different. So let me focus on what is the same core? The foundations. There are things that are much slower moving.
The foundations, the principles, the deeper skills, the idea that-- what is it that we want from this software? And that's a high level question that we frame in terms of requirements. But to understand how to test something is to understand what it should be doing in the first place. There's a cycle between these. There's a natural cycle. Get good at that. Get good at describing. And describing both in natural language. But also in code. What does that look like?
What does the right thing look like? What does the wrong thing look like? Programming languages, they're not really going anywhere. They are going to continue very much along the trends that we have seen for the last decade, two decades, and so on. There's minor shifts every now and then. But nothing huge. So you're OK with whatever you're working on. But keep a look at-- if you're using one of the top 10 languages, well done. Keep using it. What's in the next top 10?
Look to the rest of the top 20. Because that may be where the language that will be your primary language is coming from. The language that you'll be using in 10 years' time probably has-- I put very good money that it has already been invented and already has some kind of presence, if not in the top 20, the top 50. But also have that idea that you're not just stuck with one language. Many people characterize themselves, I am a Java programmer. I am a C# programmer. So take a step outside that.
Say, yeah, that's the language I'm using this year. But look around. You're obviously using lots of other languages. Give those first class status as well. Yeah, I mean, that's JavaScript as well. So give them first class status. So those core skills there. Understand that the tooling that you're using today is probably, the tools move surprisingly fast in some cases. Some are very slow. Some are very fast. And, you know, if you go back 10 years, Kubernetes, people will be like, what?
But at the same time, if you're in the JavaScript space, hey, guess what? JUnit was developed in the 20th century. So some things don't change. But there are the idea that many of the tools you're looking at, they're going to improve. They're going to change. And you move job, you may discover there's a different tool ecosystem that has become popular where you are. Look to open source. Open source is where a lot of these ideas are coming from.
So I generally tell people, you know, keep your feet on the ground. Look for the foundations. What are the core principles? What are the good ideas in software development that have stood the test of time? And then what are those skills as related to me? And then what are the exciting new bits that I can hold on to? Where do I find them? That would be my general advice. It's a bit of balance. Yeah, yeah. Thank you very much for this tip. I think the community will join it and go on to it.
Yeah, so we are already done with the time. But I thank you very much for this insight, for your thoughts about the future. I'm very satisfied now. I have some things I think about the next days. And I wish you a very good conference here and good talks and a good time here. Thank you very much. Thank you. ♪ ♪ you