Developer Week in Review: Everyone can program?

There's a big gap between easy-to-use tools and competent programming.

I’m devoting this week’s edition of the WIR to a single news item. Sometimes something gets stuck in my craw, and I have to cough it out or choke on it (hopefully none of you are reading this over lunch …).

Yet another attempt to create programming for dummies …

Just today, I came across a news article discussing a recent Apple patent application for a technology to allow “non-programmers” to create iOS applications.

This seems to be the holy grail of software design, to get those pesky overpaid software developers out of the loop and let end-users create their own software. I’ll return to the particulars of the Apple application in a moment, but first I want to discuss the more general myth, because it is a myth, that there’s some magic bullet that could let lay people create applications.

The underlying misunderstanding is that it is something technical that is standing between “Joe Sixpack” and the software of his dreams. The line of reasoning goes that because languages are hard to understand and require specialized knowledge, there’s a heavy learning curve before a new person could be productive. In reality, the particulars of a specific platform are largely irrelevant to whether a skilled software engineer can be productive in it, though there are certainly languages and operating systems that are easier to code for than others. But the real difference between a productive engineer and a slow one lies in how good the engineer is at thinking about software, not C or Java or VB.

Almost without exception, any software engineer I talk to thinks it’s insane when an employer would rather hire someone with two years total experience, all of it in a specific language, rather than one with 10 years experience in a variety of languages, all other factors being equal. When I think about a problem, I don’t think in Java or Objective-C, I think in algorithms and data structures. Then, once I understand it, I implement it in whatever language is appropriate.

I believe that a lot of the attitude one sees toward software engineering — that it’s an “easy” profession that “anyone” could do if it weren’t for the “obfuscated” technology — comes from the fact that it’s a relatively well-paid profession that doesn’t require a post-graduate degree. I match or out-earn most people slaving away with doctorates in the sciences, yet I only have a lowly bachelors, and not even a BS. “Clearly,” we must be making things artificially hard so we can preserve our fat incomes.

In a sense, they are right, in that it doesn’t take huge amounts of book learning to be a great programmer. What it takes is an innate sense of how to break apart problems and see the issues and pitfalls that might reach out to bite you. It also takes a certain logical bent of mind that allows you to get to the root of the invariable problems that are going to occur.

Really good software engineers are like great musicians. They have practiced their craft, because nothing comes for free, but they also have a spark of something great inside them to begin with that makes them special. And the analogy is especially apt because while there are always tools being created to make it easier for “anyone” to create music, it still takes a special talent to make great music.

Which brings us back to Apple’s patent. Like most DWIM (do what I mean) technologies for programming, it handles a very specific and fairly trivial set of applications, mainly designed for things like promoting a restaurant. No one is going to be writing “Angry Birds” using it. Calling it a tool to let anyone program is like saying that Dreamweaver lets anyone create a complex ecommerce site integrated into a back-end inventory management system.

The world is always going to need skilled software engineers, at least until we create artificial intelligences capable of developing their own software based on vague end-user requirements. So, we’re good to go for at least the next 10 years.

Fluent Conference: JavaScript & Beyond — Explore the changing worlds of JavaScript & HTML5 at the O’Reilly Fluent Conference (May 29 – 31 in San Francisco, Calif.).

Save 20% on registration with the code RADAR20

Got news?

Please send tips and leads here.


tags: , , , , , ,

Get the O’Reilly Programming Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • Israel Alvarez

    I’m not so sure you’ve quite nailed Apple’s approach here. This sounds/looks a lot like a spiritual successor to Hypercard. Many, many developers of my generation started with Hypercard, and it’s a tool I heartily wish was available to my children. A modern implementation of Hypercard that could generate runtimes for the iOS would be *huge*, and could be a “killer app” for iPad adoption in the education market.

    The more I think about it, the more sense it makes. Didn’t the patents blocking the original Hypercard expire a couple years ago?

  • When starry-eyed people started having the idea that maybe reading and writing could be taught to the masses, there was a lot of opposition. And there were hucksters promising the world to youngsters that if they copied squiggly lines here and there, they were “writing” and were doing what the learned priests were doing. We are living in this kind of transitional stage in history now. But I have no doubt that if reading and writing, which are extremely, extremely difficult cognitive tasks, have been distilled so that most people in developed nations can do it (although they are not going to be Shakespeare or O’Reilly authors), computational thinking and programming can also. Eventually we’ll figure out how.

  • Every time I’ve seen one of these applications, the lifecycle of the project has been like this:

    – A non-technical person installs it, and after futzing with it for a few days, makes an app. Magic!
    – They take it to their manager who, astounded by their magic, figure out a way to make the thing that they made something the customer might want.
    – Some sales guy pitches and sells the app. Everyone is delighted. Grumbles from developers are ignored.
    – The customer asks for a bit more in the next release. They struggle a bit, but comply.
    – The customer asks for more. It’s a bit harder this time.
    – And again, the customer asks for more, but this time, they can’t get the app maker to do what they want. They’ve hit a wall.
    – They have code for the app, so they hand it over to a dev. The code is completely and utterly unusable, since good code generally cannot be generated.
    – The dev realizes he/she must rewrite the code completely, and gives the hours for that.
    – Management either balks and drops the project, or accepts, and piles a ton of money on fixing the POS app.

  • Anonymous

    I see this type of thing impacting the web developer more than the systems developer. With content management systems and robust blog software like WordPress the developer can slowly be removed from the equation. In many ways the developer is like a middle man in these worlds. But that role doesn’t really cease to exist. Instead they move to the CMS or WordPress team. Building plugins or modules that are “easy” to configure. So while the traditional web developers role is reduced a web designer that can code will become more and more in demand.

    As far as how this impacts tools like complex iPhone applications or web applications in general, I think Katie hit the nail on the head here. The problem is with educating managers about the scope of these “easy” programming languages and systems. The CMS example I give above only relates to simple websites, not complex web applications. However, authorship of simple web sites and simple apps should be something that can be accomplished in a WYSIWIG style interface. However, as Katie pointed out, this leads to major problems with product growth.