Software Technologies that Stand the Test of Time

What software technologies have stood the test of time or have had a massive influence over existing systems? Which do you love or hate?

We asked these questions to the GOTO Book Club authors and interviewers that made up the lineup for the second season. Find out what Nicki Watt, CTO/CEO at OpenCredo, Eberhard Wolff, fellow at innoQ, Venkat Subramaniam, founder of Agile Developer, Inc., Liz Rice, chief open source officer at Isovalent, Rebecca Nugent, professor in statistics & data science, Phil Winder, CEO of Winder Research, Hanna Prinz, DevOps & software engineer, and Eoin Woods, CTO at Endava, had to say. The conversation was moderated by Rebecca Parsons, CTO at ThoughtWorks.

SQL - Nicki Watt

Rebecca Parsons: Hello, everyone. My name is Rebecca Parsons. And we're here to discuss software technologies that stand the test of time. And we have eight panelists who are each going to propose software technology, and then the other panelists will weigh in on what they think of that idea. So, Nicki Watt, let's start with you.

Nicki Watt: All right. Thanks very much, Rebecca. So, my humble submission is SQL, the Structured Query Language, used to access and maintain relational databases since the dawn of time. I think the roots go all the way back to '74, when Chamberlain and Boyce actually published their sort of famous paper, and it's, really that language that we have today is based on what that was sort of 45 years ago.

So, for me, the sort of three acceptance criteria that I had was what was the original purpose, does it still fulfill that, has it actually evolved gracefully over time, and how prevalent is its usage today? So, I think, on the first point, when relational databases originally were created by Ted Codd, the query language back then was based on maths. But they really wanted to do it in a way where it could be more accessible to users that were not trained in mathematics and computer programming.

Today, you have engineers, data scientists, your basic sort of Joe Soap, who can generally write SQL, write SQL to get data out and into the database. Even my dad, who's a bank manager, can actually write SQL as well. So, I think it ticks that box, hopefully. But it's used across the board, not just to query the database, but also to maintain it.

I think in terms of evolution, the language structure and the base syntax have remained the same, although it has had different evolutions. 

For SQL, I think it was '86, where the very first ANSI standard had the support for the select, insert, update, and delete statements, exactly the same ones that we have today. SQL 92 then introduced things like outer joins, set operations. And even in 2003, there was the introduction of XML querying through XQuery and stuff, which you can argue whether that's a good thing or not. But the language evolved as more things kind of came along.

I think whilst I concede that SQL itself doesn't have one sort of standard to rule them all, the dialects are all kind of different, I think the core has really remained true. And, in terms of its prevalence, I think you really can't escape SQL. It's used for every single relational database that's out there. It's de facto query standard, so prevalent, maybe, that a whole class of other databases are named as being not SQL. And so, in my conclusion, I'd just say SELECT * FROM table is as well known today as it was back in '86. 

Rebecca Parsons: Yep. Rebuttals. Or support.

Venkat Subramaniam: I don't have a rebuttal, but I do support that that's a beautiful technology to mention. So, kudos for that. In fact, I would say, probably, it goes beyond SQL itself. For example, Microsoft's efforts towards Link were inspired to take that idea into data in memory, not just the database itself. Though, I spent my youth with object-oriented databases. So, I escaped SQL for a number of years until I was thrown back into it. But I can definitely appreciate that.

Eoin Woods: My possible rebuttal would come from the perspective of DBAs. SQL is a tremendously powerful declarative language that allows you to ask almost impossible questions against data structures that they were never designed to answer. So, it produces a huge abuse of perfectly good relational databases. But it is a very powerful language.

Nicki Watt: Yes That's fair enough. I was torn as to whether to go for a relational database itself, or whether to go for SQL, but landed up going for SQL.

Recommended talk: GOTO 2019 • Explore your Microservices Architecture with Graph Theory & Network Science • Nicki Watt

Venkat Subramaniam: Good choice.

Liz Rice: Very good choice.

Rebecca Nugent: I might jump in here. I come from statistics and data science and more from the education side. I had a professor at Carnegie Mellon. What I find interesting about how the use of SQL has changed is that even when I was doing my kind of undergraduate degrees, and even maybe the first master's degree, you know, SQL was very much, like, "Yes, you probably should learn it while you're here, but, like, don't worry about it. You're not necessarily gonna need it." You know, etc.

In the last 10, 20 years, watching how important it's become in our education/training programs, all of our students who are graduating with statistics, machine learning, and data science degrees are all getting exposure to SQL. 

So it's been around for a long time, it's interesting to watch kind of the educational programs are now really focusing on it as well as other, you know, relational databases and languages, and stuff. From the education side of things, we are embracing it, as well.

Nicki Watt: Cool.

Rebecca Parsons: Nicki, any closing comments?

Nicki Watt: No, I don't have anything else to close.

NeXTSTEP - Eberhard Wolff

Rebecca Parsons: Let's move on then to Eberhard.

Eberhard Wolff: My proposal would be NeXTSTEP. NeXTSTEP is an operating system that NeXT built, the company that Steve Jobs did after he was fired from Apple in 1985. Its UNIX-based operating system pioneered technologies such as Display PostScript for the graphical user interface, object-oriented development with Interface Builder and Project Builder, and some pretty interesting applications were built on NeXTSTEP, such as the game Doom. And also, obviously, the first web browser and the first web server were created on NeXT at CERN in Geneva.

The operating system originally worked on NeXT hardware. Just 50,000 machines were built. At one point, they quit production, so it seemed like a failure. I think that's the interesting point about technologies that stand the test of time, that they evolve and adapt. So it was then ported to other platforms, HP, Sun, and Intel. The API was ported over to Windows with OpenStack for Windows. So, sort of write once, run everywhere, and it lost that battle to Java, so again, it had to shift, and NeXT was bought by Apple in 1996.

Nowadays, Xcode, the development environment on macOS, is based on the interface with their project builder. The dock that we have on macOS is originally from NeXTSTEP. Display PDF is an updated version of Display PostScript. And the Cocoa NS classes... NS is NeXTSTEP, and nowadays, it runs on iOS and Watchaware. So, those are pretty much-updated versions of NeXTSTEP. So, it runs on hundreds of millions of devices.

So, I think it's interesting how such a sort of niche technology that was pretty much ahead of its time is the center of so many devices nowadays and had such a long history being ported from the original NeXT hardware over to Power PC, Intel, ARM processors, mobile platforms these days. And nowadays, it's probably part of our everyday life, even though it seemed like a failure at first sight.

Rebecca Parsons: Excellent. Responses.

Venkat Subramaniam: If it's possible to make somebody nostalgic by talking about technology, you get the badge of merit for that. I'm almost in tears right now. I spent my graduate student life playing with NeXT computers late in the night. So, I couldn't agree more. I had a dislike, honestly, for Mac computers back in time while all my friends would be using it. I was kind of wondering why, until I started using it when I discovered, "Oh, my gosh. This is NeXT being reimplemented on the Mac." So I couldn't agree more on this particular topic.

Eberhard Wolff: And there is a NeXT manual right behind me if you look there closely.

Nicki Watt: Is that what you were trying to point to?

Rebecca Parsons: I think your point about evolution is an important aspect of this technology as standing the test of time is an important one. I must admit, I was quite surprised when you said NeXT. It's like, "Wait a minute."

Eberhard Wolff: Yes. I also found the contrast interesting concerning SQL because that's the technology that has been around for quite a long time, and it never really changed, while this is something where, the market changed, and the whole idea changed from being more like an object-oriented API developer focus. It was a hardware store before that, and now, it is something that, as I said, is the foundation of lots of mobile devices nowadays.

Rebecca Parsons: All right. Well, let's move on then. Venkat, you're up.

Functional programming - Venkat Subramaniam

Venkat Subramaniam : All right. So, I was gonna talk about technology, but I wanted to broaden that to something a little bit more, and then tie that back into technology.  I'm gonna say it's our desire to simplify the complex world around us. If you look at everything we do as programmers and various other things, we just get into so many complexities. When I look at programmers, people trying to solve problems, what beats us down every single day is complexity. So the question I wanna ask is, you know, what can we do to mitigate the complexity?

Any kind of technology solutions that can help us in getting through our lives, managing all the things we have to build. In that regard, I see functional programming as the one that has stood the time for managing complexity. I don't look at functional programming as a tool with monads, as people, you know, threaten everybody else, but I look at functional programming as a way to remove accidental complexity.

Well, in general, when we are working with things, we have to deal with two kinds of complexities, as we all know, those that are inherent complexity, which comes from the application and the problem and the domain, and the accidental complexity that often comes from the solution space. 

While a lot of programmers, I would say, probably most of the programmers are very familiar with [SP] style of programming, how ironic that something so familiar is yet so complex. And we are that frog in the pan being fried and, you know, boiled every day. We have endured this pain, not because it's simple, it's because it's familiar.

On the other hand, what is not so familiar to us is quite simple because, in functional programming, the code begins to read like the problem statement, and as a result, it becomes a lot more expressive. In a way, I would say this also, comes back to other activities in human life. You know, if you go back to 1900 and ask what were the automobiles that were most prominent in the world, those were the electric cars that were prominent back in 1900, which was forgotten, a generation or maybe two or three generation of people, who were around were driving gasoline cars, and we are getting excited about electric cars again.

Similarly, it's kind of funny to watch that a generation of programmers or more have gone through the imperative style of programming, not even ever getting a taste of functional programming. And all of a sudden, just like electric cars, we are excited about functional programming. So my vote is, first, to reduce accidental complexity, and by way of doing so, is to vote for functional programming.

Liz Rice: So, I'm gonna have a question rather than a rebuttal. Do you think that or are you saying that functional programming necessarily creates clearer, easier-to-read programs than imperative languages? Or is it perhaps more to do with familiarity and the ability to... You know, you can write terrible code that's impenetrable in any language. Do you think it's the case that functional programming is inherently clearer and fewer complexities?

Venkat Subramaniam: Yeah, that's a really good question. I'm gonna say, because of familiarity, the imperative style is easier to write but harder to read in the long run. And because of unfamiliarity, functional is harder to write but easier to read once we get marginally familiar with it. So, fundamentally, I do believe that for any given complex problem, imperative style is harder to read. A functional style, hopefully, well-written, is easier to read.

Rebecca Parsons: Although I will say the scariest program I ever saw was a Lisp program, it was written by somebody who had programmed his entire life in Fortran, and so he wrote a Fortran program in Lisp syntax.

Venkat Subramaniam: To your point, I had somebody email me a piece of code and said, "I know you're a big fan of functional programming, so here you go. I wrote one. This is horrible." And the person who wrote it said it's horrible. I replied saying, "I agree. But here's the refactored code if you wanna take a look at it."

Nicki Watt: It's an interesting point though, as well. Because I think if you look, for example, at something like Scala, which can do both sorts of OO and functional, it's quite interesting to see when an original sort of Java programmer or OO programmer, gets hold of Scala. It takes quite a long time before the functional style sometimes comes out and you can get your head around that. So, I think that point is very valid, as well.

Eoin Woods: I think I've got one slight rebuttal. I keep coming across people that tell me they love functional programming. I see lots of practical functional programming languages. And it's not like we can't learn new stuff. The JavaScript guys learn something new every three months, as far as I can see. And yet, people are still not putting their money where their mouth is and betting on functional languages. So, I don't know. I think something is missing. Maybe you need to write another book, Venkat.

Eberhard Wolff: Just a slight remark. I'm sometimes wondering what the world would be like if, in the '80s, home computers would have shipped with functional programming languages, like Logo, instead of BASIC. So, then, maybe the world would be very different.

Liz Rice: I think there was one of the early kinds of home PCs, maybe called Oric, that had something like Logo or Lisp as its... My memory is failing me.

Eberhard Wolff: I think it was Fog.

Eoin Woods: The SimpleX workstations were native Lisp machines. They processed the Lisp VM in their hardware. So, it has been done.

Eberhard Wolff: But they were quite expensive. I mean, the thing is that the kids grew up with imperative programming, so it seems intuitive to us nowadays. While if they had grown up with functional programming, it would be functional programming that seems to be intuitive for them nowadays.

Eoin Woods: Could be.

Rebecca Parsons: Any final remarks, Venkat?

Venkat Subramaniam: I think you know we should have introduced imperative or functional, to begin with. One of the things I do, I moonlight and teach part-time at the university. And I introduced a programming languages course mainly with the intention that I want the students to graduate knowing there is no one way to solve a particular problem. So, I'm not going to say that functional is the right way to do things, but we need to get a taste of different styles of programming. These are vehicles, and we have to choose what's right based on the situation.

And again, one of the other things I will quickly mention is I don't understand why people would pit object-oriented programming, something as opposed to functional programming. I don't see them as competing with each other in a lot of places. So, I think the real, you know, enemy to programming is complexity. And functional programming tries to attack complexity. And that's what I really wanna focus on in terms of what we can do with this particular technology, which, surprisingly, has been around for such a long time. Some of the initial languages created were functional. And I hope in the next few years, we'll come around to embrace that a lot more than we do today.

Rebecca Parsons: Okay. Thank you. Liz, you're up next.

Makefile - Liz Rice

Liz Rice: All right. So I tried to think of something that I have used recently that I used very early on in my kind of programming career. I think it's maybe gonna be a bit controversial because I don't think it's that great. But it's kind of a hammer that a lot of people continue to use. And it is the humble Makefile. I remember, you know, running make commands when I was, you know, a student when I was first getting into kind of C programming.

Only recently, I've been going back to Makefiles because I've been doing some work on EBPF. Not only am I compiling C, maybe I'm compiling some Go code, as well. Maybe I have, you know, targets in different languages. There are other tools that you can use to build things, but it struck me, I'm using this tool that I first used 30 something years ago. I still kind of don't like it in a lot of ways, but it does the job. So, the Makefile.

Eoin Woods: I've wasted far too many hours putting tabs in the wrong place to ever love Make.

Rebecca Nugent: Do you still use it, though?

Eoin Woods: Not when I can avoid it. But maybe that's what Liz was saying, as well. Sometimes, there's a Makefile, so you have to just get on with it.

Liz Rice: Exactly. I mean, whoever thought that, like, different whitespace characters should have, like, different meanings. I remember having real arguments with PHP in the early days because a blank line at the end of a file would make a difference. So I am not a fan of meaningful whitespace. But I do think Makefiles do the job.

Venkat Subramaniam: I was gonna say, I wish they had learned from it and not go that way to Python. That's one thing that ticked me off. You know nothing makes me madder than significant whitespaces. But, Make is such a love-hate relationship. I mean, I couldn't agree more with you. Had you said that you love to Make, we'd have had a different conversation, right now, I think. But I think we are in violent agreement here.

I remember spending my youth with Make, and it's like, "Who in their right mind would do this stuff?" But yet, you had to because almost everything you did use Make. Not that things that came after made it any better. And you kind of have to wonder, is significant whitespace better than angle brackets with Ant? And that was a disaster for a few years. And I would say the only difference between make and Ant is the creator of Ant publicly apologized to people for creating such an XML syntax.

But I agree. And, you know, decades later, we are still looking for a better way to express our dependencies and build. So maybe another 40 years later, we can have this panel again and look back at how we're doing with the build utilities and how the world has progressed.

Eberhard Wolff: There are so many other build tools that came and are not used anymore, while Make is still there. So, I think that's a very good point. So it's not about how it's elegant, it's about how it's persistent and still there.

Liz Rice: Yes, kind of the definition of standing the test of time really, isn't it?

Eberhard Wolff: Exactly.

Venkat Subramaniam: That applies to roaches, as well, but...

Eoin Woods: The cockroach build system.

Rebecca Parsons: So any closing remarks, Liz before we go on?

Liz Rice: I will just say, just reiterate, I'm not necessarily a fan, I just think they have longevity.

Rebecca Parsons: Understood. Rebecca.

R Language - Rebecca Nugent

Rebecca Nugent: Oh, sure. Thanks. So, when I started thinking about this, I thought very much about the statistics and data science world because that's where I am.

So, the first thing that came to my mind is the community-built or the community-developed tools that have evolved and grown, and people are still using after decades. They're using them in ways that maybe the original developers didn't even kind of imagine. But the principles were general enough that they could be extended.

So, for example, the R language is a really good example of that. So, I think S was created in '76 by John Chambers, I believe, at Bell Labs. And then S-Plus came out in a commercial version around '88. But then R came along in '93 and sort of grew and became this monster of an ecosystem that's now supported by the R Foundation for Statistical Computing.

There are so many other languages we use in statistics and data science, as well, but this one keeps coming back to this community-driven kind of organic growth idea. I have middle school students and high school students, who when they're coming to learn about our school, tell us about the R functions they're building and the packages that they're making.

So, somehow, it's accessible enough that people can start very young. They can feel confident, they can contribute. There are lots of different ways to interface with it, command line, graphical interface, IDEs, right through notebooks, and such. So, for me, I guess that's one example of software technology, I would say, from statistics and data science would be that kind of R programming language.

But I'm referring to the kind of community and the ecosystem that has grown and built over the years. So, that would be a good example, I think, for statistics and data science. Happy to hear what you guys think, if you use those, if you use that one, or if you prefer other tools.

Phil Winder: I think it's my responsibility to jump in on this and offer the rebuttal. And my first rebuttal would be if that's the case, then why is R considered to only be used in the realm of academia and not in the industry?

Rebecca Nugent: Right. That's a great question. I think it's not the only thing that people are using in academia and statistics and data science. Thank you for asking that question. I mean, we're certainly teaching Python, we're teaching SQL, we're teaching all kinds of things.

I think what people still use R for a lot of data analysis, like visualizing things, and so, then, using R maybe in conjunction with other languages and other tools to do more of the more complicated statistical computing and things that we need now for today's kind of large data science problems.

It's more that R is like a common entry point, I think, for a lot of new people, and then they move off kind of into other things or combinations. But to your point, I guess I more meant what I like about it is... Maybe this isn't that R is standing the test of time, but kind of the idea of building an ecosystem that people can contribute to, like an open-source community that can grow. I guess I mean that aspect of software technology standing the test of time. I think that's powerful.

Liz Rice: I'm gonna jump in and sort of agree and disagree. So, my experience of R is very limited and somewhat dated. And my recollection of it is that, because you get so many community-contributed versions of different packages, I guess. You might have half a dozen different implementations of a very different function. But they'd all have, like, the parameters in different orders. And it would be really hard to kind of, like, "Oh, I needed a different version of this function, but now I've gotta move everything around."

That felt to me as if it were something that is kind of...it's grown organically, it's been community-contributed, and it didn't feel like a very sort of self-organized community. Where, I think, particularly, now, the way that open source has become core to so much infrastructure, I'm thinking about Kubernetes and other cloud-native projects, where they're incredibly well-organized community-driven projects that still have that kind of very rigorous control, and, I guess, careful consideration of how APIs might change.

So, I guess I'm disagreeing in the sense of I'm not a massive lover of R. But I am agreeing that communities can build and that we're seeing the evolution of really well-organized community projects.

Recommended talk: GOTO 2020 • Data Science for Everyone with ISLE • Rebecca Nugent

Rebecca Nugent: Yes, and I would say that the development of R Studio and the Tidyverse framework, in particular, has moved more in the direction of what you're talking about. So there is a lot of kind of R, kind of going rogue, right, and people putting up packages and saying, like, "Use my package," and "Let's upvote that," etc.

But there are also a lot of very principled frameworks kind of that are coming out now, you know, frameworks that, if you ask professors who were teaching in R 10, 15 years ago, they would be like, "I've never even used that." So, you know, it's so new and it's so popular now. So, I think a lot o  my current college students, view R very differently from how I viewed R or learned it. I learned far more what you're kind of describing, that you're trying to find a package you want, you're doing a lot of web searching, right, you're trying to do things.

The students who are learning it now are having a very kind of different experience. Another kind of community thing you could bring up is they also just believe that you can get everything just on, like, Stack Overflow, right, or just, like, discussion boards. Well, this is maybe taking the panel in a different direction, but, like, I worry sometimes about how people are learning how to debug and solve their problems because some people are thinking, like, "Well, here's a principled way to go through this. Thank you." And then other people are like, I'm just gonna Google this and see if somebody else figured it out and then I'm just gonna cut and paste their solution." There are pros and cons there. But that's kind of another feature of the community stuff.

And just with my last 30 seconds, I want to throw out to the room that I think something that, hopefully, will stand the test of time, but it's a little bit newer in our space, is things like standard.lib, or, like, libraries for JavaScript and Node.js that are allowing us to do numerical and scientific computing for some of these large statistical data science models on the web. So starting to build interfaces where we can run...and I'll throw out for Phil here, reinforcement learning or deep learning or regression models or all kinds of things. But we're doing it with these, like, standard libraries that are being built with JavaScript and Node.js. We see that a lot more now, and I'm hoping that becomes a software technology that stands the test of time maybe in a, you know, in a few decades, etc. Thanks.

Rebecca Parsons: Okay. Thank you, Rebecca.

Rebecca Nugent: Yes.

Rebecca Parsons: On to you, Phil.

Machine Learning - Phil Winder

Phil Winder: Thank you very much. It was a good lead-in there. I like the link. So, I'm going to mix Rebecca and Venkat, I think, and produce my answer. When I was thinking of this, I was thinking of technology. And I think, like, the generic definition of technology is scientific knowledge applied or something like that. Then I thought, "Well, what's the test of time? What does that mean? So, I took it to mean something that's lasted as long as possible.

Related to my work in RL, and machine learning, and stuff like that, I kind of gravitated towards just purely machine learning, you know? And I know it's not technically a technology. It's more of a technique, I guess. But I think it's a really good case for this because it's been around for such a long time. I think it's gonna be around for such a long time in the future.

So, I mean, generally, using... This idea of being able to learn rules, to learn models, to learn from data, as opposed to, you know, presupposing what software should do, and us being, as software engineers, assuming that we know what the right program should be, you know, we should be learning from the world and learning from data and developing programs and software and models that can take advantage of that learning.

So I was gonna talk a bit about RL, reinforcement learning, which is the idea of learning from experience and trying things out, and trial and error, and things like that. And that's what my book's on. But I thought it's a bit too new. That kind of started around the 90s.

So, I stepped back a bit and went back to machine learning, because it has been around since, the 1950s, 1940s. The 50s is when it started to blow up. And it's been around for such a long time that it peaked in about the 60s and then sort of tailed off in the 70s and 80s again. So, you know, died off again. And didn't re-emerge until the 90s.

So, I think that is standing the test of time where it can go in and out of fashion. And I think somebody mentioned this earlier, this idea of cycles. Machine learning has already been through several cycles. And I can envisage it going through several cycles in the future as well. 

Rebecca Parsons: Cycle is a much nicer term than AI winter, which is what I normally hear.

Phil Winder: Exactly.

Rebecca Nugent: I also agree, and that resonates with me about the cycles. You know, we often hear things described as machine learning that I think some of us in statistics are like, "That sounds like logistic regression," which has been around forever but somehow, it seems like it's new. But I think that that kind of makes the point that you're making, though, is that these ideas have been around for a long time, how to learn from data, learn from the world around you. I do certainly think that concept is, of course, standing the test of time. I think it'll only get stronger and grow larger as we go, yeah.

Phil Winder: Yes, exactly. And still, the fact that logistic regression, or logistic regression used for classification, is always the most confusing thing to try and say and explain to people, you know, it's been around since, what, 1880 or something?

Rebecca Nugent: Oh, yeah.

Phil Winder: So, it's well over 100 years old now, and still commonly used in many models today. So, that's stood the test of time. I think we've got a total agreement.

Rebecca Parsons: Okay. Well.

Liz Rice: I could throw in one thought there about sort of machine learning, in general, more how it's used as a marketing term, which I'm sure is not really what you're referring to. But you do see a lot of companies using the phrase machine learning when I think what they mean is storing some data in a database. Remembering some variables, it's not quite the same as actually deriving any kind of real learning from a set of data. And so, I hope that that form of marketing-speak around machine learning does not last.

Phil Winder:: Yes.

Rebecca Nugent: No, no, I agree with you there. A lot of times, machine learning is used as a real sort of simple data analysis, right, and thinking about extracting insights from data, but it's not really how we might think of as learning, right? Like, for example, how Phil just described it, that's not what's happening. But I think you're right. The phrase is ubiquitous. It's applied to all kinds of scenarios. So, we'll see if that changes over time.

Phil Winder: Yes. It's such a philosophical problem, though, that's half the battle. It's like, how do you define learning, you know? It's a philosophical definition. And that's why I specifically didn't use the word artificial intelligence or AI. Because I think that that's even worse for that. I think that's overused even more by companies. And I particularly don't like that term. But yes, pros and cons.

Rebecca Parsons: Okay. Well, let's move on. Hanna, you're up next.

The monolithic architecture - Hanna Prinz

Hanna Prinz: Thank you, Rebecca. So, I feel like what I will propose is exactly the opposite of what people would expect me to propose. And I'm thankful for Venkat for mentioning that complexity is the enemy of programming or, of the things we want to do. So, I would propose the monolith or the monolithic architecture or the monolithic deployment because I wish it will turn out to stand the test of time. I feel like we have abandoned this idea in favor of many other ideas, and we still haven't figured out solutions for the main problems of these new ideas.

So, if we think about distributed applications, from my perspective, there are far more problems that still exist, that we haven't solved yet. So, I've been working on application infrastructure for the last years, which is why I was working on the topic of the service mesh, which was interesting to me. Because the idea is to make teams more productive, right? With many things that are invented now, it's meant to make teams more productive. But thinking about it, I believe that there are more basic things we can decide that will make teams more productive. For example, the monolith.

So, what I want to say is if we would invest the same amount of time in improving or reinventing ideas just like the monolith, that is technically simple, then we would come up with much better solutions than we have right now for distributed systems.

Nicki Watt: So, maybe just one thing from me. One thing that I will agree with, something that we see in our sort of consultancy is sometimes, people will reach for a far more complex system before they go for something more simple. And they'll go for microservices because it's the flavor of the day, and that's just what you do when you build a system nowadays. And I think that thinking is certainly not helpful because, sometimes, that is just the wrong architecture for the problem at hand. And sometimes, things are simple, and I think you should start simpler with something like, maybe, a monolith type.

When I think over time, I think there are cases where the architecture and the requirements would dictate that you might need to go to something more distributed, just because the requirements dictate that. But I think I would agree with you that, sometimes, people start at the wrong end now, they start at the sexy microservice end, when they should start at the more simplistic end. My rebuttal would be that I think, certainly distributed systems done right does still have a place or does still have a place..

Hanna Prinz: Yes

Liz Rice: Yes.

Hanna Prinz: I feel like we might not have tried to make monoliths done right. This is what I feel. But I agree that, of course, there is no one solution for everyone and everything. But it's worth thinking about complexity, you know, very, very early on and choosing the right thing for the situation. 

Liz Rice: So, I feel like I have to come in with a rebuttal because I have, you know, books about containers, and posters about Docker on the wall behind me. And, you know, I'm a big fan of cloud-native. I mean, I completely agree that you need the right architecture for the job, and, microservices is not always it. Functions as a surface are not always it. Sometimes maybe the monolith is the straightforward approach.

But I think we see so many advantages in things like the ability to scale things independently, the ability to distribute components across, you know, multiple servers, the ability to secure individual components and sort of adding extra layers of security around those individual components, that, although there is a big cultural change to moving from a monolith to moving to the kind of cloud-native microservices approach, there is a ton of benefit if you're building a complex distributed system.

I don't think it's just hype. I think people are doing it because it's turning out to be successful and allowing people to ship functionality quickly. So, I don’t think it is just a flash in the pan. Whether in 30-years' time, we will come back and say, "Yeah, microservices stood the test of time," well, we'll find out.

Nicki Watt: I think distributed systems have stood the test of time, though, in one way. It might be complicated, but I think the underlying principles and the way that they work are still the same, and that hasn't changed. But how we apply them, and whether we apply them correctly, I think, is where we run into trouble.

Venkat Subramaniam: I think the idea that Hanna proposes is very controversial because she is saying what a lot of us don't want to hear. That's one of the complexities of the world we live in.

I often associate a lot of what we do with resume-driven development. "We want to do it because everybody else is doing it. And how could I not be building another microservice?" And I always question this. If, overnight, 10 million people wake up and say, "I gotta build microservices," how could that possibly be correct for so many organizations?

So, I think there's good merit to asking that question, "Have we understood what's wrong with monoliths? Have we understood why it is not working for us?" So, often, we are eager to find a solution, but if only we can pause to ask what did not work and how we could improve it, I think can be better. Here's one of the fears I have working with a lot of organizations looking at architecture is are they building a microservice, or are they building yet another service-oriented architecture and calling it microservice?

So, that's one of the things that I want to question:  what problem are you trying to solve before you propose a solution? And I think it's a useful question to ask. Let's explain why what you build doesn't work before you find an alternative solution. So, taking the spirit of that discussion, I think there's really good value in asking, you know, "Are monoliths dead?" I don't think monoliths are dead. We haven't understood what killed it yet, if at all. And I think we should spend more time, I think.

Eberhard Wolff: Absolutely. Lately, I've read a text, and the text was about how the proposal was to use microservices.  I experimented. So, instead of reading the word microservice, I put it in the word module. And it turned out that the text still worked. So you can have interfaces between modules. You can have interface negotiations between modules. You can have modules that use different databases. And so on and so on.

It turned out that the whole text didn't give a reason. It was meant to give a reason why you would use microservices. And actually, it didn't. That's why I think a statement that says that we should look at monoliths is very valuable. 

There is another thing that I find interesting because you were talking about distributed systems. So, I would argue, as soon as you have a server that has a network plugged into it, it's a distributed system because it talks to some clients, it talks to some database, there is some network equipment attached to it.

So, the decision or the point that you do have a distributed system is, I think, different from the fact that it's a monolith or not. We do have distributed system because, unlike the home computer that I had in the '80s, the network is the computer, right? So, that's the world we're living in.

Rebecca Parsons: Ok. Thank you, everybody. Eoin, you're up next.

Message-oriented middleware - Eoin Woods

Eoin Woods: Thank you, Rebecca.

Okay. So, interestingly, my suggestion continues the distributed systems theme. When I was preparing for this talk, I realize two technologies have been around for a long time which I've used repeatedly, successfully to build systems. Luckily, I picked the other one because the first one was the relational database, which Nicki​ introduced us to in the first step. The second one, though, I've been involved, in using these, and also building them with system software. And I just think both of them are brilliant.

Mine is message-oriented middleware, which is the kind of product everyone loves to hate, and yet nearly everyone's got embedded right in the middle of their systems, and they're relying on it. When you introduce messaging, you're now into distributed systems for grown-ups, or maybe growing up distributed systems. Because everyone starts with microservices, for example, more services, with everything synchronous, and then they're trying to build something at scale and realize, "This has just got horrible courses." And they'll introduce asynchrony, they introduce messaging, only, they realize building their own messaging is going to be tough, because it's a lot harder than it looks, so, they introduce message-oriented middleware.

Although they claim that they hate it they push lots and lots of complexity down into it. And what do you know? Very quickly, they get magical improvements in their systems architecture. It's now more scalable. It's now more resilient. It's now more transparent as to what's flowing through it. They can use it for bulk data transfer. They can abuse it for all kinds of things it was never intended to work with.

And yet, it's got such a simple model. It's just got two concepts. It's got queues and it's hot topics. You can explain them to almost any developer in 10 minutes. And yet, having a grasp of that, they can then use these magical messaging-oriented middleware products to completely revolutionize the qualities of the architecture of their systems. So, I would argue that a lot of development teams have got a lot to thank message-oriented middleware for, as well as their relational databases. And it has stood the test of time.

It's not as old as RPCs. It's not as old as relational databases. But I think TIBCO RV, which was the first kind of middleware I used, I think that was introduced in about '96, '97. That was building on top of research prototypes. I think it's been around, what, well over 20 years, and that, today, it's quite hard to find a scalable system that doesn't have message-oriented middleware built into it, even if, perhaps, not too many people are using TIBCO RV anymore.

Venkat Subramaniam: I would say one of the things that we should also be careful about is testability. While the technology is really useful, it does increase the complexity from the point of view of the ability to test it. And interacting with certain teams...I wouldn't be naming them here, obviously...but where they've gone overboard with the event-driven architecture but did not take the care to write enough automated tests and audibility.

I've spent time with teams where the messaging layers did not handle the errors properly, and there were production problems that led to years of, you know, issues.They had to bring in a team of people to debug and find out what was going on. Tthis is not necessary  a rebutte against the technology, but more of how people get infatuated with it and end up using it, but don't spend enough time on the, maybe we should say, engineering practices that would make it sustainable in development, as well.

Recommended talk: GOTO 2020 • 3 Practices for Effective DevOps Adoption • Eoin Woods

Eoin Woods: I think you're quite right. Actually, the big problem I've seen, big mistake teams make, is they assume they run a tiny little broker in memory, inside their IDE, and they test on that, and then they hope that when they move on to a hundred-node massive enterprise broker, it will behave in the same way. But what do you know? They don't. And they never quite learned the model.

In particular, there are many promises and constraints, and unpromises that message-oriented middleware tends to turn up with. People tend to kind of assume it is just magical. Unfortunately, it's not quite magical. There are a few tradeoffs. Presumably, you've seen lots of problems like messages ending up being routed to impossible destinations, and so, never coming out the other end, that kind of problem. I agree. That sort of thing needs good monitoring, lots of testing.

The programming language - Kevlin Henney

Kevlin Henney: Hi, I'm Kevlin. The software technology that stands the test of time that I'm going to suggest is the programming language. Specifically, the concept of a programming language is a text-based notation through which we program our computers and create our systems and also the idea of specific programming languages in general, that programming languages tend not to die. 

So let me start with our second one first. Whenever anybody says a programming language is dead, if you look around, you still see that it's alive. Perhaps it's not as active as it used to be in its use, but normally it's still around. There's normally somewhere running that code. There is normally somebody who has created a compiler or interpreter for that or updated an old manual. The language is alive. It may not be very lively. It may not be on a growth curve, but it's still there and perhaps a better word than death for languages would be that languages become moribund, they reach almost the point of death, but not quite. And that's a really long tail. So whenever people pick a language you normally find - it's not that if they say that's just a that's just clickbait. So I'm not suggesting that we immediately all go out and find languages like PL/1 and CORAL 66 and things like that and start scaling up in them. But there's a difference between not really very active and completely inactive, which is dead.

So the first thing is the programming languages generally do not die, they just linger. This leads us to this other observation that for almost as long as programming languages have existed in the earliest programming languages that were not just straight assembled,  we kind of conceived of in the 1940s, and we have things like Plankalkül dating to the late 40s as a notation that was not implemented for many years and never caught on but was highly influential. We have languages like ALGOL and Fortran that came from the 1950s. ALGOL 60 was the first proper implementation that people started using and that we still live in the shadow of and most of the languages that we use in terms of things like scope We have languages like Lisp that were designed in the 50s and were implemented in 1960. These still linger. They are still around. Go and watch The Martian as a film. The code that they show in that is Lisp. If you're using Emacs you are using Lisp. You're using Clojure. Yeah, that's a Lisp language. In other words, these are still with us. You go and look at the current jobs. All these languages are mostly old. You don't see a lot of people recruiting for things that are not languages. Oh, those things happen. They come up every now and then.

There's a visual system and there's normally a bit of popularity and excitement around them for a few years. People say, oh, you know what, we don't need to code or you can code in English. We've seen this before and we've seen it arrive and we've seen it leave from the very same platform. Of course, there are points of progress. There are systems where we don't use code primarily, but they have an interesting tendency, perhaps the most widely used programming system that does not directly use code in the way that most people use. It is Excel, except that it's also got VBA and Excel has just recently acquired lambdas. So actually it's a proper programming system based on the programming language. It happens to have a convenient grid-based interaction model that most people are familiar with. 

The point here is that I'm fully expecting that in another few decades, programming languages will still be there and people will still be making the same complaints. Perhaps we could do this without programming languages and they will discover that it turns out that the system of writing and the system formalisms that humans have created are surprisingly effective, unreasonably so. And they're not going to go away. That's going to change. So thank you very much and I hope you have some thoughts about that.

Rebecca Parsons: Great. Well, we've had quite a combination of ideas here, from hardware and languages and language categories, architecture, system software. The variety has been quite fascinating. I've enjoyed listening to all the recommendations. Unfortunately, we don't have time to do a closing vote, so, you'll all have to decide for yourselves if you've made a compelling enough case for your software technology that stood the test of time. I'd like to thank all of you for appearing on the panel and thank you.

What was the most surprising proposal? 

Preben Thorø: Thank you so much, all of you. This has been so inspiring. I'd like to, just as a closing remark... We are getting very close to the end here. I'd just like to ask, out in the open, which ones surprised you the most from the other panelists here?

Eoin Woods: To me, Makefiles. I was not expecting that from Liz.

Rebecca Parsons: Well..

Liz Rice: Well, like, a lot of the things that I talk about, are way too new to call them, you know, stand the test of time.

Rebecca Parsons: When you were doing your lead-up, Liz Rice, I thought you were gonna say Emacs. I don't know why.

Rebecca Nugent: I agree.

Rebecca Parsons: But everything you said, I said, she's gonna say Emacs.

Liz Rice: Well, Rebecca, you don't know me. I'm a Phi girl. I'm a Phi girl.

Rebecca Nugent: I asked some of my colleagues their thoughts, right, about software technologies that stand the test of the time. And one of them did bring it up... They're like, "You gotta talk about Emacs." And I was like, "I don't know. We'll see."

Eoin Woods: I nearly brought Emacs, but I thought it didn't stand the test of time.

Rebecca Nugent: Yes, exactly. But it's kind of a community-driven kind of thing, you know, so yeah.

Eoin Woods: Yes.