Bert Hubert

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 the most, what almost everyone said is keep it simpler.

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 the most, 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 had very bad experience. We need 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.

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 had very bad experience. We need 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, maybe fun, we have like 25 active political parties. So that's, I mean, you have two. Yeah. But can we borrow some? Yeah. Well, yeah, you could. Well, there's no, having 25 is not, not an optimum. I can tell you that.

So if you have like 10 political parties or in the Netherlands, maybe fun, we have like 25 active political parties. So that's, I mean, you have two. Yeah. But can we borrow some? Yeah. Well, yeah, you could. Well, there's no, having 25 is not, not an optimum. I can tell you that.

But even if you have 25, there is no need to set up a complicated data structure to hold 25 political affiliation names. Okay. But one day you might sit there and say, hey, wouldn't it be useful? Wouldn't it be fun if we had a complicated red-black tree so that we could make really rapid searches of our 25 political parties?

But even if you have 25, there is no need to set up a complicated data structure to hold 25 political affiliation names. Okay. But one day you might sit there and say, hey, wouldn't it be useful? Wouldn't it be fun if we had a complicated red-black tree so that we could make really rapid searches of our 25 political parties?

And then you sit there and maybe in 2032 trying to debug why it doesn't work. And that's because you try to be clever. And like so many people came to me, they said, if I had one regret, it's that we built things too complicated. And then seven years later, no one understands the code anymore. And the other thing that people came up with is that people change jobs a lot for a number of reasons.

And then you sit there and maybe in 2032 trying to debug why it doesn't work. And that's because you try to be clever. And like so many people came to me, they said, if I had one regret, it's that we built things too complicated. And then seven years later, no one understands the code anymore. And the other thing that people came up with is that people change jobs a lot for a number of reasons.

But if you want to do long-term software development, the easiest way to do that is with long-term employees. Because they build up knowledge, they know how the stuff works. But if you have people that are changing in and out all the time, then you become very reliant on good documentation. And it's, of course, always good to have good documentation. I mean, by me in all means, do it.

But if you want to do long-term software development, the easiest way to do that is with long-term employees. Because they build up knowledge, they know how the stuff works. But if you have people that are changing in and out all the time, then you become very reliant on good documentation. And it's, of course, always good to have good documentation. I mean, by me in all means, do it.

But it's very hard to compensate for all that knowledge walking out of the door. after two years. So they also, people said, look, you really need to, I mean, it's old fashioned and it's almost crazy talk these days, whether you really need to just invest in keeping your developers happy And wanting them to stay for like maybe seven years or eight years or something like that.

But it's very hard to compensate for all that knowledge walking out of the door. after two years. So they also, people said, look, you really need to, I mean, it's old fashioned and it's almost crazy talk these days, whether you really need to just invest in keeping your developers happy And wanting them to stay for like maybe seven years or eight years or something like that.

But again, this is also not how many places work these days anymore because they have contractors and they zoom in and they zoom out. And it's very... So it's actually... As a result, so I wrote the article based on my presentation to the Dutch electoral board and it hit Hacker News and other people. And amazingly, almost everyone agreed with it. It was very rare that it happens.

But again, this is also not how many places work these days anymore because they have contractors and they zoom in and they zoom out. And it's very... So it's actually... As a result, so I wrote the article based on my presentation to the Dutch electoral board and it hit Hacker News and other people. And amazingly, almost everyone agreed with it. It was very rare that it happens.

But like 30,000 or 50,000 people read it. And based on that, I got a lot more feedback. from people that said, look, we are doing nothing like this here. We are following sort of the Facebook model of software development where we deploy all the time and most days of the week it actually works. And sometimes we go through a bad patch.

But like 30,000 or 50,000 people read it. And based on that, I got a lot more feedback. from people that said, look, we are doing nothing like this here. We are following sort of the Facebook model of software development where we deploy all the time and most days of the week it actually works. And sometimes we go through a bad patch.

But then there are all these kinds of people that have to make software that opens and closes bridges and doors and MRI scanners that could physically tear themselves apart or pacemakers or robots that actually do surgery. These people are like no one understands us anymore.

But then there are all these kinds of people that have to make software that opens and closes bridges and doors and MRI scanners that could physically tear themselves apart or pacemakers or robots that actually do surgery. These people are like no one understands us anymore.