Navigating Through Programming's Greatest Mistakes

Programming’s Greatest Mistakes

Hannes Lowette: Well, hello, my name is Hannes Lowette, I work as head of learning and development for Axxes, and I'm here today with Mark Rendle. And we're here to talk about programming mistakes. Mark, can you introduce yourself?

Mark Rendle: So, hi, I am Mark Rendle and I am a software engineer and speaker. I do kind of lighthearted, funny talks such as closing keynotes and lock notes and things. I am also available for children's parties.

Hannes Lowette: So your talk that you're doing here at GOTO Amsterdam is about Programming Mistakes.

Mark Rendle: Programming's Greatest Mistakes.

Hannes Lowette: Programming's Greatest Mistakes. Now, I can interpret that title in several ways, either they could have been mistakes made by programmers, or they could have been mistakes in things like language designs, or it could have been stuff that we used software for that we maybe really shouldn't have, right?

Recommended talk: Programming's Greatest Mistakes • Mark Rendle • GOTO 2023

Mark Rendle: Yes.

Hannes Lowette: So which angle are you attacking the mistakes from?

Mark Rendle: It's mostly the first one. So it's mostly mistakes that have been made either by programmers or sort of someone involved in the software development process. And for most of them, there's a dollar value attached, and then there's also a couple of things where it's kind of...and then people do this when they are programming or there is a tendency to do this, and that is a mistake as well. And, you know, ending up with a particular programming language, a script, and, yeah. But, no, mostly it is just kind of like so they were doing this and somebody got this wrong and this is what happened, and this is how much money that costs.

Hannes Lowette: Right. Because we've all made mistakes, right?

Mark Rendle: Yes. And I put a couple of mine in there actually because I don't wanna be kind of going, oh, look at all these idiots. And so actually the first one that I talk about is something very, very stupid that I did once.

Hannes Lowette: What was your own worst mistake, so to speak? I mean, I have a couple from myself in mind, but...

Mark Rendle: So the one that I talk about in the talk, and I probably won't go into it too much here because of bad language, but also it's gonna be recorded so you can watch it on the GOTO channel is about a piece of software. Someone said, "Write this piece of software," and I gave it a name with a very rude word in it, and then somebody accidentally released that to a customer with the rude words still in it. And I was just kinda like, yeah, okay. But that was just a whole unprofessional kind of thing.

Hannes Lowette: Right. It doesn't strike me as something that has cost a business a lot of money unless they lost a customer because of it.

Mark Rendle: The one that I look back on and just kind of still go, ah, was I think I was 17 very, very early in my career. And we were at a customer's site, and this was in the days of Unix, like pre-Linux, '90, '91. And I had a laptop, when this is a huge great thing with the old, sort of very slow LCD and everything and there was no graphical user interface. You had multiple consoles and you could switch between the consoles by pressing ALT and F1, F2, F3, F4, F5 and so I had a console open, we had a new version of the software on the laptop, and we had the live customer system and I was remote-shelled when it was just RSH, there was no SSH, it was just RSH. And so I was on the customer's actual production machine.

Hannes Lowette: On one of your eight.

Mark Rendle: On one of my eight consoles. And so I had to copy the database file, and this is in the days of CI SAM. So it was just a .dbs file that was it into the laptop so that we could do testing and make sure that the new version of the software, the database. I just kind of went, okay, so right. I need to clear this one out. So rm -rf bin 3.dbs, hang on. What console am I on? Who am I? Oh.

Hannes Lowette: So you dropped the entire database?

Mark Rendle: So I dropped the production database. This was at about two o'clock in the afternoon. Which wouldn't normally have been that bad, but they'd hired four temps to do data entry, and so they'd had four temps doing data entry for five hours solid. So they lost 20 hours of people typing in all this data. So that was fun, but, yeah, you know.

Hannes Lowette: It reminds me a little bit of where...I once worked for a company that made marketing software and part of it there wasn't an online component to it that we got from a third-party supplier was my responsibility to set that up. I was setting it up for a new customer and well, because we had customers all over the world, I took a copy of another customer that was using the same language and a similar color design. It was also his biggest competitor in the region where he was located, right? Ah, so I took a copy of the other customer to start my configuration and part of it was a sync job that had to sync between their on-prem system and the online one. And the default used to be that the welcome emails to my customers' customers didn't go out by default. So what we would do is we would enable the sync and then send out the welcome emails after everything had been set up properly. And our supplier had changed that default, and I didn't bother to check with them. So I enabled the sync, and the sync had finished by the time that we noticed that the welcome emails had gone out in the email template of his biggest competitor with the brand of his biggest competitor in the emails, 60,000 emails.

Mark Rendle: Yeah. That's bad. That's worse.

Hannes Lowette: So that's my biggest fuck up.

Mark Rendle: That's worse than mine. That's worse than mine.

Hannes Lowette: Yeah. Sounds like it.

Mark Rendle: But even that sort of pales into insignificance when you look at some of the things where a programmer at NASA, or the European Space Agency, or Boeing, or whatever when they make a mistake or...

Hannes Lowette: There are lives at stake, and there's, like, very expensive equipment that can burn up and...

Mark Rendle: Because the talk is kind of lighthearted and it's just me making jokes and taking the mickey out of people I specifically don't talk about airplanes, medical equipment, or any time that a programming mistake has killed people. But when I was researching the talk, there have been a lot of times when programming and I didn't think I would want to write software that had the potential to hurt people. So, you know, like guidance systems for autopilot systems for airplanes, there was a particular I think it was a medical scanner which gave, like, thousands of people a lethal dose of radiation before they realized it was happening because it was lethal, but it was kind of, in three months you are going to develop tumors, right? And so in three months, you can see a lot of people. So, yeah, I don't talk about those because I don't want to depress or upset people.

Incorrect Code, Measured in Wasted Time

Hannes Lowette: How about like, let's take a more lighthearted angle on that. How about we calculate like time wasted in lifetimes? So if you do something that wastes a lot of people's time because of a decision that you made in software, that also has a price tag. It's not a dollar amount, but it's like...

Mark Rendle: That could be quite interesting if you...

Hannes Lowette: I know that Tim Berners-Lee, always regretted the http://www URL prefix because, it's like, it doesn't need to be there.

Mark Rendle: Yes. Because that's the thing about the internet that wastes people's time.

Hannes Lowette: Well, at least, like, just me saying that to you.

Mark Rendle: Yes. Certainly, I mean, the...

Hannes Lowette: I mean, all those little bits, all over the world, it adds up.

Mark Rendle: The http://, the www always annoyed me because for some reason they decided that the letter W was going to have three syllables. So it's easier to say world...

Hannes Lowette: World worldwide web.

Mark Rendle: It's quicker to say worldwide web than it is to say www. But no, I would like to know how much time has been lost because Windows decided it was going to reboot itself to update and people haven't saved their work because I think if you added all that up, that's probably hundreds of thousands of hours that's been wasted.

Hannes Lowette: A couple of lifetimes at least.

Programming Pitfalls In Finance and the Dark Side of Digital Markets

Mark Rendle: Yeah. But no, the talk, it's kind of this spacecraft blew up and it cost this much and this building collapsed and it cost this much to fix it. And this hedge fund lost an eye-watering amount of money in...

Hannes Lowette: Because of trading?

Mark Rendle:...three hours Yeah. Automatic trading. Yeah. And it's interesting there because this was the error in programming that caused the problem, but you can also discuss whether, like you mentioned earlier, the thing that they are doing, is that a thing that should be done.

Hannes Lowette: Exactly.

Mark Rendle: Because,  these days there are entirely autonomous little algorithms running inside servers, inside the data centers of the New York Stock Exchange, of the London Stock Exchange, and so forth. Just executing trades milliseconds apart to try and cream off .0001% of a cent which because it all adds up over a day, they can do hundreds of millions of dollars of trades and so those fractions of a percent of a cent all add up to real money.

Hannes Lowette: I don't know if it's an actual thing, but somebody was explaining to me that if you wanna go into day trading one of the things that you can take advantage of is when the algorithms overreact to a certain evolution in the stock price, you can take advantage of that because you know that like all the algorithms are selling right now. So it's for me, the time to buy and when it corrects itself and goes back up, you sell when it goes back up and you make money on that.

Mark Rendle: Yes. Although I have to come down sort of on the side of the whole trading thing now, it's gone rotten.

Mark Rendle: The very concept of trading because, you know, stock markets was originally a way for people to raise money...

Hannes Lowette: Raise money for companies, and invest in other companies.

Mark Rendle: ...and build ships. And that sort of thing. And now it's become, like, an autonomous algorithm.

Hannes Lowette: A virtual thing to make money for people who already have money.

Mark Rendle: Exactly. And it doesn't contribute anything to society.

Hannes Lowette: No. Well, no. Probably not.

Mark Rendle: And when I talk to people who disagree with me, they just kind of go, "Well, what does Xbox or Facebook contribute to society?"

Hannes Lowette: Or Bitcoin?

Mark Rendle: And I have to kind of go, oh... Well, certainly Bitcoin. Yeah. I mean, Bitcoin there's a version of the slide deck somewhere that just has a single slide that says, "Bitcoin" and the idea was I was just going to do it and then just stand there and not say anything, and then just move on to the next one because, yeah, that's just a ridiculous mistake...

Hannes Lowette: Would have been funny though.  It is one of the things that I have mixed feelings about is not Bitcoin, but blockchain technology. I think it's a beautiful solution to a problem that...

Mark Rendle: Doesn't exist.

Recommended talk: Build Software Like a Bag of Marbles, Not a Castle of LEGO • Hannes Lowette • YOW! 2022

Hannes Lowette: That nobody has. It's like technically and theoretically, it's blockchain and the distributed ledger and all of that. It's like, okay, this is a great solution. And whenever I have seen it applied, my thought has been, this could have been done so much simpler.

Mark Rendle: The issue with you can do a distributed ledger where you don't need millions of GPUs trying to guess. That is the proof of work. I mean, you can still do proof of stake and it takes the compute factor out of it.

Mark Rendle: But even proof of stake, I mean, proof of stake is I have enough money to take over this thing. And there was that thing quite recently, a guy gained the system on a particular blockchain that gave him more than 50% of the voting rights then voted to give himself all the money. And then I think he borrowed money from people on this thing where you can borrow like cryptocurrency for five minutes and then it automatically reverts to the people. So there is no risk for them to lend you the money. And so he borrowed this enormous amount of money, used it to vote, to give himself all the money in this blockchain, and then it reverted and he just had all this Ether or whatever it was. And then all the other people who have got that sort of in that organization, that's suddenly the point at which they want the FBI, or Interpol, or whatever to get involved and regulate the unregulated currency because it turns out when code is law, you can do some horrendous things. Yeah.

Hannes Lowette: It's one of the things that I've always found suspicious about the whole NFT scene as well because we're artificially inflating the value of a digital proof of ownership, literally. And, like, whatever it's worth is what anybody pays for it. But you can sell an NFT to another account made by yourself, so you'll buy it for 200 euros and you'll sell it to yourself for 75,000 euros.

Mark Rendle: I think they call it washing or something.

Hannes Lowette: Yeah. So that 75k goes from your pocket to your pocket, so you don't really care, but, now, you have artificially inflated the value, the perceived value of your digital proof of ownership. And then you'll sell it for sheep for 30k or whatever and there was no regulation at all.

Mark Rendle: No. And I think we've pretty much established at this point that whether the Bored of Ape Yacht Club knew it or not, the main reason people were buying and selling pictures of monkeys was that they were laundering drug money.

Hannes Lowette: Probably.

Mark Rendle: So you're not the pioneers of a new era of digital creativity, you are Jason Bateman in Ozark or Ozark or wherever that's pronounced. And so, yeah. But no Bitcoin, that's a mistake. Yeah. 

JavaScript: A Game-Changer or a Programming Mistake?

Mark Rendle: And then I have JavaScript in there.

Hannes Lowette: Sure. I mean, you don't have to preach that to me.

Mark Rendle: Well, yeah. And the thing with JavaScript though, I don't think JavaScript itself is a mistake. And what I say in the talk is that if you know that sort of, if you had a time machine and you could go back and fix one thing, and I would go to Netscape six months before..

Hannes Lowette: JavaScript was released.

Mark Rendle: ...they told to Brendan Eich to create JavaScript and just, you know, in about six months, Mark Rendle's gonna come and ask you to create a scripting language to put it into the browser.

Hannes Lowette: And build it properly.

Mark Rendle: So I'm giving you a start working on it now and design it properly. Also, they're gonna ask you to make it look like Java, don't, stick to scheme. Then just come back and see what the internet looks like.

Hannes Lowette: I mean, it is a similar story to VHS versus Betamax. Like, you have a technically superior solution, but something becoming ubiquitous in the market dictates what everybody is going to use. And JavaScript is a perfect example. We use it for everything and kinda runs everywhere as well. And we even have a song about that, don't we?

Mark Rendle: We do. We do.

Hannes Lowette: We'll play it tonight at GOTO, but you as the watcher of the video, you're not gonna see that. And it's all in jest because it's probably one of the most used and most popular programming languages at the moment. JavaScript is in no way still the language that was in the beginning as it was released in Netscape.

Mark Rendle: Oh.

Hannes Lowette: It has evolved to be something much more powerful and much more workable, but some of the remnants are still there, right?

Mark Rendle: Yes. But I remember, you know, that photo of [removed] The Definitive Guide and [removed] The Good Parts...

Hannes Lowette: Next to The Good Parts.

Recommended talk: Programming Language Stereotypes • PJ Hagerty • GOTO 2021

Mark Rendle: ... I took that photo and tweeted it back in 2010, 2011, and it went viral with 45,000 likes, and I went from like 100 followers to 1,500 followers overnight. But, yes, JavaScript today, there are two good things about it. One, we now have evergreen browsers and so apart from Safari, there's much less weight, this is the new standard and now it works in Edge, Chrome, Firefox, and Safari. But, you know, so now we can use arrow functions just natively. We don't have to worry about running it through Babel, or TypeScript, or whatever and there's a whole bunch of stuff in there that we can use and make work. But I think the thing with JavaScript at the moment is the ecosystem around it, particularly the front end. So React, and Vue, and Svelte, and Astro, and NZXT, and Next, and all these different things. Whether each of those individual technologies is good or bad, and whether, you know, React is at a large download size and can use Preact instead, does Svelte have better performance and a nicer developer experience, and all that sort of thing. But I mean, the fact...

Hannes Lowette: Every one of those frameworks has been invented to scratch a particular itch that has an alter head. So I would argue that they all have a reason for being,

Mark Rendle: I mean, React is interesting because they invented it to scratch an itch, found out it didn't scratch that itch and reverted to a different way of doing that thing, but React lives on, but, no, it is just the NPM and the number of .files, and .editorconfig, and .tsconfig.json, and package.json, and eslint.config.json. It's just mad. It's like COBOL and, you know, and an angular, of course.

Hannes Lowette: And then the whole left bed thing that happened, that hasn't been fixed in the entire ecosystem.

Mark Rendle: No. It hasn't.

Hannes Lowette: It could happen again. If somebody decides to pull their package, that is a dependency for a whole bunch of things, and there are probably thousands of packages out there that could break a significant part of the JavaScript ecosystem. And it's all being compiled, well, it's not being compiled, it's all being pulled in as a source from NPM. So potentially we can have that again.

Mark Rendle: If you were an immoral person, you could write a really useful, very simple thing, put it on NPM, and then you don't even have to figure out how to do a bad thing yourself, you don't even actually have to commit a crime yourself. You can just give control of that package and that GitHub repo to somebody who doesn't want to do a bad thing. And so you enable them to commit a crime, and then they can use that to install Bitcoin mining or there's whatever it's they want to do.

Hannes Lowette: Well, yeah.

Mark Rendle: And there's very little comeback on you for that. This is not a how-to, do not do that. Okay. Please. Thank you.

Hannes Lowette: Well, Bitcoin mining is stealing CPU cycles, but JavaScript is often running on both...

Mark Rendle: That's what JavaScript does anyway,

Hannes Lowette: ...front and backend. It can sniff authentication tokens, it can get access to database connection strings. I mean, if you have a package like that, the impact that you can have on certain businesses is way bigger than running some Bitcoin miners.

Mark Rendle: And this is the big thing and, you know, to be fair, this is not just a JavaScript thing. This is a pip Python thing. This is a Gradle Maven thing, it's a new get thing. It's a cargo thing, you know, even Rust with all its guarantees. So, yeah, it's the problem.

Package Managers: a Big Mistake in the Programming World

Hannes Lowette: Are you arguing that package managers are a big mistake in the programming world as well?

Mark Rendle: Yes. I have this sort of thought that landed in my head one day, and it's never really gone away. As a society, as a world, there is an enormous amount of time, energy, and money that goes into things that we wouldn't have to do if people were just fundamentally honest. You know, if everybody just went, "This is my Gmail account," and all I should have to tell the computer when I want to log into my Gmail, "hi, it's me." And it shouldn't need a password, because other people shouldn't want to read my Gmail. And I shouldn't need to keep iterating on things, and we shouldn't need TLS, and SSL, and HTTPS, and all these sorts of things, we're spending vast quantities of energy that could help us in something else.

Hannes Lowette: And you were talking about the stock exchange a while ago, right?

Mark Rendle: Yes.

Hannes Lowette: So, I mean, that dishonesty or, well, I wouldn't say that stock trading is dishonest, but, like, this trying to get ahead by exploiting whatever people can in the system, it's something that is probably rooted into human nature for a bit.

Mark Rendle: And, you know, sometimes it is dishonest. The 2008 thing, the big short and the mortgage crisis and everything, that was...

Hannes Lowette: That was dishonest.

Recommended talk: Craftsmanship: Code, Guitars & Tech • Dylan Beattie, Hannes Lowette & Kevlin Henney • GOTO 2022

Mark Rendle:...fundamentally dishonest. If you take the bottom 5% of 20 things and then put it together in one, that's just now 100% bad things. But then you can still say, "Oh, this is the top 5%." Yes. But it was the bottom five. So, yeah. But, yeah, you know, the amount of programming time and effort and energy that's gone into just stopping people from being dicks or lulz, and these people...

Hannes Lowette: People learned the Dutch word for dick yesterday evening while we were throwing darts because my nickname became Lul on the dart system.

Mark Rendle: But, yeah, and it just occurred to me how much further along would we be as a species if all the smart people who've had to spend their time...

Hannes Lowette: Could focus on useful stuff.

Mark Rendle:...fighting human nature, had just been able to go, "Actually, what can I do to make the world a better place?" So, yeah, basically if you've ever, ever done anything bad, or told a lie, or just anything, if you are not completely innocent and virtuous, then you've killed us all, and I hope you're pleased with yourself. Yeah.

Hannes Lowette: Wow, that took a turn for ..

Mark Rendle: I should do a whole talk.

The Worst Programming Language

Hannes Lowette: Now, there are other mistakes that we haven't talked about, but you also have a nice talk about those mistakes. Are mistakes in programming language design that make the job of the programmer, let's say, less enjoyable?

Mark Rendle: Yes. The worst programming language ever, my most successful talk ever, I think added up it's had like 5 million views total on YouTube in various forms or something.

Hannes Lowette: That's very nice.

Mark Rendle: It is. It's insane.

Hannes Lowette: If you haven't seen it, look it up. It's hilarious talk. It is.

Mark Rendle: I'm very, very proud of that talk. And people think it's going to be mean. People think it's going to be me deciding which is the worst programming language ever, which it isn't. It starts with a programming language that I don't like, it's a lot better than it used to be, but I still don't like it. But then progressively make it worse by adding just the weirdest, worst features of other programming languages.

Hannes Lowette: I mean, one that you made up, but that I liked because of how evil it is, is the prime numbered line numbers that needed to be in.

Mark Rendle: Yes. Sequential primes.

Hannes Lowette: Sequential primes. And as soon as you like, want to add lime somewhere.

Mark Rendle: Yes.

Hannes Lowette: So that was particularly evil, but you also pulled stuff from other programming languages, stuff that has already been done, but that was horrible.

Mark Rendle: Unless from Ruby which just, no, throws an exception unless something isn't false, and he just kind of like, "That's the wrong way round." Yeah. And, there's a linguist, I can't remember his name, but said, "Unless is responsible for so much stress because you do, you say, 'bad thing, unless...' Condition," so there's that.

Hannes Lowette: So you're pleading here that we should all be going, if this isn't true, then do that.

Mark Rendle: If a bad thing has happened, then raise an exception. Not raise an exception unless a bad thing hasn't happened. That's just the wrong way around. But, no, it takes date formatting from Go, which I only learned about quite recently, and I won't spoil it for you, but Go's date formatting is just weird. It is weird. And it's quite fun finding out sort of where various, like, so it takes a vowel from fourth, I believe, is where that came from, macros which it sort of takes from C and C++, but then it kind of goes, but, you know, to make macros properly powerful, we should do them as regular expressions. And the idea of having the compiler just run a bunch of regular expressions over your code as part of the build process just tickled me.

But the nice thing is I've done the talk a few times and I always leave 10 minutes in the end. I open it up to the room because, yeah, I've used quite a lot of programming languages over the last 30 years, but people have used stuff I haven't used as, and so what would you suggest from programming languages that you use and you get people who've used, there's a sys language that was used for building healthcare software and it was called MUMPS. One of the features of MUMPS was that you could shorten any keyword to the minimum amount of letters before it became unique. And so, of course, because you could do that, everybody did do that. So MUMPS code is unreadable.

Hannes Lowette: Oh, so instead of, while you can maybe get away with wh?

Mark Rendle: Yes, exactly.

Hannes Lowette: Stuff like that.

Mark Rendle: Yes.

Hannes Lowette: Okay. Wow.

Mark Rendle: And so that's fun. And then now they go on YouTube and they go viral now and then, and I suddenly start getting emails and things, and the YouTube comments is just people going, "Oh, you think that's bad, you should try this." And it's thousands of comments.

Hannes Lowette: So that's how you wrote part of that talk?

Mark Rendle: I sort of pick things out that I like and I iterate on the talk and I add stuff into it. But no, it's great fun. And I don't think it's mean, people worry that it's mean, and it's kinda like, no, just...

Hannes Lowette: It's a good laugh.

Mark Rendle: ...if it'd picked on one language, then it would be mean. But saying, "I don't like that feature of that language," and explaining why.

Recommended talk: The Ideal Programming Language • Richard Feldman & Erik Doernenburg • GOTO 2021

Hannes Lowette: There are a lot of mistakes in programming language design that were meant well and have caused us all a lot of pain.

Mark Rendle: Null.

Hannes Lowette: Null, for instance, yes. Like, null is not a good way to represent nothingness.

Mark Rendle: No.

Hannes Lowette: Because it can mean a whole bunch of different things, right?

Mark Rendle: Then you get JavaScript which picks up null and just runs with it because, yeah, undefined, which is not the same as null because if it's null, that means somebody set it to null. If it's undefined...

Hannes Lowette: Nobody knows who set it to anything.

Mark Rendle: ...then nobody set it to anything. So, yeah, it's like a three-state Boeing or something.

Hannes Lowette: Well, I would argue that those are indeed two very different things. It's like, I have set this to be nothing or nobody has set it to anything. They're different. And the clean solution, in my opinion to this is you can see it in a bunch of functional languages where you have discriminated unions where you can say like, if I have a person, it could be that it is no person and you can define that as part of a union where you have even different types of classes that can still be approached as one concept, which is something that we still don't have in C#, for instance. And it's one of the things that would make steering away from null as the catchall concept for nothing would make it a whole lot more bearable.

Mark Rendle: Yes. Option, or maybe, or whatever, and being unable to just... Or you can still... It's like Rust has its result and you can call unwrap which says, "Just get me the result out and if it's not there and an error has occurred, then just dump the process and exit out." So you can always do that. And not having null doesn't mean you can't do that, and having null... You know, C# is now very good at throwing up warnings going, "You know, that could be null where you are doing that," and so you can at least put some guards around it instead.

Hannes Lowette: But they're in the limbo where it is a compiler feature and it's not baked into the runtime yet, right? So you see all the things in your ID and it's giving you very, very nice warnings. I think that the evolution to be more strict about all of this while we're programming is a good idea, but we could do with a few more features to make it better so that we have viable alternatives.

Mark Rendle: Yes. I sometimes wonder if it's time for kind of C# Next and .NET Next drop a bunch of the stuff. I think they try to do it with .NET Core.

Hannes Lowette: I have to say that, like, the language changes from let's say Core 1 2016, last seven years, right? The language has evolved tremendously and I would say for the better, we now have almost effortless immutability for objects which is great, which is something that makes programming against immutable glasses so much easier and it makes it easier to also achieve things like item potency and so on. Because if, you know, it's like, I'm never gonna change the contents of this object anymore, like why not enforce it? But there's a whole bunch of innovations coming from the functional ways of thinking making their way into C# which makes it a very, very usable language. But I don't think we're there yet.

Mark Rendle: No. I mean there's a bunch of stuff coming in .NET 8 with frozen dictionaries, frozen hash sets, and frozen arrays. That's quite cool. And like you say, discriminated, I mean, discriminated unions would be lovely, structural typing on interfaces. So you don't say it has to implement i.e. dictionary of string object. You can just say it needs a string indexer that returns an object. And then the compiler goes, "Yes, this does have that," and that sort of thing, shapes, I think they call it. Funnily enough, had something like that when you do comm program and you see this kind of I things, but there's also S things which is sort of coercing it at runtime and saying, "It will have this method if it doesn't then blue screen." But, yes, so I think this...

Hannes Lowette: That's something we still have, is we can define an interface, but unless the actual class implements that interface...

Mark Rendle: The class has to...

Hannes Lowette: ...you can not just make a class that has those members or you cannot define an interface that maps to members of a class that was written by somebody else and then use that interface.

Business Failures that Impact Software

Mark Rendle: You just think, you know, because C#'s 23 years old now. And so you kind of go, right? So I have this thing that I think would be beneficial for a lot of software projects, which is building it as fast as you can, as slapdash as you can, and then build it again from scratch and take everything you learn, building it the first time, but, now, write it out as clean code effectively. Don't copy and paste anything, so, yeah, build it in three months and then build it again in a month, but just do it right. And I think we would end up with much better, more maintainable purposes.

Hannes Lowette: I argue that that could be a practice for a lot of enterprises as well.

Mark Rendle: Absolutely. 

Hannes Lowette: If I would get the authority... I've had this one customer once where we would have a deal, we were building everything as vertical slices and we could ship features quickly and dirty, but it had an expiration date. So if four weeks from now you still want to keep this as a business, you're gonna have to invest 10 times the amount of time to ride it properly. But in the meantime, we can ship quick and dirty and you can be very responsive. And the moment that that model failed was like, most of the time those features are okay, we're gonna want to keep them from now. And it's like, no, we can longer do this because we're effectively shipping crap to protect crap. But the advantage of that system is if you can do it quick and dirty 1/10 of the time for the price of two features, you can try 10 and keep 1. And if you are in a fast-moving industry, that is tremendously valuable. And it surprises me that not a lot of teams are doing that in the world.

Mark Rendle: I think the problem is that from an enterprise point of view, from a cost center point of view, it's nice clean, maintainable code, but doesn't have recognizable business value. It's kind of, well you've done it, it's working. Why am I going to pay you to do it again? And you go, so it's still working in 10 years.

Hannes Lowette: Or so we can keep maintaining it or whatever. And that's mainly us...

Mark Rendle: But the CFO honestly doesn't care about 10 years because he's probably gonna have moved on by then, so, yeah.

Hannes Lowette: But that's mainly us failing to communicate the true cost of technical debt to business people.

Mark Rendle: Yeah. But it is also, I mean, sometimes it's us, you know, just don't tell 'em it's finished, just build it. Don't tell them it's done.

Hannes Lowette: Everybody has done that, right?

Mark Rendle: I worked at one place where we weren't supposed to write automated tests, so we wrote them and didn't tell people. Then went, oh, no, those aren't automated. We have to run them manually. But, yes, so I think if I wanted to spend the next 20 years of my career doing talks about programming mistakes...

Hannes Lowette: There's enough of them.

Mark Rendle: ...I'm pretty sure I'm never gonna run outta material, put it that way. So maybe I will. That'd be fun.

Hannes Lowette: Thanks so much for joining me here today. Is there, like, a key takeaway that you want people to have? A mistake you would like to save them from by giving them a bit of advice.

Mark Rendle: Probably, I would say the primary mistake that just kept popping up over and over again, was just not sufficient testing. People build things and they go, "Oh, it's impossible to do testing on that." And you're kinda like, "No, it's not. You just need to apply yourself and figure out how," don't assume that something is incredibly simple and it will just work. You know, just test. That's the biggest takeaway. The people who can sort of go, "Well, you know, testing is difficult," is the people who are sending robots to Mars because It's very difficult to test whether a robot is going to work on Mars. They do the best they can, and so if we do the best we can to do proper testing then we can avoid a lot...

Hannes Lowette: That was the opening keynote yesterday.

Mark Rendle: Yes.

Hannes Lowette: Somebody hit the landing mechanism out of curiosity.

Mark Rendle: I know. And then we build hydrogen-based airplanes, which is just...

Hannes Lowette: Amazing.

Mark Rendle: I love the way can you build the landing system for the next miles rover, now I've done that, I'm bored. Come on. Yes.

Hannes Lowette: I have a feeling that you can relate to that sentiment.

Mark Rendle: Oh, yeah. The ADHD is strong with this one.

Hannes Lowette: And I love the fact that she went, "Well, I'm gonna apply myself to try and improve emissions in the airline industry and I'm gonna start doing that and nobody's ever done it before, but I'm gonna make it work."

Mark Rendle: So if that talk's available online, you should watch that one as well.

Hannes Lowette: It's amazing. And, Anita, we really hope that you succeed.

Mark Rendle: Yes, please. Okay. Cool. Thank you. Thank me.