After 30+ years in the software industry, Bert Hubert has experienced a lot. He founded PowerDNS, published articles for places like IETF / IEEE, and built his own parliament monitoring system. That just scratches the surface.
Recently, Bert wrote about what it takes to build software for the long term. Letâs dig in.
Matched from the episode's transcript đ
Bert Hubert: Yeah, so I was invited â so Iâm a very part-time technical advisor to the Dutch government also, to what you would call the FEC, the electoral board⌠And they built this software for tabulating the national elections. And they are revamping it, and they said âWould you take a look at our code? Can you tell us what you think about it?â And I looked into it and Iâve found that they were doing sort of more or less standard 2025 software development⌠And then I wondered â and that means having like 1,600 dependencies. Because if you have a Node.js built project these days, and you install it, it will, for starters, pull in like a thousand dependencies. And then you havenât done anything yet even.
So I looked into that and I thought âWell, this is not going to be something thatâs viable for the next 10 yearsâ, because these dependencies change all the time, and Npm might go away for the next 10 years⌠So I turned that into a study, âWhat would you do these days if you had a 10-year software project?â And I went to Mastodon; that is a really good social network to ask these kinds of questions, because itâs full of nerds, and theyâre my people⌠And so I asked them, I said âLook, what are your thoughts, for anyone doing long-term software development?â And we had people weigh in that have a software with an 80 - and not 18⌠80-year horizon. And these are people that study, and have to measure the radioactive decay of nuclear waste. And they are tasked with measuring and supporting that for the next 80 years. So they spent quite some time thinking about this stuff. And it turns out, actually, itâs sort of modern software development. Itâs like sort of the complete opposite of what you would do if you want to have software that works 10 years from now⌠In the sense that we have these huge â that even building software is fragile right now. So not even that it does the same thing, but if you want to build a sort of standard 2025 software project, you need a working internet connection, and like hundreds of servers around the world that supply you with data, even before your software runs. And that is not something that is a healthy thing to have if you want to promise people that it will work 10 years from now.
So I got a bunch of very strident feedback from people. They said âWell, if you look at the problems that people have with old software, something goes wrong with the software, there is a problemâŚâ Something always goes wrong, of course⌠And then in your mature software project, you need to figure out what is actually going wrong. And what almost everyone said is keep it simpler. Of course, we all know that we should not write software that is as complicated as we can make it, because thatâs not going to end well⌠But everyone said âLook, weâve had a very bad experience. We needed to figure out seven years ago why this clever code â what it actually does.â And then often you find that this clever code, there was no need to make it clever. So if you have like 10 political parties, or â in the Netherlands [unintelligible 00:31:15.12] we have 25 active political parties. So thatâs â I mean, you have two?
