00:00:05 Introduction of the topic of maintainability of supply chain software.
00:01:22 Explanation of how software can degrade over time, using Microsoft as an example.
00:03:01 Discussion of the differences between maintainability of Microsoft products and other software.
00:04:16 Explanation of why software must change over time due to changes in computing hardware and security concerns.
00:07:50 Discussion of the perspective from which maintainability should be considered and the problem with looking at it from the survival of the vendor.
00:09:08 Microsoft’s compatibility with over a million printers as an example of the scale of the task.
00:10:07 How software design affects maintainability and the need for engineering software to be highly maintainable.
00:11:07 The importance of analyzing the incentives of vendors in ensuring software maintainability.
00:13:03 Maintainability is a matter of design and that the conservation of technological mass is key to having a maintainable product.
00:16:00 Discussing the importance of software maintainability.
00:17:00 Vendors’ incentives to ensure software maintainability.
00:19:00 How to identify maintainable software.
00:21:02 Symptoms of unmaintainable software.
00:23:13 Final thoughts on the importance of software maintainability.
Summary
In an interview, Kieran Chandler and Joannes Vermorel discuss the importance of software maintainability, particularly in supply chain software. Vermorel argues that maintainability is primarily a matter of design and that it is often overlooked by companies who focus solely on a vendor’s survival. He notes that software becomes unmaintainable over time due to changes in technology and entropy, and emphasizes the importance of compatibility, security, and simplicity in software design. Vermorel also warns against falling into the trap of using flashy user interfaces and suggests thoroughly challenging developers on their plans for maintainability to ensure long-term viability.
Extended Summary
In this interview, Kieran Chandler and Joannes Vermorel discuss the challenges of maintaining supply chain software and how good design can impact its longevity. Vermorel explains that while software doesn’t degrade like physical objects, it does fall apart over time due to entropy and changes in the technological landscape. Companies like Microsoft have been successful because they have shown a strong commitment to the long-term survival of their products, making it possible to open and use older documents today.
Vermorel notes that Microsoft’s ability to maintain their software’s longevity stems from their immense investments in maintenance and their focus on compatibility. He contrasts this with Linux, which, while leaner and more sensibly organized, does not offer the same level of backward compatibility. Vermorel acknowledges that supply chain software is even more complex due to its distributed nature and the numerous moving parts involved.
Maintaining supply chain software is made more difficult by the fact that computing hardware continually evolves. While virtualization can help mitigate some issues, it’s not a perfect solution. Additionally, the way users interact with software is constantly changing, such as the increasing prevalence of touch screens and higher-resolution displays. Older software may not be designed for these modern systems, making it less intuitive and potentially insecure.
Vermorel argues that software maintainability is often overlooked and misunderstood. The typical concern is whether a vendor will still be present in the future, but he believes this is a weak angle to approach the issue. He points out that having a surviving vendor is a bonus, but not a guarantee of maintainability. In fact, some vendors have a perverse incentive to create unmaintainable products to sell new versions.
The interviewee emphasizes that the problem of maintainability should be looked at from a different perspective. He explains that complex software, like enterprise supply chain systems, have millions of moving parts and numerous companies working on them simultaneously. These systems face constant upgrades and changes to remain compatible with various hardware and operating systems. Ensuring compatibility becomes a massive undertaking, as Vermorel illustrates with Microsoft’s compatibility with over a million printers.
He argues that, by default, software is not maintainable unless it is specifically engineered to be so. He also stresses that the focus should not solely be on the survival of a single vendor but the entire ecosystem of companies involved in the supply chain. Vermorel believes that maintainability is primarily a matter of design, particularly in the conservation of technological mass.
To win clients through demos, companies often use the latest and most advanced technologies for data visualization, user experience, and real-time analytics. This creates a “wow effect,” which can be a selling point. However, Vermorel challenges this approach, citing the example of outdated-looking ERP screens that resemble text terminals from the early ’80s. Despite their appearance, these screens are incredibly fast, responsive, and have minimal dependencies, making them highly maintainable and efficient.
Vermorel emphasizes that not every layer of software needs innovation, as it’s more important to have stability in certain areas like calendar management or password storage. He also notes that software engineering has a rich history to learn from, and maintainability should be a priority. However, clients and prospects often overlook this aspect, focusing more on whether a company will be around in the future rather than the maintainability of their software.
To determine whether a piece of software is maintainable, Vermorel suggests looking at the incentives offered by the vendor. For example, a vendor that charges hefty implementation fees and concentrates revenues at the beginning of the project may have an incentive to repeat those fees as often as possible. Lokad, on the other hand, charges a monthly fee with no commitment, ensuring that the company has skin in the game and making maintainability a priority.
Vermorel also highlights the importance of Software as a Service (SaaS) solutions, as they ensure that the vendor is responsible for the maintenance of their own software. He warns against technological complexity, where companies boast numerous cutting-edge components that may become a nightmare to maintain due to their individual life cycles. Instead, he suggests that a simple, maintainable solution should be the priority for supply chain practitioners.
Vermorel explains that even though companies invest in supply chain systems, they often become unusable over time due to various glitches and issues that emerge. As the number of glitches increases, the software becomes harder to maintain and operate. Consequently, users abandon the system’s features and revert to using Microsoft Excel spreadsheets as a workaround.
He shares that this situation is a common occurrence in the industry and reflects the symptoms of a solution that has become completely unmaintainable. Vermorel warns that flashy user interfaces do not necessarily guarantee a well-functioning product and may even hide potential maintainability issues. On the other hand, outdated user interfaces can also be a red flag, as it may indicate a lack of maintenance and updates from the vendor.
To avoid falling into the trap of unmaintainable software, Vermorel advises companies to thoroughly challenge developers on their plans for maintainability and understand the key design decisions that contribute to the software’s long-term viability. He emphasizes that without carefully considering maintainability, software in the industry tends to be unmaintainable by default.
Vermorel concludes by highlighting the similarities between supply chain software and high-frequency trading systems in finance, noting that both often utilize text-based user interfaces. While these interfaces may look outdated, they are efficient and maintainable due to their minimal dependencies and streamlined design.
Full Transcript
Kieran Chandler: Hey, when investing in a piece of supply chain software, there is the expectation it will last the company decades rather than just years. However, from the perspective of the vendors, the rapidly changing tech landscape means just maintaining this is no mean feat. As such, today we’re going to discuss maintainability and why it’s such a challenge, and also understand how it can be impacted by good design. So it’s an intriguing topic today, and maintainability is something that you’d normally think wouldn’t be associated with software. Software doesn’t really degrade. So, what’s the idea?
Joannes Vermorel: Well, actually, software does degrade. Yes, it’s not like mechanical degradation, where there is tear and wear after use, and things become physically fragile to the point they break down. Software is not the same thing, but things do fall apart over time. That’s something that is maybe very surprising because some of the largest and most successful software companies, let’s say Microsoft, have been precisely incredibly successful because they had an insane commitment to the long-term survival of their products. It’s literally a testament to the success of Microsoft that, at present time, you can take a Microsoft Word document that was edited in 1995 and open it, and you can still print it. It’s incredible, but it’s also what most people fail to realize: that Microsoft was fairly unique in this regard, having this mindset of long-term commitment to their products. If you were to try any of their competitors, and nowadays, people don’t even remember that Microsoft Word and Excel had plenty of competitors, none of it would actually work.
So, let’s go down the path that software degrades, and it mostly degrades due to entropy, to the fact that this is a forever changing landscape. The hardware is changing, and software is a very composite product. At its core, to run anything, you’re typically involving dozens of parts provided by dozens of companies, and those things are not naturally very well maintained over time. When there is something that changes, there is no clear reason why all the other parts would remain completely compatible and correctly integrated with the part that has just changed.
Kieran Chandler: Yeah, I mean, the tech landscape is one that’s really changing and changes very rapidly. So, what is it that Microsoft did well? Why is it that they could impact upon the longevity of their software?
Joannes Vermorel: At the core, they really cared and made insane investments for that. A lot of people complain that Microsoft Windows is so bloated, that you have so many things, and if you go for a Linux operating system, it’s so much leaner, better organized, and more sensical overall. That’s true, absolutely true. But try to run a program that was written for Linux 25 years ago; it will not run. The games that I purchased as a teenager back in the 90s for Windows 95 still run nowadays. So, I believe that this illustrates that.
Kieran Chandler: You can do things right with, I would say, an insane level of commitment. And if you read the Microsoft blogs on what they are doing to ensure maintainability, I would say they go to insane lengths, literally. Now, for supply chain software, you cannot expect the same degree of commitment, just because the market is not as large, and you simply don’t have companies that go into such extensive lengths to do that. Plus, you have another problem, which is that supply chain software is also very, very complex because it’s typically distributed, and there are many, many moving parts. So that makes maintainability all the more complicated. And now the question is, why do you have any change at all, and why can’t you just freeze a piece of software and stay with it forever?
Joannes Vermorel: The answer is, first, the computing hardware itself is changing, so you can’t just say this thing will run forever. I mean, yes, you can now use virtualization to mitigate most of those problems, although virtualization is frequently not quite completely perfect emulation of the hardware that you used to have, so it can help. But then, it’s not just the hardware to do the compute; it’s also the fact that, for example, the way you consume screens has changed. Screens have a lot more pixels nowadays, you can have touch screens, and you have plenty of things that don’t exactly behave like the old systems. Sometimes you have even weird systems, like where you have keyboard keys that are just gone. So, if the software was designed for a certain key, it might have been obvious at the time, but now that the key is gone, or the setup of the keyboard is different, it’s much less intuitive.
And then, that’s just one part of the problem that is evolving relatively slowly, but then you have all the security issues. Most of the software that has been produced historically was absolutely not designed for the modern threats that we have nowadays. So that puts immense pressure to basically change tons of things in many, many software components.
Kieran Chandler: So people always kind of want to be using the latest tech when they’re in their workplaces. Would you say that’s more of a dominant issue or is it more the security side of things and the fact that it wouldn’t be safe to use these people?
Joannes Vermorel: First, maintainability is a sort of issue where supply chain managers are mostly unaware of it, and when they are aware of it, they only see the problem through an angle which I believe to be exceedingly weak, which is whether the vendor will still be present or not. And my proposition is maintainability has nothing to do with the survival of the vendor. Yes, having a vendor that is still alive is kind of a plus, but it’s not even that much of a plus because, let’s face it, many vendors have a massive perverse incentive to have something that is absolutely not maintainable. How are they going to sell the next version otherwise? If we go back to why I would say that usually this problem is even absent, it’s that you’re not looking at the problem from the right way.
Kieran Chandler: You have to think that, imagine, you know, a complex piece of software like an enterprise supply chain system. Imagine a system that had, you know, millions of moving parts, literally millions, and you had dozens of companies who were tweaking at any single point of time, you know, some of those parts for a huge variety of reasons. Sometimes you want to be compatible with new hardware, so when you do that, you might actually create accidental incompatibilities with some ancient hardware. You might want to be compatible with a new operating system because, for example, Linux keeps changing, Windows keeps changing, so you want to basically be compatible with the latest. But by introducing some compatibility with the latest system, you might accidentally introduce some incompatibility to the ancient system.
Kieran Chandler: And just to give you an idea of the scale of the task, I was reading on a Microsoft publication that, at one point, Microsoft was ensuring compatibility with over a million printers. Just think of it, one million printers with different drivers, instruction sets, different hardware, etc. This is how much engineering effort do you need to ensure compatibility with one million devices. This is borderline insane. And then you always have people say, “Ah, Windows is such crap. I’ve just plugged my 17-year-old printer that was the Epson 7.1.6 point B, Slovakian edition, and guess what, Microsoft is not 100% compatible with this device, which is obviously such a flagship reference.”
Joannes Vermorel: But, joke aside, you have this massive piece of software in supply chain with tons of moving parts. The database you rely on is constantly upgraded, the network layers you’re using are constantly upgraded, the web server that you’re using is constantly upgraded. You have so many moving parts. And by default, what you have is, unless you engineer specifically your software to be highly maintainable, it’s not going to be maintainable. The thing about supply chain is it’s much more of a longer game that people are playing. It’s not only the vendor that we should be thinking about, is how are they going to stick around, but it’s also all the people that the vendor interfaces with. And so, how much confidence can you actually have that these other companies will still be there in the future as well? So again, the fact that companies will be there or not, mostly, I don’t care. This is not the proper way to think about that. If you have vendors that are still there but have a vivid incentive to make the thing unmaintainable to sell more, have you actually made any progress toward maintainability, or have you run in the opposite direction? You need to analyze the situation through the incentives that people have. That’s another thing, is that mostly, I believe maintainability is pretty much a matter of design. But what kind of design exactly are we talking about? And here, I believe that it’s mostly about the conservation of the technological mass.
Kieran Chandler: You see, if you want to have a product that makes very cool demos, what do you need? You need the latest and coolest data visualization library, the latest and coolest UX library. If you want to have fancy real-time analytics, you need to have the latest and coolest subsystem to do that, and so on. Your incentives to win clients through demos is to have a wow effect. For example, a lot of my clients were telling me their ERP screens just look like text terminals, just black and white pure text. They were saying, “Oh, we really have to do something.”
Joannes Vermorel: I challenge that because when I look at those terminals that look like we’re back in the early 80s or late 70s, I see people using them and they’re super fast, incredibly responsive. The screen is ultra-minimalistic with just a few commands that you have to know by heart, but that’s it. There’s no distraction whatsoever; it’s purely utilitarian. People have an insane productivity with it. Yes, it looks like crap, but it’s highly maintainable because you have literally no dependency whatsoever and certainly no web dependency with web browsers that keep changing.
So, if you look at both the oldest part of supply chain and the most advanced part of high-frequency trading in finance, you’ll see that the user interfaces are similar. If you look at those quantitative traders that are using super advanced systems, their UI looks like a text terminal again. It’s kind of bizarre, those people are absolutely state of the art, and their UI looks completely outdated. It’s the opposite of what you would think of Hollywood movie user interfaces.
Kieran Chandler: It seems kind of frustrating because everybody wants to be using the latest technologies. So, are you saying that having a product that’s very maintainable means that ultimately you can’t be very much at the cutting edge?
Joannes Vermorel: If you’re cutting edge in terms of maintainability, why not? I’m not saying that we haven’t made progress in this area as well, we did. It’s just that it doesn’t trigger any kind of wow effect. When you have very clean versioning strategies in place and the components that you pick have some very interesting philosophies, such as being flexible or picking software components where the philosophy is about maintainability, that’s great.
There are some components that we use that are open-source components with exactly this philosophy. They say there is a manifesto: this problem has been studied for the last 20 years, and we have converged on what we feel is the best trade-off in terms of design. Now, all we will ever do with this component is proper maintenance just to ensure that, in terms of security, there are no serious issues.
Kieran Chandler: In terms of compatibility, there are no accidental problems, and we will not keep reinventing ourselves. So you say it’s disappointing, it’s the opposite of innovation. But again, do you need to have innovation on every layer of your software? Are you going to keep reinventing the way you’re dealing with your calendar, or the way you’re storing passwords, for example, unless there’s some cryptographic attack that requires you to upgrade? So, you want to choose things where you already have stability.
Joannes Vermorel: Software engineering is not a new discipline. We have about 50 years’ worth of history to learn from. But the question is that, again, because clients or prospects don’t pay attention to that, they ask naive questions like, “Are you going to be still around?” versus “What is your incentive to make really sure that your software is maintainable, as opposed to doing the opposite so that I will buy your next license?”
Kieran Chandler: So what should the supply chain practitioner be looking out for? What are the clues that there’s a piece of software that’s very maintainable compared to a piece of software that’s maybe just a bit old-fashioned and people are just being lazy?
Joannes Vermorel: First, I would say, just look at the incentives because it’s not so technical. For example, if you’re buying a license or something where the vendor is charging hefty implementation fees, that means their revenues are concentrated at the beginning of the project. What happens afterward is just less of the same, so it’s literally a downward trend. The vendor has a structural incentive to have those hefty implementation fees repeated as frequently as possible.
Now look at Lokad. We charge a monthly fee without commitment, and we typically break even after two years. The maintainability is basically a flat fee, so the cost in terms of maintainability is eating into Lokad’s margin. When I positioned Lokad, I decided that we have skin in the game, that we are paying the price of having unmaintainable software, and that gives us massive incentive to make something maintainable. There is no money to be made, and quite the opposite, there is money to be lost for us as a vendor if it’s not maintainable.
So, a monthly subscription where you ensure that your vendor is losing money at the beginning is a very good, healthy start that frames the problem, so it’s going to be maintainable. And then, you want to make sure that the vendor is dealing with the maintenance of their own software, which is basically what Software as a Service (SaaS) is about. If it’s unmaintainable, it’s first and foremost the vendor’s problem, not your problem as a company operating.
Kieran Chandler: So, talking about the supply chain software, I often see slides and PowerPoints of competitors showing all the pieces in their solution. It looks like they have 20 super sophisticated, complex subcomponents, like TensorFlow, Apache Spark, Kafka, MongoDB, React, Redux, and many more. They claim to be state of the art, but when I see this, I think it’s going to be a nightmare to maintain. Each component has its own lifecycle, and there’s no guarantee that they’ll work together in the long term. Can you share any examples where you’ve come across unmaintainable software and the issues that led to it?
Joannes Vermorel: At the symptom level, you could see that when people give up on the software and switch to using Microsoft Excel and spreadsheets for managing supply chains. It’s not like large companies haven’t purchased supply chain systems; they might have even purchased three of them over the last few decades. These systems have complex forecasting, replenishment, assortment optimization, and promotion management modules. However, after the initial implementation, which was supported by the vendor, people start encountering glitches. Over time, these glitches pile up and the system becomes harder to maintain.
Kieran Chandler: So what happens when they give up on the software?
Joannes Vermorel: When people give up on the software, they abandon the features entirely and fall back to using Excel spreadsheets. They decide to pick their battles and focus on just one thing – exporting data to an Excel spreadsheet. They surrender their hopes of making anything else work but the export to Excel feature.
Kieran Chandler: Spreadsheets, and that’s a story that I’ve seen in dozens of companies. It’s literally the symptoms of a solution that has gone completely unmaintainable.
Joannes Vermorel: Okay, if we start concluding today, the core message is that all that glitters is not really gold, and we should maybe be a little bit wary of those companies that have got flashy UI interfaces because there may be issues of maintainability in the future. I mean, again, I’m not saying that having a garbage user interface is a solution either. If you’re dealing with a vendor whose solution looks like it’s from the 90s, the chances are that it’s so unmaintainable already that the vendor did not even manage to upgrade their UI. So, there is no hard rule, but my advice is that you need to challenge even internal development, in-house software. You really need to challenge people who are in charge of the development. What is your plan for maintainability? What are the key design decisions that you are making now to ensure that your software will be maintainable? And again, if people don’t have a very precise vision of how the design decision that they are making is shaping the future maintainability of the software, then, as a rule of thumb, you can assess that the software will be unmaintainable because it’s a default status of products that are engineered in this industry without carefully paying attention to maintainability. It’s unmaintainable by default.
Kieran Chandler: Okay, we’ll wrap it up. That’s everything for this week. Thanks for tuning in, and we’ll see you again in the next episode. Thanks for watching.
