Now Johnny CAN program, says Behlendorf

Open source champion Brian Behlendorf says enterprise mashups will open up development to 'average Joes' - and he says that's a good thing.
Written by Phil Wainewright, Contributor on
I had a chance to chat to Apache co-founder Brian Behlendorf late last week.
Brian Behlendorf, Apache co-founder and CollabNet CTO
Now CTO of CollabNet, Behlendorf these days is in the business of helping companies co-ordinate their software development. But I was surprised (and pleased) to find the extent to which that increasingly means welcoming large numbers of non-programmers into the development process — something that can only grow with the spread of Web 2.0-style mashups into the enterprise.

"The concept of who's a programmer is going to become very fuzzy," Behlendorf told me. "Mashups are really Excel macros 2.0 — and with the rise of web services, the more vehicles that are out there that expose data through programmable APIs, with Office 12.0 and Firefox with AJAX, the more people you'll see create applications. The line between hardcore developers and the average Joe will start to get very fuzzy."

I thought the analogy of mashups to Excel macros"Mashups are really Excel macros 2.0" was especially insightful, and as I've sat down to write this, it's put me in mind of an article from a couple of years ago by spreadsheet inventor Dan Bricklin, about Why Johnny can't program (or 'wontprogram' as the URL has it). He ended the article with a hierarchy of programming systems ordered according to how acceptable they are to 'the average Joe' (or Johnny, in this case). Spreadsheets come next after dialog boxes and forms, because it's much easier for the average user to start getting results with them than visual development environments, markup languages and (worst of all) raw programming languages such as Java, C and FORTRAN.

What Behlendorf is saying is that when you start putting mashup tools into the familiar environment of Microsoft's Office suite or into extensions to a popular browser like FireFox, then the effect is the same as putting macro languages into the spreadsheet — it opens them out to 'average Joe' users, because (as Bricklin explains) that's an environment where they can see results as they go along, and thus more easily learn by trial and error.

This is not just an analogy, of course. You can already see it literally in action today if you download and start using StrikeIron OnDemand Web Services for Microsoft Excel, a plug-in that lets you drag-and-drop Web services output fields directly into Excel. Or you can play with the "wkcHTTP" function that Dan Bricklin built into the latest Alpha release of wikiCalc — the collaborative spreadsheet program he's currently developing. The new function provides access to external web services during recalculation. In the Web 2.0 world, it's appropriate of course for Johnny not only to program, but to do it collaboratively, too.

Collaboration is a key element of lifting everyone's game in the CollabNet world. So I asked Behlendorf about the dangers of unleashing newbies into the development arena. Wouldn't it end up creating a lot of Frankenstein mashups, just like the horror artwork from the early days of desktop publishing?

"I don’t know what we could do to keep users from writing bad software," he laughed. "I'm fully in favour of giving people more rope to hang themselves with."

Professional developers have themselves been all too guilty of creating APIs that change frequently, thus breaking dependent applications, he said. The best way of placing a check on bad programming is by opening up communication channels and feedback forums.

"If there is room for feedback where they can be flamed to hell for breaking things, they'll be less likely to do that."

CollabNet's experience is that large numbers of users do get involved in the development process. A typical CollabNet site will start off with a couple of hundred seats for all its core software people, but once it's been live for a year and a half or more, that number will expand to include even larger numbers of non-core or "light" users. 

"There's this spectrum of development all the way between naive users and core developers," said Behlendorf. He believes the non-programmers have a crucial stake in the applications that are being developed, and should have access to a framework that lets them participate.

Editorial standards