https://www.youtube.com/watch?v=vlWc0DbcGpc
- Jonathan Blow - Preventing the Collapse of Civilization
- ICSE '00: Proceedings of the Conference on The Future of Software Engineering
- Software Engineering Education: A Roadmap
- Controversial Twitter comment on staying relevant as a software engineer
- C++ Seasoning
- Jimmy's blog
- Jimmy's coaching business
Elliott: [00:00] Thanks for taking the time to talk today. Would you mind telling our listeners a bit about what your background is and what you're currently working on?
Jimmy: [00:07] So I've been studying academic software engineering, program analysis, and program synthesis for over a decade. Just over 10 years ago, one day I woke up and realized the world does not know how to write good software.
I've worked all over this space, from some time at a company that builds custom tools that rewrite entire programs, to my own startup, automatically fixing bugs, to my current work at MIT.
My life mission is to reduce the global cost of software maintenance by a factor of 100.
Elliott: [00:37] What's the current global cost of software maintenance?
Jimmy: [00:40] Extremely high. Total salary in the trillions, and a very large fraction of that is on tasks you'd describe as maintenance. So, looking at hundreds of billions.
Elliott: [00:50] How will you know if you succeeded?
Jimmy: [00:53] There are various stories where software maintenance problems proved disastrous or are holding us in the past.
Y2K is the most famous example of this, and a lot of people just don't realize how bad it was, how much work went into it, or even that Y2K actually didn't really end until quite recently, because a number of companies just pushed the problem off by 20 years and they didn't really fix it.
My new favorite, very approachable but less well known example is about Sabre. Sabre is not a single system, but a family of systems used for airline reservations.
Airline reservations are very complicated. They have a lot of features, like the way that your bags are matched with people and transfers, a number of different binary formats, and each system needs to handle everything produced by the other airline systems and vice versa.
When I get a boarding pass, I frequently see my first and middle name printed without a space. Why is there no space? Because in the sixties, IBM charged per-byte data transfer, and that's too hard to change so that they can put in that space.
When stories like that stop happening, then I've succeeded.
Elliott: [02:02] What will be the implications to society, if software maintenance costs are reduced by a factor of a hundred?
Jimmy: [02:08] A lot of things will be able to change faster. Major new laws and policies will be much faster to implement.
So, recent example that's on everyone's mind right now, that the Real ID is just coming to a fact. It was passed 15 years ago, and now it's actually happening. So things like that will change faster.
There was a talk by Jonathan Blow, the famous game programmer, where he talked about "computers kind of stopped working and no one cared".
Go through a day and write down every single problem you have with your software. You know, this could be something like Gmail has a weird formatting and I can't get it to undo that formatting, it could be something like your voice suddenly changes in a video call, could be your screen freezing, could be a pop up being locked and not being able to close it.
Just go through the day and write everything down. And you're like, "Holy crap, I've been carrying around a giant weight all this time and just gotten used to it."
Better software maintenance, that weight can go away for everyone.
Elliott: [03:06] Do you have some sort of a 50 year plan for achieving the 100x improvement?
Jimmy: [03:11] I have a dual life. By day, I do my MIT work, trying to make programming tools easier to build and more general. By night, I train programmers. I think we can get a 10x reduction from each of those independently.
Phase one is to take my teachings and turn them into the software engineering norm, that is, at least as popular as things like SOLID design are today. Phase two, building a tools company. When I talk about getting 10x from coaching and 10x from tools, can basically view it as prevention and remediation.
Coaching is largely in the prevention category, helping people create software where they're not going to have huge systems that hold the world in the past, either because they built them in a way where they are easier to change, or because maybe they even got it right and don't need to, or because they manage to design it in a way where it'd take much less work and so it's actually reasonable to replace it, or because they were able to actually document the knowledge which is implied by the system that would get lost otherwise and where you don't have cases where you can't turn this thing off because you don't know how it works, and the people who built it are dead and you just therefore cannot build a replacement without a ton of experimentation.
That's the prevention side. The remediation side is, why can't I have a hundred airlines get together and say, "tomorrow, we're all going to press this button, and the next day, all of our systems will have been upgraded in tandem, in a way where I can have arbitrary length names on my boarding pass"? I think that button is possible to build.
Elliott: [04:41] Can you describe the workflow of a programmer 50 years from now?
Jimmy: [04:46] 50 years is a long time. 50 years ago, people were still using punch cards.
Starting easier, let's look at 20 years from now. To see the future of programming, I think you should look at game programming today. Games are a place where they routinely write new software, and there are many kinds of games, but the actual architectures of game systems are limited enough that people can write engines that are applied to a wide variety of things.
So the game industry is actually in a pretty optimal place for extreme software reuse and extreme tool building.
A lot of what some of the job-titled "Game Programmers" will do is not even recognizable to typical software engineers as programming. They spend their days in this graphical editor, a lot of it is like attaching and customizing pre-built behaviors to components, or otherwise just writing things for small pieces at a time. I think a lot more domains are going to have tools that look like Unreal and Unity do today.
Elliott: [05:40] Can you describe the workflow of a programmer in a world where this 100x improvement has been achieved?
Jimmy: [05:46] A very simple example, when you start doing something, your IDE pops and says, and I want you to picture like a Microsoft Office 90s style Clippy paperclip jumping up and saying this, it's like, "Hello! I see you are trying to consolidate these fields into a structure. Would you like me to help you with that?"
Elliott: [06:02] How do we fit that into a historical context? How has the role of a programmer evolved over time?
Jimmy: [06:08] Early in my career, I read a collection of articles, written around the year 2000, called "The Future of Software Engineering". And ironically, it's actually a great piece of software engineering history. A big lesson from reading this and from older pieces is just how modern everything seems.
I read some software engineering writing from the seventies, and you would think that they're kind of bumbling and not knowing what they're talking about, and a modern programmer would think "ha ha, how quaint".
In fact, they use a lot of the same language that we use now, and they talk about system design, and requirements, and stuff that feel more apt to modern day than like three quarters of the stuff that you read in blogs.
Until you get the section where you actually read the details they implement, and then they suddenly start talking about hundreds of lines of code instead of thousands or millions, and they'd talk about the exact bit layout of stuff.
One way to look at this is that maybe there's this thought process of software engineering. It's being applied at multiple levels. And the thought process they were applying back then, making sure their bit layouts were correct, it's similar to the thought process we do today, talking about microservices and multi-tiered architecture.
Perhaps in 20 years we'll be having the same kind of thinking now, and the conversation will look the same, it's just that your system design is, instead of wiring together various screens to get a front end for your app, now the atomic unit of reasoning is going to be like, an entire section of an app or an entire app.
Elliott: [07:36] Do you think there have been significantly improved ways of organizing these different components?
Jimmy: [07:41] I'm not sure. I'll give you a tempting answer, which is not the answer. So an easy route to go down is thinking that what's called "dynamic connections", "dynamic architecture", is a modern thing. This means that which components connect is determined programmatically, and can change. So dependency injection is today's recognizable example of the idea of a dynamic architecture.
Most people don't realize this, but COBOL is a very dynamic language. The system run by the Bank of Australia, New Zealand, all in COBOL, COBOL aged, extremely dynamic. All the components found each other by string lookup.
Take a programmer today, transport them back 40, 50 years, bar them from saying anything too technology specific, and, they can have a pretty natural conversation with their contemporaries.
Elliott: [08:28] That reminds me of the trope or the saying everything old is new again. To what extent have you seen that?
Jimmy: [08:34] So here's one thing that I'll bring up. So this is the software engineering education thing. Two facets.
One is the idea of, "let's throw away the standard, stodgy computer science curriculums and like have a Bachelor of Engineering in Software Engineering and just do projects, programming, and learn frameworks and stuff". That was a pretty hot topic. Then they basically did that, they're called bootcamps. I've again been hearing some people still calling for "let's get a degree in software engineering kind of stuff", without distinguishment from the bootcamps that have been tried.
So the second angle is the idea of "CS schools should be teaching the current hot industrial languages, those things people actually use on the job". Earlier I mentioned this "Future of Software Engineering" collection from around the year 2000. Absolutely great memorable line by Mary Shaw, basically one of the founders of the field of software engineering, she wrote a piece called "The Future of Software Engineering Education".
And she said companies always want us to teach the latest job relevant languages. She said, "I first heard that line in the sixties, with companies asking me to teach more JCL". What is JCL? It is Job Control Language. It's how you schedule COBOL programs to run on mainframes.
Every time I hear calls to teach frameworks in school, I think of that line.
Elliott: [09:50] What's your counterargument to teaching something that's directly applicable?
Jimmy: [09:55] The standard counterargument is that things change fast, but something I think fewer people have an appreciation of is you don't realize just how big software engineering is.
There was a controversial Twitter comment last year. Someone said, if you want to be relevant in the next 10 years, you have to learn these things, like web assembly, web components, blah, blah, blah.
And I think he honestly believed that, and like, that was his part of the world. This kind of web programming. That was what was becoming popular and that's what was needed.
But I talk to people who are writing simulation code. I talk to people who are writing embedded code. I talk to people who work for big banks. I talk to people who are working for construction companies, that for some reason have a pretty high-end software engineering team inside them. I talk to people who are working for retailers as software engineers.
The world of software engineering is big, and people from different ends have totally different ideas of what the important parts of software engineering are. And in fact, a lot of the jobs are in less flashy areas. Embedded systems is absolutely huge. Their needs are extremely different from your stereotypical web dev shop.
When you're preparing students for jobs by teaching them current trends, which job are you preparing them for?
The bootcamps have transformed many people's lives for the better. But many people who do have the resources and the time preference to commit to learning something deeply for a long time and set them up for a long career ahead of them, a lot of them will be better served by focusing on things that are more fundamental.
If you have only so many learning points to spend in a year or four years, do you want to spend them learning fundamental programming things about operating systems, and graphics, and AI, and common features shared by many, many programming languages, things that are going to stay relevant for 50 years?
Or do you want to spend your learning points learning about the difference between two confusingly, similarly named method calls in some YAML parsing library?
Elliott: [11:54] So reducing maintenance costs, what sort of capabilities do you expect that sort of productivity improvement to enable?
Jimmy: [12:01] Some of them are going to be in small things. I'm thinking of a talk I watched recently called "C++ Seasoning" by Sean Parent, which is one of the best software engineering talks I've seen in several years.
An example he gives at the beginning is, problem of, in UI, dragging several boxes into the middle of a list, and several variants on that. And he asked the audience what C++ standard algorithm does this for you. I didn't know, I'm not a C++ guy. The answer is a function called rotate.
He points out this before and after, where the before is a lot of complicated code and a bunch of loops, only handles like a few cases, whereas if you use rotate then it gets all of them.
So just this nice UI feature, can we do these many kinds of dragging things around and it just works, is a benefit of better software design.
You can think about various quirks of interoperability or dragging from one application to another, and so many more things will just work with better software design. Things that work in one area just also work in another.
As far as new types of applications altogether, one answer is that if we can figure out how to not manually encode knowledge about visual layouts, that'll make a lot more things possible.
So we talk a lot about coupling, which I define as when one part of the system tends change in tandem with another part. Perhaps the most complex kind of coupling constraint that we deal with is in GUI development. The constraints of visual design, they are extremely complicated. A lot of people don't realize this, but if you have some very large piece of text, changing the text can actually affect the design of the entire piece.
Like, if I have a very large letter K somewhere, then it makes a difference whether things align with the vertical line created by that tall straight line in the K. So there are things like that, just all over the place in visual design. I don't know how it's going to happen, but I do imagine that at some point there'll be a revolution in visual layout.
You will have a lot more apps total and maybe some very custom and very personalized ones.
When it comes to software design, it's mostly going to be a matter of things that you'd want to work today, but just take another thousand engineers to build, will in the future just take another 10 engineers to build.
And I most often think about this in the case of software tooling, where this IDE has all these fancy features for Java and Python, and then I'm working in a new language or even C++ or TypeScript, popular but less supported, and they don't have any of that stuff. That will stop happening.
Elliott: [14:33] We've talked about some optimistic visions of the future, where programmers are vastly more productive, but what's your pessimistic view of the world?
Jimmy: [14:40] What can go wrong in software?
Y2K programmer in 1999 decides he wants to skip all the drama and decides to get cryogenically frozen, and to be woken up in a year. But alas, his vault is not Y2K compliant so he does not get woken up in a year, and he wakes up in 8,000 years, and he's surrounded by all this futuristic technology.
They said, "Oh my God, he's alive, yes!"
So then he says, "Well, wait, what's going on?"
It's like, "Yeah, it's the year 9999, and we're so glad to have you."
It's like, "Why, why are you waking me up now?"
Then they say, "Well, the year Y10K is right around the corner, and it says in your resume that you know COBOL".
I actually think Sabre does have the record of the oldest continuously running system. It's obviously changed a lot since it was created, but it's about 60 years old, and it's still a huge part of the world.
Well, are we going to be having hundred year old systems? 200 year old systems? So far, the answer looks like it's going to be yes.
Elliott: [15:34] In some sense, wouldn't that be a good thing? Because it means those hundred year old or 200 year old systems have been working, they've been doing their job?
Jimmy: [15:42] It's a good thing, if, were you to burn it down and rebuild it, it would be mostly the same. It's a bad thing if it's actually tethering you to the past.
In many cities, you have buildings that are a hundred, two hundred years old. You have streets that are similarly old. They've been working. Is that a good thing? If your buildings are crumbling and they have terrible connections and poor insulation and your streets are always crowded and you're jealous of all the newer cities that don't have these problems, then maybe not.
Elliott: [16:11] Do you have any closing thoughts for our listeners?
Jimmy: [16:14] If you're a software engineer, then you're building some piece of the world. That piece you build will exist for a long time after you stop thinking about it. It'll affect the lives of many people. Even if it's something running in the backend, processing a transaction somewhere, it is affecting people's lives and it is a piece of the world that you're building.
That is a huge responsibility. So never diminish the role that you have in building the future. One day the stuff you write will be legacy; what's your legacy going to be like?
Elliott: [16:45] That's an awesome way to end it. So where can listeners find you on the internet?
Jimmy: [16:51] My blog is www.pathsensitive.com, posts about software design and software engineering.
My business is www.jameskoppelcoaching.com, I do one on one coaching and I have a web course, trying to teach my philosophy grounded in first principles of programming language theory and software engineering theory, and change the way the world works.