It’s seems almost quaint to think that once upon a time, you really had to be a rocket scientist to develop software. OK, correct that, computer scientist. Your IDE was a cryptic command line text editor, and you freelanced debugging manually. That’s OK, that was during the cowboy days of appdev, when ideas like objects, components, or models were considered the stuff of idle dreams. Besides, what self-respecting programmer (we didn’t call them developers back then) would ever condescend to using somebody else’s code? Real coders only need command lines, and they don’t need formalized architecture to tell them how to program.
Roughly 25 years ago, what was then Borland introduced the integrated development environment, and several years after that, Microsoft blew the lid out of that market with the first programming language that was really designed for, to borrow Apple’s terminology, “the rest of us: Visual Basic. For the first time, here was a language that was fairly easy to learn; offering lots of flexibility; and taaping the innovations of visual development, it made software development more intuitive. As God’s gift to liberal arts majors, they now could get paid for doing something other than waiting tables, driving cabs, or teaching art history or philosophy.
Of course, lowering barriers to entry allows the unwashed masses in, and yes, there is sound argument to say that allowing anybody to program would lower the quality of coding. Yet, democratizing development became essential because in the early 90s, the coming boom in client/server, followed by web developed, unleashed an enormous appetite for applications for which there weren’t enough computer scientists in the world to deliver. Even with bandwidth bringing millions of Indian, Chinese, and Ukrainian developers online, supply is still mismatched with demand. While you might think about outsourcing large projects or maintenance, it is simply impractical to task teams located over a dozen time zones away (not to mention language or cultural barriers) to churn out the kinds of quick, tactical applications that some agile team in a corner could crank out in days.
Not surprisingly, the democratization of development unleashed by Visual Basic and almost every development tool after made it possible for the IT profession to meet demand; it didn’t create it. But not surprisingly, with all that sloppy coding out there, emergence of robust frameworks like Java EE and .NET attempted to clean up the mess with frameworks that required disciplined practices like strongly typed coding. But as the laws of physics predict counter reaction to every action, dynamic scripting languages like PHP and Ruby emerged to provide the ease and lightweight that the top down frameworks forgot.
Anyway, it is difficult to make it through a vendor briefing call these days without hearing bromides on how they are making their tools accessible to “business developers” – as if there is such a class of people in the business who do software development. What they are really saying is that they have tools for business stakeholders who have day jobs to, by the way, craft quick little productivity or business insight apps with their drag and drop tools on the side. It’s the same thing that we have heard from players like Zoho which seem more like cloud platforms for developing trivial apps of little meaning.
Therefore our ear perked up with Microsoft’s release of LightSwitch, which provides a simpler path to developing real data-centric .NET applications. We’ll spare you the details because Andrew Brust has explained them much better than we could, and is hoping that LightSwitch might become part of “a long overdue turnaround” from Microsoft’s last decade of “courting complexity.”
We share his hopes, but our optimism is a bit more measured. Microsoft doesn’t exactly have a great track record backing innovation these days. A couple years ago, it had a similar kind of great idea with Oslo, an innovative attempt to make modeling of data-driven applications (do we see a pattern here?) more developer-centric through a coding-oriented approach. Less than a year after unveiling Oslo, Microsoft backtracked and made it a development pattern for SQL Server. Let’s hope that on this go round, Microsoft has the patience and perseverance to keep the LightSwitch on.