An Application Development/Execution Platform for the Rest of Us

Mel Conway, March 13, 2020

This is about engaging almost everybody in the process of building

real-world applications. It develops the rationale for, and will end with, a
product concept.
0:1/2

Contents:
1:Thesis
2:Historical Perspective
3:The Model of Progress
4:Humane Tool Design
5:On Platforms
6:Where the Work Stands
0:2/2

1:Thesis

If non-programmers are going to build real-world solutions

a simpler programming language isn’t enough.

We must put non-programmers in a

collaborative situation
where we meet them where they are
and the environment empowers them by leveraging developers’ skills.
1:1/2

So this is about creating a new

1
platform-based two-sided software market
in which almost everybody can participate with the skills they already have.
1:2/2

2:Historical Perspective

The software industry is in the middle of a monumental historic

transformation. What we might not realize is that this transformation has
been going on for 4000 years:

Democratization of culture-critical information technologies.

2:1/16

The first three legacy universal information technologies:

calendar, writing, and arithmetic
started off as the property of an elite priest class and, over approximately
4000 years, are now being taught in elementary schools around the world.
2:2/16

I believe that building digital tools is so central to our technological society

that it’s going to join these three legacy technologies as the fourth universal
information technology. This paper is about how that might happen.
2:3/16

2
This chart shows how the level of education required to use a technology
has dropped over 4000 years. The vertical axis shows the level of
education, from birth (not a joke, as you will see) to advanced education.
2:4/16

For the three legacy technologies the long solid lines show the
democratization from high priest to elementary-school child. Now along
comes a fourth, building digital tools, beginning around 1950, entering at
the far right.
2:5/16

Note the dotted line at the right. It shows that over the last 70 years, the
number of software developers has grown from about 200 in 1950 to over

3
23 million in 2018. That’s an average growth rate of about 18% per year
over 70 years.

Something big happened around 1950.

2:6/16

Meanwhile the educational requirement to build digital technology has

dropped from college to early secondary or middle school for a lot of kids.
2:7/16

What happened to the legacy technologies:

[Link] conceptual models became simpler and more accessible to more
people, and
[Link] media became more lightweight, portable, and easily reproducible.
2:8/16

4
Here’s how it used to be. Mayan time was circular. The Mayan calendar
was three concurrent cycles: 260 days (for ceremonial purposes), 365 days
(for agriculture), and approximately 7900 years (essentially a linearization
for counting indefinitely into the past or future).
2:9/16

You might recall that a few years ago there was a doomsday myth going
around because all three cycles simultaneously came to their origin points
in December 2012.
2:10/16

5
What happened around 1950 was a
step-function reduction
in the skill level required to program computers, hence a
step-function increase
in the number of people to whom programming became accessible.
2:11/16

A 1945 paper introduced the idea of representing a computer program as

data in the same memory used for problem data, rather than as external
plugboard wiring.

Another important change was in the weight of the embodiment of a

program. (The Mayan calendar vs your phone.)
2:12/16

ENIAC programmers in 1946 had to know digital logic as well as

mathematics. ENIAC program wiring could take days to set up and weeks

6
to complete test, and you had better be sure you had run all your data
before you tore it all down for the next application.
2:13/16

And while you’re wiring it up and tearing it down, the computer is sitting
there unavailable.
Also, communication, training, and other delays were greatly reduced due
to the lightweight medium, which is easily copied and transmitted.
2:14/16

The first commercial computers appeared in the early 1950s. Then, people
like me in the universities were building assemblers and compilers. IBM
introduced FORTRAN in 1957, which brought a lot of scientists and
engineers into programming.
2:15/16

Meanwhile, Moore’s law was continually driving down the costs of

hardware. Desktop computers started in earnest in the early 1980s, greatly
enlarging the market for applications.
2:16/16

7
3:The Model of Progress

This graph introduces the concept of *Universal Human Skills*. It says that
the more your technology relies only on Universal Human Skills and
doesn’t require additional education, the more people will be able to use it.
3:1/16

The line suggests progress, from a past at the left where the model is not
intuitive and only a few people get it, to the present in the middle, where
you can be trained to understand it, to the top right where everybody gets
it, maybe at some point in elementary school.
3:2/16

8
But before we go further, we have to answer what we mean specifically by
“Universal Human Skills”.

What skills do all humans have in common that we can exploit in order to
design a fully accessible model of how to build software?
3:3/16

According to Michael Merzenich of UC San Francisco, what all of our

brains have in common is
plasticity.

The first few years of the life of each human child are massively invested in
this project:

Build My Brain.
[Link]
_plasticity
3:4/16

Nature builds into every infant a process of building its brain, first passively
by responding to stimuli, and then actively, through relentlessly persistent
practice, well beyond what we as adults normally can tolerate.
3:5/16

For most normal children this project focuses on hand-eye-brain

coordination.

9
Therefore:
Universal Human Skills
means
hand-eye-brain coordination.
3:6/16

10
In this graphic the picture at the lower left shows ENIAC programming
around 1946. The ENIAC was no slouch; it was built to compute artillery
tables in World War 2 and was also used to study the feasibility of
thermonuclear fusion.
3:7/16

Programming ENIAC required people trained in both mathematics and

digital logic to wire up the functional units.

They were almost all women, by the way, because the men were in the
military fighting World War 2.

Women were leaders in the early days of software.

3:8/16

The invention in 1945 of the stored-program computer changed everything.

It eliminated the need to understand digital logic and opened up the
creation of computer solutions directly to the scientists who had the
problems, greatly simplifying the solution process.

11
3:9/16

Also, programs were now data, and computers could create programs.
High-level languages and their translators were born, simplifying the task
and bringing in still more people.
3:10/16

The resulting explosion in the number of programmer candidates created

the software industry, and now we have over 20 million developers
worldwide.
3:11/16

That question mark at the upper right, what does it tell us?

That the construction model must be accessible to almost everybody. It

must be a high match to Universal Human Skills, that is, hand-eye-brain
coordination.
3:12/16

12
This is the big idea. We must reframe application building from a symbolic
activity to a manual activity.
What does that even mean? How do we do it?
And then, what do we even mean by a “programming language”, or by
“programming” itself?
3:13/16

13
The potter’s wheel at the top is a great model of hand-eye coordination in
building something. There is immediate feedback involving the hands, the
eyes, and the working material.
3:14/16

What is software “working material”?

The term suggests that the thing we’re building evolves as a valid thing
from the very beginning of its life. The bowl starts out as a lump of clay and
has a continuous existence as the potter forms it.
3:15/16

What if we need to rethink the application’s model as being continually valid

and observable from the very beginning of its construction?

14
I’ve addressed these questions and have come up with a list of a dozen
tool design principles, which I call the
Humane Dozen.
3:16/16

15
4:Humane Tool Design

These twelve principles can’t just be tacked onto existing development

tools. They form a holistic, “Humane”, approach to building and testing.
4:1/14

This three-page paper gives you one or two sentences for each principle.
[Link]
4:2/14

Here is one consequence that falls out of fully following the Humane Dozen
that you might recognize in browser debuggers.
4:3/14

16
The tool and the application it’s building (with live data) are in front of you
as peers. Your next event can be in either one of them. If you change the
application in the tool, its behavior immediately reflects the change. Just
like turning a bowl on a potter’s wheel.
4:4/14

If you try to do something illegal it refuses and tells you why, and even
doing stupid things won’t break anything. What has to happen for that to
work?
4:5/14

17
Let’s take just one principle, self-revealing, and describe how it might apply
to one application of that principle: API design.

The self-revealing principle is quoted in the green box.

4:6/14

This is old stuff; it’s how the Mac and Windows replaced the command line
with dialogs and icons. They called it the “WIMP” interface, for Windows,
Icons, Menus, and Pointer.
4:7/14

You saw with Mac and Windows how

lowering the barrier to entry greatly increased the population of users.

That’s where we have to go.

4:8/14

18
Every self-revealing API is an
active object
that answers this one question:

Show me what you can do.

So, even with this simple example, we’ve changed the tool concept.

We’ve replaced external API documentation by tools that interact with

active APIs.
4:9/14

19
At the lower right is a dialog for building an SQL Select. It looks familiar. But
it’s not that obvious because of another principle: Alive With Your Data.
That principle means that you’re watching the result of your query as you
build it, step by step.
4:10/14

The tool asks the API: Show me what you can do.

The API responds with a list of services that the tool lists, including help
provided by each service if requested. Once the builder chooses a service

the service takes control

and presents whatever WIMP dialogs it needs.

4:11/14

20
It won’t be simple, so why try?

Because doing so can greatly enlarge the number of candidates for

building applications. Empowering new classes of builders means

creating new markets and building new businesses.

4:12/14

This is not about today’s “low-code” and “no-code” languages, whose

vendors see them as productivity enhancements within the enterprise.

It’s about a holistic market-based construction concept that is addressed to

the total population.
4:13/14

It’s research, but it’s not pie-in-the-sky. I’ve worked through many of the
issues and have a working Humane proof of concept.

So what does a software market based on this design concept look like?
4:14/14

21
5:On Platforms

Let’s consider Microsoft® Excel as an acknowledged and widely used

approach to simple application building, but let’s consider it not as a piece
of technology but as an

interface between two populations of people.

5:1/20

Excel is more than a programming language. A big part of its power is its
library of functions and presentations.

22
Excel is a platform

that enables non-programmers to reuse a portfolio of professionally-built

functions and presentations in a humane development environment.
5:2/20

In the graphic everybody in the world of Excel is inside the outer rectangle,
and inside that there is a colored rectangle containing the builders of Excel
features.

Excel itself, the red and blue boundary, is a

collaboration interface

between these two populations.

5:3/20

So Key Idea 1 is the notion of two populations with different skills and a
collaboration interface between them.
5:4/20

23
We’re interested in these three key attributes of the collaboration interface.

Asynchronous.
The builders of Excel features and the users of Excel features work at
different times, but they collaborate through the platform, which combines
their work into something new.
5:5/20

Asymmetric.
The builders and users of Excel have very different skill sets. Some
platforms with more matched populations, like telephones, don’t have this
property, but asymmetry of skills is a key idea to leveraging the skills of the
builders in order to empower the users.
5:6/20

Construction.
Some platforms, railroads, for example, don’t build new things as the result
of their use. Some, like the potter’s wheel and software development tools,
do.
5:7/20

24
What’s a platform? It turns out that it depends on whom you ask.

To the person on the street, a platform is something you put stuff on.
5:8/20

25
I’ve seen two different usages of the word by software engineers, shown
here.

In the example on the right, the number of connections in the star network
grows linearly with the number of nodes, whereas in the point-to-point
network it grows quadratically.
5:9/20

26
To an economist, though, a platform is a powerful economic phenomenon
that connects two populations in what’s called a two-sided market. You’ll
recognize the examples on the left; they’re all associated with rapid market
growth.
5:10/20

The two populations are sometimes called producers and consumers, but
the suggested asymmetry is not an essential part of the definition.
5:11/20

Network effects
are key to market growth. The more people on one side of the platform, the
more valuable the platform is to the people on the other side. In the early
days of the telephone you wanted a phone service that connects you to the
people you want to talk to.
5:12/20

27
The curve, called the “logistics curve” describes the early exponential
growth (due to this positive feedback) and later market saturation. Once a
platform with strong network effects gets started it’s really hard to dislodge
it.
5:13/20

When you examine successful platforms you see a lot of

standardization of interfaces

which further enhances network effects.

5:14/20

If you want to study platforms as economic phenomena I recommend the

book “Matchmakers” by Evans and Schmalensee.

“First-mover advantage” is good-news/bad-news. The first mover has a lot

to learn, and will make mistakes. It's often the second mover that captures
the market.
5:15/20

28
Here is my definition.
5:16/20

29
My favorite interface standards picture: the port of Shanghai.

From the ships and cranes in the distance to the containers and trucks in
the foreground, to the barcodes on every container connecting it to a
worldwide information system, count all the interface standards!
5:17/20

When intermodal containers were introduced in 1956, most cargoes were

loaded and unloaded by hand by longshoremen. (Remember the movie
“On the Waterfront”?) This introduction reduced the cost of loading a ship
by a factor of 36, from over $5 a ton to 16 cents a ton.
5:18/20

30
Containerization also greatly reduced the time to load and unload ships,
which reduced unproductive time in port.
Since that time the volume of international shipping has exploded.
5:19/20

Comparing containers to longshoremen is analogous to comparing stored

programs to bundles of wiring, in their effect on setup costs.

Notice software being framed here in a systems model that has parallels to
other businesses, such as shipping.
5:20/20

31
6:Where the Work Stands

Now the pieces are in place to describe the goal: a

Humane
Asynchronous
Asymmetric
Construction Platform
for Stateful Business Applications.
6:1/17

32
This is what the cloud-based development/execution platform looks like. On
the left are developers building reusable components and on the right is
just about anybody assembling these components into applications and
other reusable components.
6:2/17

The Consumer Interface on the right presents the application model to

Everybody in Humane form.

What does it really look like?

33
I can answer by dividing the application model into two parts:
[Link] use-case session, and
[Link] coupling between these sessions.
6:3/17

A working Humane proof-of-concept session prototype exists, using a static

declarative text-free pictorial model. A composite screenshot is below. I’ve
been showing videos of building this restaurant menu ordering session for
several years at developer conferences.
6:4/17

All my design documentation is public on my website. Much of it is in the

form of working papers, through which I can guide interested questioners.
(DMs are open.)
6:5/17

There are several models of stateful session coupling in use, e.g.,

based on a database, and
based on an immutable event log.

Their designs have not been expressed in Humane form and have not
been integrated with the session model.

I believe that both are possible.

6:6/17

34
In the box at the top of the figure is a statement of the declarative
connection model.

This model is a half century old. It’s the basis of the user interfaces of
mainframe applications, but I’ve not seen it suggested as an alternative to
the model-view-controller pattern.
6:7/17

The wiring in the heavy rounded rectangle on the left is an expression of

the model for this order-entry session. It is not a programming or flow
language but a

static connection language.

6:8/17

35
I have demonstrated building this session in the wiring tool one component
and one wire at a time, and at every stage something observable is going
on.

This is the digital equivalent of the potter’s wheel:

It encourages discovery and correction at every stage.

6:9/17

This discovery/correction cycle underlies the Humane Dozen concept, and

it is fundamental to the goal of the proposed “for the rest of us” product:

[Link] evolution of the naive user from toy to tool.

[Link] for others at any point along this path of evolution.
6:10/17

The yellow components in the left-hand rectangle are the portals to the
reusable objects on the Producer side of the Platform.

The communication protocol is self-revealing APIs.

6:11/17

I anticipate that reusable objects will exist at multiple levels, including

horizontal objects such as computations of all sorts, transient collections

36
and data stores, objects that capture domain knowledge, and application
fragments built from wiring.
6:12/17

It will require experimentation, but I imagine that domain knowledge from

vertical software can migrate into these reusable components and
employed by systems integrators.
6:13/17

The prototype is built in Smalltalk. Smalltalk is not required for a product,

but it was required for the kind of experimentation I did. I believe that a
product design must be a full object design; I don’t see any other way to
standardize self-revealing APIs.
6:14/17

How does one do a full object design across the Web safely using existing
protocols?

Is this a settled question or must it be part of the research?

6:15/17

You can see one instance of this wiring process in

[Link]
through

37
[Link]

The rectangle in the middle of the figure shows just one way to build the UI.
You could also use wireframes or forms, for example.
6:16/17

Now we have a roadmap that gives us confidence that this cloud-based

Humane development/execution platform can be created.
6:17/17

38