Where are the New Client-Side Development Environments?
History repeats itself, first as tragedy, second as farce.
Clients and Servers
My first professional job was as a system administrator in HP in the '90s. The Internet was popular enough that even Microsoft had noticed, and Outlook viruses were about to shut down our site for a couple of days. (How fortunate that we had just migrated from HP OpenMail to Exchange.)
Two technical facts surprised me when I started. First, the administrative assistants in my group had to log into an HP 9000-based terminal application to reserve conference rooms and catering. Second, the logistics team collaborated by mailing around a multi-megabyte Excel file with ferocious amounts of VBA performing calculations and updating projections and prices.
Our IT group had two opportunities to provide applications to users. One was
through our internal application installation console, by which users could
request licences for specific pieces of software and we could push patches.
(After ghosting a new Windows-based PC, the first thing I did was update the
installation console, and then update new versions of applications.) Think of a
aptitude which tracked licenses and received pushed
updates, rather than polling. The second option was writing a small web
application, or occasionally a Java applet.
The first serious program I ever wrote for an employer was a Java application (not an applet) installed on a recycled Debian box for the laser printer support group to log the printer class of all advanced customer support questions. Another developer wrote a Perl program to report the results every day.
The Perl world has a term for all code not available on the CPAN: the DarkPAN. Though there are 15768 distributions and 59062 modules from 6803 uploaders available publicly (as of 12:24 pm on 06 August 2008), there's immeasurable private code in thousands of businesses around the world. It's possible to check the CPAN for uses of a Perl core API, or to test that a core change doesn't break existing and well-behaved code, but it's impossible to know if a change affects any or every part of the DarkPAN.
It's easy to postulate the existence of the DarkNET as well. This isn't gigamiles of dark fiber that Google purchased for own nefarious purposes. It's all of the Intranet applications someone wrote and deployed to a forgotten "server" under a desk somewhere. If HP still relied on those ancient '70s mainframe apps in 2000 when I left, what are the chances that some of my code from the '90s is still running?
While almost every Rails-based startup with magazine-cover perfect pointy-haired founders and rounded corners (the app, not the founders) eventually gets press and praise and attention, especially in the Silly Con Valley echo chamber, my rough guess is that there are orders of magnitude more little apps created on the DarkNET. It may be one order of magnitude, but two wouldn't surprise me and three is possible.
People want to solve their problems, and they're happy to work around what they perceive to be the most difficult problem. Often, that's deployment. As much as we might like to believe that Google Apps are inappropriate for business secrets, that PHP is insecure and unmaintainable, that CGI programs are unbearably slow and unscalable, or that mailing around multi-megabyte spreadsheets is sign of evil number four out of seven, sometimes they're the paths of least friction.
Apps for Non Programmers
The multi-megabyte Excel planning file made little sense to me at the time, but now I see several advantages:
- Everyone who needed the information already had Excel with VBA
- Anyone could update the data in place
- No one needed a server, a PC always on, or a VPN
The only real problem was distribution, and my group had already solved this by using an Internet-available shared network drive. As far as they cared, sharing this application was the same as sharing a document -- because that's all it was.
If they'd asked central IT, I'm sure they would have been happy to open a support ticket and prioritize development and eventually produce some sort of server-based application, then eventually giving contractors and a couple of vendors limited VPN access to the application, and before you know it, months would have gone by.
I couldn't have written it much faster myself as a web application, and I still would have had to find a place to host it.
Mailing around new versions of the document wasn't ideal, but every form of deployment had its drawbacks. That's still true today.
One persistent debate lately revived by Ajax is whether shiny enough web applications will displace thick client applications, or whether Web 2.0 is a return to the bad old days of sharecropping in the gated community of grouchy mainframes.
Better than Worse, For Once
I wonder, though. I've worked on projects where the entire front end was a web site. That worked, as long as we controlled the servers. I've worked on other projects where the front end was a small client application written in Python which connected to a web service backend. That worked (at least, after we replaced SOAP with something that actually worked). Yet I'm a programmer, and I worked with programmers and system administrators. We had the power of source control and deployment and staging servers and production servers.
The huge Excel application I saw didn't come from programmers. Central IT had no small fit when they realized what my group was doing. Of course, that tantrum deflated somewhat when they also realized that they could offer nothing better.
A non-programmer in my group (a smart businessman, but very much not a technie) took a two-day VBA class and spent a couple of weekends honing his skills to be able to modify that spreadsheet. He'll probably never be a programmer, and that's fine. He had motivation and intelligence and he made things happen.
If the new paradigms for application development are either beg/borrow/rent time on a server and write your mainframe-style client-server application for anyone with a browser to use or learn how to write client applications and figure out how to distribute them and synchronize data, we're missing a piece.
Sure, users can still grab Excel and write a little bit of VBA and mail around their spreadsheets (or, worse, I hear Access still exists) -- but that's hardly portable, is it? It seems like a big step backwards from allowing anyone with a web browser to create and manipulate information.
Where You Come In
(Attention potential startup founders: I'll take a mere 2.5%.)