The talk is called Long Life Software, I’ve worked a lot in systems both that had a lot of old code in them and I’ve worked in systems that were designed to have a very long life span like 20-30 years, and it's always interested me. How does software survive? What are the causes of survival and what are the causes of death. So as a thought experiment I tried to figure out what would it mean to write software that last 10,000 years. We’ve got to this idea, there is a thing called the LongNow foundation and they are building a clock that will last 10,000 years and I though what would that mean for software, how would we do that? So the talk is really an exploration of this kind of idea, how do we do this, how do we avoid death?
It’s not necessarily that you take an old language but I for sure would recommend something mainstream because they are the ones more likely to get continued maintenance. If I look to the old software I dealt with, it was nearly all Fortran or C, because that stuff survived, and I guess if you were to go to an insurance company they will probably have a lot of old COBOL lying around and there are still compilers that, I mean very good Fortran compilers on the market today and I think there will always be very good Fortran compilers, but by the same token more modern languages like Java, C#, they are more likely to survive, they are just as likely to survive at least. I think that there are a few criteria to look to, more than one vendor for the language, so you want to be able to have more than one compiler, and preferably several that were Open Source, because that gives you a lot of opportunities for continuing.
If you have the source code for something, then that’s the other key, to actually have the source code for the part of the system that you care about, like having the source code for the compiler can be tremendously important. I’m reminded of an interesting story I once heard about an embedded system where the compiler vendor gone out of business and the operating system, the RTOS vendor, had been bought by another company and the project discontinued, and the company had no source for either of these things and they had a bug, there was a bug in the way that interrupts, or at least registers behaved during interrupts and one in 100,000 times you would get this error and it was very hard to reproduce, very hard to find, but when they did, they had another problem as well, how do we fix this and it was just by pure luck that this was possible that there was some NOOP instruction in the generated executable, that they could patch the binary with some instructions to actually store the register correctly.
So that was just pure luck, so I think the source code is really an important key to being able to keep your software alive, and not only your own source code, but the source code for the things you rely on, it could be your compilers, or could be your operating system, it could be libc, every program is different, these are all important aspects.
Werner: Of course if you go with 10,000 years, you have to go transitive, you have to go CPU instruction, you have to know what the model of the CPU is, I guess.
Well that’s an interesting thing, I’m still on the fence about this because if you have a compiler that can generate code and as long as the language remains available, what a target could move, but again we are living in a strange kind of world know because we are on architectures that have been around for a very long time, if you look at the core of the x86 instruction set, lots of very old code can still run today and I think that even if the hardware architectures change, we'll have emulation; you can still run old Commodore 64 games or Atari games on your Intel machines and the reason is that people have written emulators for the old stuff and I think that that will always be true.
3. But will be possible to fully understand modern x86 CPUs?
I think so, we see it as a complex problem but we also thought that the ZX Spectrum was a complex system when we had it, so yes, I think we will have a software model for all the hardware we have today, it’s such a mainstream architecture as well, I mean that’s another aspect of things like what is your platform architecture, if you want something to last for a long time, either you have to have a very mainstream architecture or you have to be cross platform . So if you can write platform independent code, that’s another solution to the problem.
4. Let's go into other aspects of long term development; what are some architectural considerations?
So when it comes to survival it’s not just, it’s not whole system that survive, sometimes it's parts of systems, so when I look at the code that has survived so far it's either been something so big that it was too big to fail, so had to be supported and the companies had no choice but to keep the thing alife because it would be too expensive to replace, or there are lots of tiny things that were cheap to copy. So you could copy them around very easily and it was very small pieces. So I’m actually quite interested about this move towards Microservices in software architecture, I think that this is probably a great way to enforce this kind of boundaries that mean that you have lots of little things that are quite loosely coupled. So they are more likely to survive I think and for good reasons. Big software might survive but that might be just because it might be terrible software but it's just too expensive to replace, I mean I think there is probably a lot of software in financial institutions, I mean everywhere really that has been around for 40 years but nobody is able to change it.
Werner: Nobody dares to touch it. And yet they generate millions of dollars.
Exactly, I mean these are hugely valuable systems.
Werner: So I guess that’s another reason: things survive if they make a lot of money.
Yes, I mean valuable software is the key part aspect, nobody wants to keep software alive that’s not valuable and that’s why we have legacy systems in the first place, they are extremely valuable pieces of software.
5. I hear rumblings that you might be writing a book on these topics, what’s the book about?
So the book is called “Conquering Large Legacy Software” and it’s about how to improve systems that are too big to improve everything and where you should focus your energies and really about how to make the business case for making improvements, because I think that as software engineers we often want to improve things but we can’t describe it well enough to be able to convince people, so being able to make a business case to improve software and because actually bad software has significant costs and it’s not hard to find business cases for a lot of improvement work, that make sense for a business, it's not just our instincts tell us that we want to live in a nice software environment, there is a real business case usually in there.
6. I guess it's the old problem of selling refactoring to management?
It is, yes, I mean and it’s also a lot about convincing yourself that there is a problem, because I think trying to create a business case forces you to actually quantify things, what is so bad about this system, why is having a daily build, like a 12 hour build, a problem, what are the costs associated with it, but then if you look at the, ok I’ve got 200 developers all waiting for the answers and the build usually fails and causes an awful amount of rework and delays in the development process. Then you can start to add all of those things up into money and actually be able to explain them well to the business stake holders and if you can describe things like that, then you can get the commitment needed to improve things.
Yes, like modularity is important, keep things like I don’t think bad software is the thing to fear, it’s big software, because small things are easy to replace if they are bad, but big things are very hard to replace and that’s the key.
Werner: These are good words to end on and I think will all look out for your book, and thank you Mike!
Thanks!