Not Everyone Can Program and Not Every Programmer is Great
Posted by Bob Warfield on December 2, 2007
Reg Braithwaite wrote a column recently called, “The Optimistic View”. He’s tired of organizations pushing lowest common denominator tools because they’re afraid lowest common denominator programmers will hurt themselves (well, hurt their code really) with stronger tools. He suggests:
But maybe, just maybe, most programmers rise to the occasion when challenged. Maybe instead of catering to the bottom 10th percentile we can be open-minded about what the 50th to 75th percentile are capable of achieving, much less the top quarter.
It’s an interesting thought, but I confess I haven’t seen an awful lot of evidence it’s true. I have certainly been surprised by programmers before. But the surprise has been in just how fast a really talented “junior” programmer can take their place in the ranks of the really good architects. I have not seen a lot of evidence of the much less talented stepping up to deal with some of the real rocket science of our trade.
He gets a little more detailed in his thinking here:
Spreadsheets taught us that anyone can program. Maybe we should open our minds to the possibility that although not everyone does program in this manner today, they are capable of it if we stop telling them that they aren’t.
And when we say “Anybody can program,” we say that without reservation or disclaimer. We don’t mean anybody can program provided they are banned from using certain langauges, or anybody can program provided we hide the details of relational databases behind ORMs, or anybody can program provided they are not required to learn any idioms beyond those authorized by the local High Priest. We mean anybody can program, period, without being lashed to a heavy yoke and driven through the fields under the whip.
This is the point where we part company. Spreadsheets did teach us that anyone can program, BUT, they did so by doing some of things he suggests we quit doing with less talented programmers. They hide lots of details that one would have to know to accomplish the same thing using normal programming. It is quite instructive to think about what spreadsheets do for us. Largely, they allow us to quit thinking abstractly and organizationally, two big skills that programmers must possess. In other words, they eliminate the need to think like a programmer.
Consider the business of organization, or specifically of ordering. Spreadsheets let their users examine the trees and the forest just emerges magically, and without much planning. Tell the spreadsheet the relationship between a few cells using a simple formula. You never have to worry about what order you do that in. The spreadsheet does a topological sort and figures out the “natural order of recalculation.” Because of this, there are no loops to think about. Control structures are pretty straightforward and are seldom nested. A simple “IF” is about all there is, and easily 90% of spreadsheets don’t use them.
There’s a lot more clever hiding that happens as well. Consider the whole user interface issue. Spreadsheets give you that for free using their grid metaphor. It’s amazing what can be accomplished there, but it isn’t really programming. Perhaps most importantly, it doesn’t try to be. Most of that look is fixed at design time and is not dynamically programmable.
Data is another biggie. For those who are stuck on static typing, spreadsheets have none, nor would it make them any “safer” to offer it. But there are also no data structures. Each cell stands more or less alone, with the exception of ranges (or blocks as they came to be called) referenced in formulas. There is almost no ability to go further save Excel’s confusing array formulas which I’ll wager are used in much less than 1% of cases, and most of those were forced as a way use the LINEST builtin.
The interesting questions are how much of this can be done for conventional programming and how would one go about it? The first issue is seriously missing. It’s not clear we understand and agree just where the problems are. I’m certainly not going to claim to lay it out here, but I will say this. Layering more and more complexity on is not the answer. That’s not how spreadsheets got where they are in terms of enabling more programming. Adding a bunch of syntax around typing may have value for some things (chiefly making the tools better in my mind), but it isn’t how you help people. If you want to help lowest common denominator people, figure out how to eliminate or radically reduce complexity. Eliminate abstraction. Eliminate the need for the peculiar kinds of thinking great programmers must do.
Spreadsheets, BTW, are a graphical dataflow paradigm. They really are visual programming, just not using boxes and arcs. They are also constraint oriented programming. I could go on, but spreadsheets don’t prove everyone is a programmer. They do something quite different that is even more useful: they make it possible to write programs even if you can’t think like a programmer.