Mostly Random Technology Bytes

In his most recent blog post, Joel writes about how the Lego Programming Idea, which often appears in the "mainstream media", will never come true.

If you’ve been asleep for the last 25 to 30 years: The Lego Programming Idea, is that, in future, software will be made by putting together ready-made components, and as a result that doing so will be as simple as a child playing with lego, so that no specially-skilled programmers will be required.

Of course, this is an incredibly seductive idea. Lots of business people love the idea - think of the cost savings. Lots of computer people, particularly those in a resource-crunch or a death march, would love if it were true. And lots of vendors, playing on these dreams, position their product as being a step toward the lego future.

Like Joel, I believe that the whole Lego Programming Idea is pie in the sky. I personally believe, for reasons that I’ll come to in a moment, that the "and as a result" clause in the Lego Programming Idea simply does not follow from its precept.

Some Lessons from History

Does anybody remember a program called “The Last One” that was advertised with massive (for the time) publicity circa 1980 - it was for Commodore PET and/or Apple ][, I think.

The idea was non-programmers could construct programs, by picking options off menus, and as a result it would be The Last One [Program] that business people ever bought. Of course, things turned out rather differently: The Last One is now just a bit of obscure (almost forgotten) history, but programmers are still coding away.

Another example, from just over a decade later, is a Borland tool, called ObjectVision which allowed you to construct quite sophisticated database applications using forms and by drawing flowcharts. And while ObjectVision might have been a great tool, it certainly was never a replacement for programmers (to be fair to Borland, I don’t think that they ever positioned it as one) - and in fact, despite it’s really clean and simple user interface, it was generally programmers who ended up using it.

Indeed, if you go back to the 1950s and the early high level languages like COBOL and FORTRAN, I’m sure that you would find that some people thought that these would replace programmers, because from now on you wouldn’t need programmers messing with binary and machine code, but instead anybody could simply type in their program using a high-level English-like language.

But none of these dreams came true.

Whether it was an English-like language, or menus instead of code, or forms/flowcharts to create databases, the programming never went away. And it’s not like any of these approaches didn’t offer ready-made components: all had libraries of ready-to-use functionality.

So the real question is why didn’t the programming go away?

Because…

To a non-programmer, what it looks like programmers do is to type in commands in a wierd cryptic language. And the assumption is that if you remove the wierd cryptic language, then you will have removed the programming.

Here’s part of the quote that Joel quotes from Business Week: "Indeed, at the software startup they now head, Objective Technologies Inc., programming seems downright juvenile: Instead of mucking around in tangles of C code—writing arcane statements such as printf (”%s/n”, curr str)—they mainly connect boxes on the screens of their NeXT Computer Inc. workstations and fill in blanks."

And if you look at each of the tools that was supposed to replace programmers over the years - then you’ll see that they’re all focused on removing the (supposedly) wierd cryptic language. But, the truth is, that’s exactly the wrong place to start.

A programming language is just the notation used to express set of programming ideas. If you change the notation, you haven’t simplified the underlying ideas, you just expressed them differently. It’s no different from if you were to replace the funny squiggles used by mathematicians with words or pictures indicating "integrate", "differentiate", or "square-root" - it wouldn’t actually make the underlying mathematical ideas any simpler. (And the squiggles are used because they are concise standardized way to express complicated ideas).

So what kinds of underlying ideas being expressed in this programming notation? Or in other words, what do programmers actually do?

That would of course take an essay or three to explain, but a high-level summary might be: They decompose problems into tiny discrete logical units of data or functionality, and they assemble a hierarchy of solutions to bigger and bigger problems by combining these units of data and functionality. You might even consider these units, to be "components" of sort - even though they may not be ready-made or packaged as such.

Why Non-Programming Programming Doesn’t Work

It doesn’t seem to matter what components might be available.

It doesn’t seem to matter if you introduce simplified notation.

Non-programming programming simply doesn’t happen.

Why not?

Because non-programmers generally don’t have the time, inclination or skill to decompose problems into small units, or to assemble solutions out of small units.