This is a guest post from Shannon Wagner.

There, I said it.

Client-facing server software is obsolete.

That means we don’t need it anymore, shouldn’t be writing it anymore, and should as quickly as possible replace any of it which is currently “in the wild” with more proper and appropriate stuff. Like… “client-facing client software”. 🙂

What could possibly have brought me to this fool conclusion? After all, I write software for a living, and most of it is… client-facing server software. But it comes with a lot of unnecessary limitations.

In my mind, there are two fundamentally different environments in which we find non-shrinkwrap software deployed. (By “non-shrinkwrap software” I mean the kind of software that is not labored over for years by large design and development teams, and then sent out in cardboard boxes to sit on the shelves of your local office supply / consumer electronics retailer. And also not the downloadable versions of those SAME EXACT PRODUCTS.)

So, non-shrinkwrap software. Digital bits of compiled code.

The two environments where we find the stuff are:

• Corporate – i.e, inside the office network
• Home – i.e., the gadgety stuff that your users are downloading and constantly trying to bring inside your pristine office network!

I have a lot of experience with both environments, albeit with a definite Windows slant. And I have some strong opinions about which vendors have done the best job of producing and providing good software, good updates, and timely innovation to the software that I think users find most useful.

First, a belief (assumption) of mine: the best software changes rapidly and carefully, simply because our personal and work lives also change rapidly (though not often very carefully).

Next, some context… (You may, after reading it, think I am a narrow-minded techno-fool. Hopefully you won’t be right if you end up thinking that.)

Every office I have worked in eventually gets to the point where they believe they need a heavy-handed “change” or “configuration” management process. This wasn’t necessary when the tech department was first born, and there was one guy who wrote all the Visual Basic applications, fiddled with all the desktops and servers, and basically made the network into his hobby. But if that guy was responsible and competent, then eventually that department grew, and now you have a team of less experienced folks who are trying to put their own stamps on the network, but it’s not a one-man shop anymore so this just causes confusion.

Eventually the business folk get to thinking that if they impose enough process, the tech cowboys who should really just be more careful about what they are doing will start to deploy systems with fewer problems and productivity will increase to where it was when every department in the company was much smaller. While this may be true, the resulting corporate sludge of process can cause some serious problems.

They devise various reasons for persuading the company to wall-off their applications behind thick administrative walls, guarded on servers in data centers.

And, the upshot: Everybody thinks web applications and heavy-handed server software are great. But I am standing in the corner saying, “Huh?”

Everybody is using a web app, and the experience is… not so great. Sure, updates are easy (as long as your users keep using the same version of the browser you originally developed for) but the user is now living inside the guarded walls with you. But actually, deploying updates is not as easy as you might think, because everybody has fallen more in love with deployment process and less in love with solving business problems. Nobody trusts the technologists, so the technologists learn to be more expedient instead of more careful. Users suffer.

And when you mix that guarded environment into the bright new world of mobile devices, the experience is even worse, since users now need to rely on their sluggish cellular data connection just to use your application. Google Gears once promised to solve the “access your data offline” problem, but the project dried up and died before it ever worked well (trust me – I gave offline Gmail a comprehensive user trial myself). HTML5 now promises to solve the same problem. We’ll have to see.

But as much as we would like to think otherwise, the most important wall in the application enviro-prison sits right there at the edge of the user’s mobile or desktop computer. You have to get solid, good-functioning software over the user’s wall reliably and efficiently. Sure, this software will need to access data on your servers, but it should only be doing that – getting data – not trying to implement a fully featured local system application using a framework (the web browser) that was designed from the ground up to keep itself distant from the underlying system. Does it really make sense to essentially drag all the functionality of the user’s desktop across the wire to your server, and then spit it back in the form of ever-more-complex scripting technology grafted onto an HTML rendering system? Maybe it does, but I don’t think so.

And if you really want to ensure the security of your infrastructure and server systems, you probably want to have your administrative hands deep inside the computing stuff on the user side of that user wall. The more of your software that you can reliably install to the user’s desktop, without causing deployment pain for the user, the better you can manage the user experience.

Okay, so you still might be thinking I am crazy. And I would agree that there are scenarios (generally when an application’s deployment is in it’s infancy) where a traditional or fancy web application is the greatest choice. But I am speaking here more as a user than as a developer, and I can tell you that among my favorite systems which have not yet been deployed as native applications – well, let’s just say I look forward to the day when that changes and they are all deployed as less clumsy native apps. That goes doubly for Gmail, which I very much wish Google would support on the Windows desktop as effectively as they already do on the Android operating system.

Many of my favorites already have been built as full desktop applications, and with great results. For example, a design goal of Evernote right from the start was to provide a solid native client for every supported platform. And of course Dropbox would have zero competitive advantage if they did not rely so heavily on the native client.

You may think these are one-offs. But I think there is a reason that a vendor like Intuit has never gotten very far with a personal finance web application, but instead continues development on their heavy Windows application. True, Intuit recently acquired Mint, but they don’t seem to have any plans to merge the client-facing Quicken product with the Mint web application – it seems like they may have been more interested in the backend technology that Mint had developed. And, whatever you may think of Quicken, I think it is hard to argue that Mint’s front-end is truly competitive with Quicken’s far more comprehensively functional front-end.

One of the most important obstacles (in the past) to deploying your software as a desktop client has been the difficulty in ensuring that your users are always using the latest version of the software. But many of the best products have already solved this problem – aside from just providing an easy way to update the software, they come very close to forcing updates on the user. Early versions of Google’s Chrome would update silently and frequently. Current versions seem to require the user to restart the browser. Dropbox has been able to update automatically for a while now. And of course your antivirus software has to update automatically and frequently, or else it becomes ineffective. And this type of support for ensuring client updates has been built into the language and development tools for Microsoft’s .NET and for Java for more than a few years, although it doesn’t seem to be used very often.

The original reasons for favoring client-facing server software just don’t exist anymore. So why are we still doing it?

This is a guest post from Shannon Wagner. Shannon is a self-proclaimed technology zen hippie geek. He blogs at geek-in-law and can also be found on Twitter and Facebook.