I know they say “never say never” but I can truly say that never again will I recommend trying to produce a piece of software for internal corporate use that is a desktop client. I’m done.
For the past two years I’ve been working on a project to create a new desktop client application to replace an old desktop client application. After two years of effort I have come to the conclusion that there had to have been a better way.
Building the software was a long and complex process, a bit longer and more complex than we anticipated, but overall it was manageable. We created an application that the team is proud of and we can’t wait to get the thing deployed so we can call this project done. Therin lies the rub. Deployment. The key difference between web applications and desktop clients – how do I get the software to my users?
We now have to get a piece of software pushed out to several hundred end users. The task sounds simple until you start to take into account the gotchas that accompany this simple task:
- Who needs the software?
- What is their machine name?
- Do they have all the pre-requisites?
- Will the pre-requisites break something they already have?
- How will you deploy it?
- Did you test all the possible software/hardware configurations?
Determining the first two items on the list is a lot harder than it sounds. Does everyone who needs to know actually know that this new software is coming? Do you have a good sense of the users of the current legacy system that your application is replacing? How old is the list of hostnames you’re working from? Is there actually any documentation for the old system? If so, has anyone validated it in the past 5 years?
Software pre-requisites are another nasty piece of business. Making sure that the libraries you have are licensed for deployment is important. If your users departments need to purchase licenses to use your software, did you tell them in advance? Did you now they wouldn’t already have that “standard” application installed? How impressed were they to take on an additonal $20K in software license fees in late September?
Beyond licensing the nastiness continues with deployment of the dependencies. Can they be pushed out the same way as your application? Do they require restarts? Do they need to be deployed before you can deploy your own application?
On top of that you may have certain versions of libraries that you’ve tested with your application and that you’ve used throughout the build and test process. If you’re working with a server-side web application you probably have full control of the environment you’ll deploy to in production. Not so with a client. You may not know you have an incompatibility until you start pushing your application out to actual users. Now what? You’re supposed to go live in less than a week and your product will cripple some critical application on the users’ machines.
Now that you have all that sorted out and you know how you’re going to deploy your application, the question is whether or not you’ve tested all of the permutations of hardware and software that could impact (or be impacted by) your application. Are your users on laptops or desktops? Are they running Windows XP or Windows 7? Are any of those Windows 7 machines running 64-bit versions of the OS? You did make sure your pre-requisites were all Windows 7 compatible, right? Do you need to package up a version of the .NET Framework or the JVM with your application? Do the users have any applications installed which rely on older (or newer) versions of the libraries you’re pushing out?
Oh, and you did realize that nearly half your user base is running in some sort of virtualized desktop environmnt, right? Do you know how to deploy to them? Will your software work properly in a virtualized environment?
Oh, and you did realize that about 20% of your users don’t ever come into the office right? You can deploy over someone’s low-bandwidth VPN connection, right?
These are all examples of questions that require solid answers before you can deploy a client application in an enterprise environment. The smaller the group, the easier it is. But if you have more than 100 end users or if any of them are in critical customer-facing roles you had better be damn sure you can answer all of these questions months before you plan to deploy. Otherwise you’ll be deploying months after you planned.
From now on I’ll be looking for web-based solutions to as many new application builds as possible. Going through the circus of trying to put software on my users’ machines is not an experience I care to repeat. In this increasingly heterogeneous world of multiple platforms, multiple operating systems and bring-your-own-device programs it is more important than ever to be able to consolidate the development effort to the server. It is a far simpler thing to deal with the quirks of a few browser versions than to worry about how many employees won’t be able to do their work the next time you release a software update.