Mythos

We're doing a classic Death March on the project at work. For those who don't know, a death march is when a project is at the point where there is no hope of meeting a deadline unless everyone on the development team puts in alot of overtime.

It should probably be noted that more often than not that the root cause of a death march is the person who is not spending their evening and weekends punching a keyboard.

So anyways, while I was waiting for a build or three to compile, I put together a l'il list. It's actually about software development. Shocking that sort of thing could actually appear on my blog! Anyways....

Myth: It's faster to build "it" using a browser interface instead of a client-based interface.

In fact it will probably take longer. You have to take browser, operating system, servers and other environmental factors into account that you don't (or not as much) for a client application. Plus, what is a simple thing in a client application is a nightmare of complexity via a browser.

Myth: It is cheaper to build "it" using a browser interface instead of a client-based interface.

Client software applications can be expensive. Developers, testing, support etc can cost quite a bit. A web application needs the exact same resources, blood sweat and tears as a client application.

A client application sits on the box it is installed on. A web application sits on the web server that you either have to own or rent connected to the network that you either have to own or rent. And those boxes and networks need people and software to run effectively. And of course you need support programmers to keep the software running. So while it may be cheaper from the narrow scope of building the software (although not by much when it is in fact cheaper) you have to account for cost of ownership of the application for the life of the application.

Myth: A web browser can do all the same things as a client application does.

As people demand more and more "desktop" type look-and-feel for web applications, the more layers of complexity you need to put into a web-application. Two very big dangers arise from this:

1. The more you do, the fewer browsers and operating systems are compatible
   
2. The more you do, the more fragile (easy to break, hard to fix) the application becomes. In the client world, this can be mitigated by a well-designed application. For web applications, this is unavoidable.
   
3. A web page is inherently stateless. That means as a baseline, one web page knows nothing about any other web page (except for where it is). While they are many ways to make web pages look like they are state full, it is done by inelegant and complex means (as compared to full client software).
   

Myth: There are more web developers than client developers out there (or at least they are easier to find)

Kind of a half-truth. While there seems to be quite a few more people who know HTML than C++, there can be a wide gulf between a web designer (working with how a web page looks) and a web application developer (working with a web interface with a complex piece of software sitting behind it). In fact a web application developer needs to be a web designer *and* a client application developer.

Myth: Web code is throw-away code

Any code could be throw away code. For simple things it is easy to throw up a web page that performs a simple task (or it least it can be) to be replaced later.

Anything of great complexity takes a great deal thought and effort to produce (Web or client). Telling your web application developers that their code is throw-away because they program for a specific interface technology is a good way to find out how the job market is. Just because a web page is more ephemeral than a solid .EXE, doesn't mean it should be regarded as disposable.

Myth: Everyone can use an application with a web interface. It's as easy as using a browser.

Ever work as technical support on anything? Some people, through no fault of their own (in most cases) really don't know how to use a computer. While browsing to Google is pretty straightforward, what happens behind the scenes boggles the minds of a lot of really technical people.

Creating a easy-to-use interface is both an art and a science that requires a lot of thought, work, revision and code. It does not just happen because you are building for a browser.

There is also a really, really big danger if non-power users (powerless users?) start treating a web application like a client application. The first example is the "double-click" danger. In many web applications, a double click (the first click selects what they want to do, the second tells the computer to do it, at least in a client app) is a disaster waiting to happen. Double clicking "Submit" with credit card info can (and far too often does) lead to double billing. It doubles how much work the web application has to do when that happens. Take the problems you have with users in a client app and multiply by two.

A well educated user is a safe user (regardless of the type of application). An educated user is not a cheap user as well, and far too often user education is an afterthought. If thought of at all that is. (Yes, true for any application).

Myth: A web application is easier to support than a client application

The "cost of ownership" for a web application was mentioned above. Now add your support system that actually needs to help your users. In addition to the software, your support people need to know about the multiple browsers, multiple operating systems, the problems with combinations of the previous and more than likely need to tap into which ISP is having problems at the very minute. All while dealing with irate customers who can't understand why their credit card was billed twice.

If there is a single advantage in supporting a web application, it's that you can deploy a patch much faster and easier that a client application. But unless you have a really solid infrastructure and application design, it means *nobody* will get to use the web app while you patch it. And every time you do, your support people will be bombarded with calls.