Enterprise software makes victims of the people it touches.
Perhaps you’re the end-user fighting an arcane interface or a manager wondering what happened to her team’s productivity. It used to be that we’d accept this as a fact of life. Enterprise software is bad; the Earth revolves around the sun; don’t march on Moscow.
But then the iPhone happened. Before you roll your eyes, bear with me: the iPhone put polished apps into the hands of millions. Combined with improvements in consumer software generally – including web apps – that meant expectations changed. But enterprise software did not keep up.
As OutSystems CEO Paulo Rosado puts it, “One type of enterprise software is bad and then there is another type of enterprise software that’s really, really bad.”
In my last post, I looked at some of the reasons behind enterprise software’s poor reputation. Recently, I spoke to Paulo, and one of the OutSystems co-founders Rodrigo Coutinho, to get their take on why enterprise software tends to be unsatisfactory.
Does Enterprise Software Deserve Its Poor Reputation?
I started by asking if it’s still fair to say that enterprise software is bad.
“It’s fundamentally about three things,” Paulo told me. “The first is that enterprise software is usually very inadequate and incomplete. Typically, whenever you deployed a piece of software inside the enterprise, you only really had two options. You could buy a package off the shelf, or you could build your own software.
“When you bought something off the shelf, usually CIOs tended to make one fundamental mistake: they’d take something that was very rigid and they would mold it and twist it so that it would fit. And a lot of these packages could not sustain that type of elasticity.”
Customizing that off–the-shelf software meant deploying something that would miss the mark by some margin. And, of course, people tend to be bad at estimating how much customization is necessary; it’s not unusual to go into a project expecting to customize 20% of the functionality but actually finish up reworking 60%.
If there wasn’t an off-the-shelf option, the alternative was to build it in-house. “And in a lot of cases, that was even worse,” Paulo continued. “Because not only would you take a long time to build the systems but the quality was really bad. And so eventually, they’d crash and become very slow. Usability would be terrible. Eventually, technical debt would get to them and they would have to be replaced.”
It’s understandable if off-the-shelf software is a poor fit, but shouldn’t in-house custom-built software be better? Both Paulo and Rodrigo blamed a culture of specifying everything up-front.
We Don’t Know Everything Up-front
Rodrigo: “Because enterprise software was so expensive and hard to build, the business wanted to make sure that they gave all the requirements to the development team before they started building. On the development side, they knew these requirements had to be signed in blood almost, or else the business would change their minds halfway through. And so, enterprise software was built based on this lack of trust between those two sides, with a huge contract in the middle that stipulated exactly what needed to be done.”
Contracts and reality drift apart easily. What was true at the beginning of a project is unlikely to be true at the end. Then the project overruns and what was a two-year plan becomes a three-year nightmare. The world moves on but the contract stays the same.
OutSystems was born in 2001, the year of the Agile Manifesto. Both OutSystems and agile were reactions to the evidently broken system of software development that many organizations used.
According to Rodrigo, reliance on up-front contracts was at the heart of the problem, “Now, there are two problems. The contract says what needs to be done, but not how. As development went on, and with the stress of the deadlines, developers were worried about the functionality, and not so worried if it was easy to use.
“The other problem was that since the contract was fixed, there wasn’t any room for user testing and making sure that they were building what the business needed, rather than just what the contract said.”
Replacing Paper Systems Is Hard
For Paulo, the mismatch comes from the fact that much enterprise software still in use today was the first to replace paper systems. “The definition was often fundamentally flawed because you were asking people who’d never used a digital system before to tell you how they would disrupt and change their work based on the introduction of a new digital system. You’d ask people to design a system from thin air.
“People are actually really bad at disruptive innovation. They’re really good, though, when you design a prototype and you let them experiment. Then they can give incremental feedback. That’s why waterfall processes are being almost completely replaced by agile methods.”
Even in 2017, many current enterprise systems are the direct replacements of legacy paper-based systems. Paulo told me about one company’s project to create a digital invoice payments system, “The new digital system was designed so you would receive invoices through an e-mail address, process them and then distribute them through nineteen cost centers. Invoices above a certain value would then need to be signed by one of nineteen directors.
“When asked if they would migrate from signing a check to approving payment by just clicking a button and entering a code, the cost center directors all said, ‘Yes.’
“After deployment of the system, we realized that we now had personal assistants with €250,000 of approval capacity because all the cost center directors had given their passwords to their assistants. They were, in fact, the people who prepared the files in the paper system. Previously they had to ask the director to check what they’re prepared and then have them sign it. Now, that process was broken.
“What was interesting was the way we fixed this. Because we already had this low-code platform, we could add the executive assistant profile into the system easily. We changed the interfaces so that the assistants could pre-approve everything, and then take a computer to the director for final approval.”
The Zero, One, Infinity Rule
The blame, such as it is, doesn’t lie entirely with poorly defined contracts. According to Paulo, the way universities teach computer science is at least partly to blame for confusing user experiences, “I suddenly realized, as I was talking with a lot of my engineering colleagues, that all of us are biased towards a particular phenomenon that gets imprinted in university.
“We are prone to design systems based on the notion of completeness. A programming professor used to tell me, ‘You guys have to master the zero, one, infinity rule,’ which means when you design an algorithm for something, you need to tackle the boundary case of zero, the boundary case of one, and then you need to create some form of algorithm that would resolve all other cases.
“It’s really good for a certain type of problem, but it’s really bad for user interfaces. Computer science engineers have a reluctance to design user interfaces for the top seven or eight use cases, because eight is not a number that’s acceptable by a computer engineer. You accept the zero. You accept the one. And then you solve the general problem. In a lot of ways, that has created really bad enterprise software. Because until very recently, and we still see it today, there are no usability engineers inside corporations.”
The Influence of Mobile
Rodrigo and Paulo agree that the move to mobile has forced enormous change in enterprise software. For Paulo, mobile apps have trained people to expect high quality experiences and so they’re far less forgiving when enterprise mobile apps are bad. “It’s so hard to get a mobile app right that it has created a much better pressure mechanism for good software.
“Mobile apps are an all-or-nothing game. Either you’re designing for extreme usability or people do not use the app. I’ve talked with a lot of CIOs who have tens of mobile apps in the graveyard. There’s simply no adoption. It’s a completely wasted investment.
“That has created failures for a lot of CIOs and they became very sensitive to, ‘If we’re going to do this, we really need to get usability right.’’”
So, What’s the Solution?
Let’s be honest; not every business has the resources to throw hours of usability research and testing at every line of business application they develop. They might not even have a dedicated designer.
For Rodrigo, the answer lies in low-code platforms, “I have a bright view of the future. At OutSystems, we have this concept that we call the Silk UI. Out of the box, it gives you a bunch of patterns that are very usable and beautiful to the eye. With Silk UI and a low-code platform you can build usable and pretty interfaces very fast. And I think this is where enterprise software will go. You’ll have these patterns that you’ll use and reuse in your applications and that will do the bulk of the work for the developer.”
The beauty that is Silk UI
Paulo sees the combination of agile, iterative processes and low-code as the solution not just to better mobile experiences but to helping larger enterprises keep up with all the new technologies they have to tackle. “Using the OutSystems low-code platform, in a matter of days, two, three days, we can design high-fidelity Android and iOS applications that you can then experiment with on your phone.
“And that process is very enriching because the moment you see this thing working on your phone, in the context of where you’re going to use it, you can detect patterns that, before, were impossible to find.”
“For instance, we had a case where we were building a tablet system for use on a nursing ward. Testing it in the context of the hospital, we realized that one of the problems was that the tablet was too big for the pockets of the staff’s coats. And so, they would leave the tablet behind, dramatically changing the use case.”
The team at OutSystems sees a world where enterprise software must keep up with waves of new technology but where it will be harder for companies to maintain teams with all the necessary skills.
“The number of computer scientists being produced,” says Paulo, “it’s increasing slowly but it’s not matching demand. So that gap is widening. That’s why we believe that you need to do much more with fewer people.
“A platform like OutSystems, for instance, does that work. When we see a new technology that’s going to become an absolute must inside an enterprise, we introduce a low-code version. So it becomes really easy to add to an application, to manage, to deploy, and to change,”
Low-code is one answer to the problem of bad processes and stretched teams leading to poor quality enterprise software. Taking a step back, how do we fix those bad processes at source?
In the next interview in this series, I’ll be talking to one of the authors of the Agile Manifesto. We’ll dive more deeply into how process affects the quality of enterprise software.
Want to hear the interview with Paulo in its entirety? Check out the podcast.