Digital Exprt Whitepaper

Software Must Become Relationship

Computers run on software. In the early days, when people wanted to make computers do something useful, there was no other option but to write a computer program from scratch. As the computers became more pervasive and ubiquitous, a number of useful software programs became available. That way, not every task had to be hand-programmed.

Many such canned computer programs became commodities. The economy of scales made specialized computer programs affordable. Since many people and many organizations were prepared to purchase popular computer programs, such products became commodities.

Customization

Not every task can be easily pre-programmed. Commercially available computer programs (i.e. software) tend to address the most likely cases for the problem domain they intend to solve. These solutions inevitably converge toward the least common denominator. In other words, not particularly useful. The real usefulness of software is in its ability to automate business (or personal) operations. The emphasis of every software development project is to focus on automating identified business processes.

Since business processes are exceedingly complex, any automation that is initially based on least common denominators needs to be customized. This customization requires intense protracted focus. Strong focus is needed in order to fully decompose, understand, and implement the process and then customize as much automation of the process as possible.

Do You Feel Neglected?

The early enthusiasm of having machines take over the operational chores is slowly waning. The novelty of being able to use software that is capable of automating some crude processing is wearing off. We (human users) are starting to feel shortchanged in this game of automation.

Software development is dedicated to serving the complex needs of the machinery. This machinery is sometimes the underlying computing machinery, and sometimes it’s the actual business machinery. In short, the machinery that is needed to run business operations smoothly and efficiently.

But what about serving the needs of humans? No one seems to be paying attention to that side of the equation. More and more, we, the human users, are starting to feel neglected in this process.

What Is Missing?

We see that by working on customizing the automation of the business processing, software development completely ignores the human side. When we talk about the relationship between human users and software apps, we see that the only role users are expected to play is the role of assistants. All software apps today expect human users to do all the heavy lifting, do all the thinking, fill in the gaps and fill out seemingly endless forms.

The only concession given to humans in this process is at the UX front. The discipline of User Experience (UX) specializes in enabling users to better assist the machinery. But that is too little, too late. It is high time we revert the orientation and start designing and building software that will serve us better.

So the goal is NOT to create software that will be better served by humans. The goal is to create software that will serve humans better.

Why Do It?

Right now we only have software apps that enable us to perform some self-serve actions. We accomplish that self-serve by operating those apps. We perform most of the heavy lifting, handholding the app, telling it what to do each and every step of the way. That process is inevitably tedious. To remedy the perceived tedium, software designers are investing a lot of effort in designing and building the ease-of-use. That intention, while undoubtedly noble, is akin to barking up the wrong tree.

Right now, our usage of software apps seems to be at the stage of power tools. Even though power tools (i.e. software apps) are much easier to use than doing everything manually, they’re still falling short of serving us properly. For example, an electronic calculator is a power tool that can help expedite the tedium of performing complex calculations. Still, we are expected to tell the calculator what to calculate. And that basically means we need to hold its hand and we need to make all the decisions, and then manually plug in all the numbers.

For example, if we want to automate some workflow, we can do it either manually, or strive to implement some sort of workflow automation. Of course, it would be much more desirable to automate the workflow, in order to minimize the workload and also minimize the error rate, while maximizing productivity. So we usually opt for upgrading from processing the workflow manually to processing it automatically. But how we do it actually falls short of the expectations.

Any workflow automation solution in existence today is based on proposing the usage of power tools. What that means is, similar to using an electronic calculators, users are expected to use a software app that helps expedite some crude calculations etc. But the actual workload, the actual thinking and decision making (plus the actual data entry), is still entirely left to the human experts.

It is this thinking and decision making and data entry that is the absolute hardest part of the workflow processing. And currently none of that hard part has been automated. So the existing ‘power tools’ are actually quite useless.

It is precisely because of that uselessness that we must push the boundaries and break through to the next level, where we will finally achieve the real automation. And why would we want the real automation? For the simple reason that machines are put together precisely for doing the heavy-duty labour, while humans should be freed up to do the creative, non-mechanical work.

How To Do It?

We have seen that leaving all the thinking, decision making and data entry to the human experts is insufficient when we’re talking about the full automation of some processing. The only way to accomplish full automation is to act on behalf of the human expert. By acting on behalf of the human expert, software app must be able to think, to make decisions, and to supply the pertinent data.

That seems easier said than done. We don’t seem to have a working model, or a precedent on which to base such plans. So far, the only software based automation in existence is the semi-automation provided by software power tools. The challenge of offering full-serve automated experience appears insurmountable.

And indeed, it is impossible to achieve that level of sophistication using the current model of software design. What needs to change is the way software apps relate to human users. At the moment, software apps are not showing any indication that there is even a hint of willingness to establish relationship with human users. Simply put, no software designers ever stop to think about the ways to establish and build any kind of relationship with the users of their apps.

The way humans use software, and all the thinking and decision making needed to operate the apps, is presently considered irrelevant from the software design point of view. Those concerns are marked as being upstream from the concerns of software design. Once human experts do all the necessary thinking and make their decisions, it is only then that a software app can gladly assist them. The app usually assists users in entering the necessary data and then the app may be doing a bit of heavy lifting on behalf of the user. But usually that ‘heavy lifting’ is quite minuscule, and typically software apps require human experts to tell them what to do every tiny step of the way.

Well, that orientation must change. It is not sufficient to build apps that merely wait on humans to do all the legwork. Apps themselves must rise to the occasion and assist humans in performing those essential chores. But apps won’t be able to ever do such kind of work unless the fundamental orientation in their design changes. From patiently waiting on human experts to perform all the critical decision making, apps need to be transformed into the tools of relationship. Apps must be re-oriented to start learning about their users. And to do that, apps must be designed to keep track of all the interactions that happen between human experts and the app itself.

Those ongoing interactions between human experts and pretty much any app are intricate and complex. The app should not offer trivial generalizations based on the accumulated data. It is paramount that the app designers enable the apps to utilize sophisticated machine learning technologies. This machine learning will become invaluable in its ability to detect and elaborate on complex patterns that emerge once the human expert engages in using the app.

It is only by collecting sizeable sample of interactions with a representative sample of human experts that the app will be able to propose thinking and making decisions on behalf of its users. In other words, as the users keep interacting with the app, with the passage of time the salient interaction patterns will become more and more prominent. And since the app is now designed to pay full attention to those salient interaction patterns, the app finally exhibits signs of meaningful relationship with its users.

Can You Illustrate This With An Example?

Let’s stay with the previous workflow example. As mentioned, the present batch of apps proposing to automate workflow chores appear incredibly crude. For example, Microsoft Flow (one of the latest breeds of ‘automated’ workflow solutions). This app proposes to give users the ability to work less in order to do more. Sounds like the designers of this app/platform are barking up the right tree, doesn’t it? Ah, but as soon as you scratch the surface, you realize that yet again, humans are getting shortchanged and are for the umpteenth time getting duped into assisting and serving the technology!

When using Microsoft Flow, humans are expected to do all the thinking, all the decision making, and all the legwork associated with data entry, plus all the endless tapping and clicking. That’s not the definition of ‘work less’; not by any stretch of imagination. So we see again how software apps are completely disrespectful toward the human needs, and are only designed to satisfy the needs of the underlying machinery. This is a big time fail.

Obviously, we have no positive example to use as an illustration in support of our thesis. All we can offer is plethora of negative examples that abound on the market today, illustrating what NOT to do. However, we can certainly offer a hypothetical example of a human-centric app. But in order to do that properly, I’ll need to use yet another analogy:

Suppose I enjoy baking, and am getting really good at it. My friends start noticing my talent for baking, and are appreciative of my unique skills. I have gradually managed to forge a specific style of baking that sets me apart from the regular bakeries.

So my friends start bugging me to open my own bakery. At first I’m reluctant, but let’s say I eventually give in. I open my own bakery, and start rolling with it. But then I realize that it is just too much work for just one person, so I start thinking about hiring some help. Obviously, since my style is very unique, it’s no use placing a wanted add for experienced bakers. I don’t want to hire someone who will start producing run-of-the-mill baked goods, because that would kill my competitive edge. So I start looking for someone who is inexperienced but has some skills and is eager to learn.

If I get lucky, I may find a good assistant (or two), who will help me on the job. So how would I get things organized? I’d show my newly hired assistants the ropes around my bakery. I’d teach them the way I do baking, and will supervise their learning exercises. Eventually, I may get to the point where I’m satisfied with their newly acquired skills, so that I feel comfortable letting them produce the baked goods that we’ll be selling.

The above exercise would amount to me actually automating my baking activities. Since as an individual I cannot scale, I need to hire more hands and then I need to train them. After the training is done, I will end up with a number of workers who can do the job in an automated fashion. I can now enjoy the full service provided by my workforce, so that I don’t have to engage in any heavy lifting, manual labour, or any other self-serve activities.

Same principle applies to the software app that is supposed to offer full automation. Since each business and every person is unique, it is of very little use to obtain an app that consists of some least common denominator capabilities. Instead, the real value of an app would be its ability to be fully trainable. The app should be able to initiate the relationship with its users, and should then continue paying undivided attention to what and how are the users going about their daily job. Since the app has infallible memory and can retain absolutely every little detail that transpired during the regular workaday activities, that focus in training shouldn’t be an issue (as it often is with human workforce).

Once the app accumulates enough evidence of how does the business operate, it can summarize the most salient patterns and then offer those findings to the human users. The users will then review the conclusions that the app arrived at, and will either approve, or make corrections. If approved, the conclusions offered by the app now get implemented as the full automated services that the app offers. If not approved, the conclusions could be modified by the administrators, or the app will be notified that more learning and training is necessary.

Fulfillment Of The Original Promise

The original promise of technology was NOT the delivery of power tools. Power tools are merely a convenience for humans to keep doing the self-serve legwork. Instead, the real value proposition of technology is relieving humans from the chores by offering full-serve experiences. The only feasible way to make that transition from self-serve using power tools to full-serve using sophisticated apps is by forging a relationship between apps and human users. This article describes one possible way of making that important transition happen.