Jim Cross

I have worked on mainframes with UNIVAC and IBM operating systems (three different kinds); UNIX and Linux boxes; OS/2 boxes, DOS, and, of course, Windows going all the way back to Windows 3.1. Most of my daily and business work has been done on Windows in recent years even when deployments were going to UNIX boxes.

Naturally both of my daughters decided they wanted Apples, the one operating system I haven't worked on or know much about. The older one using a hand-me-down Windows box for many years made the jump when she went to college. The younger who spent her own money on Dell laptop a couple of years changed when the disk drive died. No doubt their years of exposure to the IPod biased them toward Apple.

Having seen the Apple now on two occasions (those brief moments when the daughters let me touch them after they first got them), I can see something enormously attractive about them. First, there is buying experience itself. Basically, pick the memory and speed your budget can afford and you're done. No complicated decisions about hardware features or about what software is needed. The boxes come mostly with everything you need or might need in hardware or software. True, they are more expensive then the off-the-shelf Wintel devices in upfront costs - meaning you can get by more cheaply to get something inferior to the Apple. But once you install everything needed to make the Wintel equivalent to the Apple, the costs start to get very competitive.

Then, of course, there is the ease of use. Plug them in, answer a few questions, and they are ready to go.

The only glitch my daughter and I had in my latest Apple adventure was getting her iTunes music, on the dead disk drive and iPod, back onto her machine. I searched the web and found a host of different ways of fixing this problem. I decided to go the easy route and we downloaded iPodRip. Immediately it started running and copying files from the iPod to the Mac. It gave us a certain number of files for free, then requested payment. The cost was a small fraction of the costs of the remaining songs, so we gladly paid and the copy continued without interruption until her entire library was restored.

Over a year ago I switched to a new web hosting company after numerous problems with the old one.

The problems with the old company which will remain nameless were detailed in my first post on this site.

In that post, I indicated that I would tell how the new company was working out.

I'm delighted to tell that the new company has exceeded my expectations and has been better than any of my previous web hosting companies. They are outstanding on price, support, and most importantly up time.

This is a completely unsolicited and uncompensated endorsement for aplus.net.

The Java desktop application has been a neglected, sometimes ignored, part of Java development. Many Java developers, once they learn the language fundamentals, head straight to server-side Java where there has been much excitement in recent years. They may pick up a little knowledge about the Java Foundations Classes (JFC) or Swing somewhere along the way, but seldom see a compelling rationale to develop a desktop application. Developers who are interested in the desktop as a platform on the other hand tend to focus on platform specific solutions (usually Windows, which dominates the desktop) and fall back on platform specific tools.

The fault for this state of affairs is not wholly with the developers. The Java desktop application to an extent is a victim of history. Java from the beginning was associated with the Internet. When Java was first introduced, many, developers included, equated Java with Applets, the mini-apps that run in browsers. Combined with this misconception were the limitations of the early versions of Java. Early Java often failed to perform well, had an inadequate event handling model for sophisticated desktop applications, and lacked many of the widgets available in one form or another on the various platforms. To remedy these problems, Sun created Swing. Almost at the same, however, Sun introduced Enterprise Java. Enterprise Java caught on in a big way. It capitalized on the association in many developers’ minds between Java and the Internet. It provided a solid and increasingly robust, portable, software platform for developing the back ends of web-based applications. Between the frenzy of the Internet and problems of beleaguered IT managers struggling to maintain software across enterprises of desktops, web-based development took off and developers immediately gravitated to it. Adding to this has been the recent development of more robust client-side browser scripting techologies such as Ajax. The result of all of this is that the Java desktop application got caught in the backwater – filling a niche role here or there but never really maturing as a major platform of choice.

Nevertheless, I would argue that there are still roles for Java Desktop applications.

Desktop Java applications are ideal for the following circumstances:

1.The application needs to be able to run disconnected from the server

A web-based application must be connected to the Internet or a local area network for it to operate properly.

If the application needs to run on stand-alone machines or disconnected part of the time, a desktop application would be a good choice.

For example, a sales support application might be intended to run on the laptops of sales people. A sales person might connect to a network and a server, maybe even a web-based application, to download and sync local databases with a master, centralized database. The person might then disconnect and go on the road with the laptop. The application continues to function in stand-alone manner while disconnected.

2.The user interface is too demanding for a web-based application.

While sophisticated interfaces can be produced with web-based applications, HTML and JavaScript are more limited than a desktop application and are more difficult to program and develop if the interface demands are significant.

Different browsers have different levels of support for HTML and JavaScript. In addition, any user can turn JavaScript functionality off completely and effectively break an application.

Obviously a drawing application or a word processing application would typically require a responsiveness and control over the display unattainable in a web-based application unless the features it supported were drastically below the industry standards for such applications.

Even more ordinary business applications, however, may need features that are difficult to implement in a web-based application. Applications that rely on interactive population of list boxes and drop downs are particularly difficult to deploy as web-based applications. For example, if the contents of a list on a web page are dependent on other selections on the page, none of the alternatives available to the developer is good. Although in some cases the JavaScript can be seeded with variables representing the various combinations of selections a user might make, the developer usually faces the choice of returning to the server every time the user changes a selection. This makes for a relatively unresponsive application and possibly unhappy users.

3.The application makes high demands on disk or memory.

Let’s imagine a large retail chain with a thousand stores and each store has twenty departments. Each department is required to create a weekly purchase order that the head of the department starts and works on for several days during the week before submitting it on Friday. Each purchase order may have hundreds of items and each might have multiple special conditions attached to it, such as discounts for ordering in certain quantities or associated items that should be ordered with an item to maximize sales. Ideally the department head would like to be able to manipulate the purchase order in spreadsheet-like fashion to monitor the overall cost of the orders and to stage the delivery times for the items ordered.

While this could be implemented as a web-based application, twenty thousand individual order worksheets would need to be maintained in the central database. In addition, each worksheet would need to be loaded into the browser with fairly sophisticated JavaScript to maintain the totals. Each change to the spreadsheet might need to be committed to the central database. The traffic back and forth between the client and the server might degrade the performance of the application and the database to an unacceptable level.

A better implementation might be to store the worksheets locally, manipulate them in a desktop application in local memory on the client machine, store the interim results locally, and only commit the final results of ordering process once all of the decisions about the weekly order have been made.


4.The application requires access to local machine resources.

If an application needs to access local resources, such as files, directories, or the printer, it would be good candidate for a desktop application. An example might be a file utility, such as a zip utility or an XML editor.

Web-based applications really have no ability to access local resources besides uploading and downloading files and using the browsers to send printed outputs. Applets are limited by browser security and must be signed to access files and the printer.

On the other hand, an installed Java desktop application has virtually full control over the file system and the printer.

5.The application is primarily of a personal or individual nature.

Although it is possible to put personal diaries, exercise logs, or household budgets on the Internet, it makes little sense to do so. Applications that are not multi-user and have no appreciable benefit to gain from collaboration with other users have no compelling reason to be located on a server or a web site.

Placing such applications on a web site requires the user to place personal information in a public place. It also requires a network connection and a web site to be up for the user just to be able to use the application.

In the interests of creating opportunities for career enhancement for mid-level managers in the IT field, I am going to pass on some tips on how to create a major software outage. A major outage, particularly of some core business component, provides many opportunities for career advancement for an enterprising, ambitious manager.

The key, of course, is that the manager avoid having blame assigned to him or her. You must be seen as part of the solution, not part of the problem. In the wake of the outage, management will likely clear away anyone it perceives as a cause of the problem. Since upper management's analysis of most things is superficial, it will sometimes confuse anyone who warned there might be a problem as the cause of the problem. They will likely look to promote anyone who helped solve the problem even if they helped to cause the problem. Your task is to aggravate the problem without seeming to be the cause of it, never to warn there might be a problem, then to step in after the outage occurs and seem to be one who helped to fix it.

A major software outage usually begins with a zealous attitude towards some business objective that requires a major software change. As a manager, your job is to feed the frenzy. If developers tell you the job requires five months, encourage upper management to think it can be done in three. Asking the developers to work extra hours goes without saying. You can also suggest canceling vacations and holding mandatory Saturday afternoon meetings. Turnover is good. It would also be good if you need to bring in contractors to meet the aggressive schedule. Make sure you go low-bid (or even off-shore) on the contractors to guarantee poor quality. A consulting company can become a convenient fall-guy with a clear path of responsibility for many problems.

If you have an old, poorly designed, and poorly understood system that is essential to the software change, you are ahead of the game. Find ways to burden this system with additional requirements and load. Probably this system barely works now so it will be easy to topple it over and almost impossible to fix it.

If you don't have such a system, then insist that a completely new system be created to support the change. Tell management you will use agile, iterative development to cut the normal development time in half. Make sure this new system has the most complicated architecture you can design. Use terms like "failover" and "horizontal scaling" to justify the architecture, but insist that nothing off-the-shelf will work. This will create the need to write thousands of lines of code in a very short period of time with very little chance to test even a fraction of the paths through the code. The first odd exception will immediately crash the system.

Requirements are extremely important. The more people you can have working on the requirements the better. Ideally people should be working on and changing the requirements right up to launch. It is also useful to have multiple groups working on the requirements to guarantee that some of the requirements are contradictory. Complex and volatile requirements mean that developers will miss most of them or understand them incorrectly.

Provided you are not a part of the QA team, you can use testing to your advantage. You must have testing of the software changes. You should be adamant about it. You don't want anyone to accuse you of installing untested changes into production after the outage. You have already paved the way to slip the bad software by the QA team with the complex requirements. Most likely the QA team will not develop test cases for most of the requirements. Since you are working with a tight time frame, they will have very little time to test and probably no time to retest fixes for any defects that get identified. Don't mention "load test". If some one brings it up, agree that it would be a good idea and create a list of new hardware and software licenses that will need to be purchased to carry out a "real" load test. Upper management will swiftly kill the idea or the purchasing will get caught up in the bureaucracy. When the day of the launch comes, you can reassure everyone having any doubts about the software changes that everything has been tested.

In deployment planning, make certain to involve as many teams as possible - the more the merrier when all hell breaks loose. This will help to provide many false leads as to the source of the problems after deployment. Each team will look to the their own area for problems. System administrators will find obscure operating system bugs. Network engineers will find bottlenecks in routers and lines. Database administrators will find poorly optimized queries. It's not a problem that some of these things may be tied to the software changes. Most of them will be red herrings many people can work hours on "fixing".

Deployment should be complicated. Rollback also should be complicated or better yet impossible. Make certain to set up multiple war rooms for the entertainment of upper IT management who has little idea what is changing. These are the people who ultimately will be held accountable and consequently they will be the ones who will jump in to make matters worse when the problems start.

When the day of the launch finally arrives, feel good. This is your time to shine. You must use every opportunity to sow confusion and obfuscation.

Try to find as many problems as possible. Upper management will appreciate your vigilance. If the problems are minor or not even problems, that's good. Undoubtedly management will dispatch teams to deal with them anyway. Hours will pass while the teams investigate the "problems".

Better yet, push for immediate solutions. Undoubtedly the "solutions" will involve the teams that may be most knowledgeable about the problems. Diverting them away from understanding the problems will assure many more hours will pass before a solution is arrived at. As the teams work away for hours at the "solutions", they will tire and be unable to analyze the problems once they may be able to get back to them again.

Whatever idea upper management comes up with, no matter how asinine, immediately agree with it and jump right into assisting with it. Assisting with it, of course, mainly means badgering the tired developers into implementing it. If the idea is good, you will be on the spot when the solution is reached. If it is bad, you can later tell upper management that you were convinced that the idea was good too and that will make them feel good about your judgment.

If upper management has a problem coming up with ideas, here's a few to suggest. Rewriting a major portion of the system in a few hours is always a good idea. You can test in production. Bring up a new server is also good to suggest. That there are probably some corrupted settings on the old server will be a good argument for management. Building out a new server will keep the system administrators and hardware people busy for hours. Since they probably don't have well-documented procedures for doing this, there will be numerous failed efforts to bring the system up on the new server. Be sure to document these failures and bring them up in the post mortem. Suggest that a team who has no understanding of the software causing the problem be sent to "help" the team having the problem is also good. Not only will this demoralize the team with the problem, it will also assure many more hours will pass while the assisting team struggles to understand the software.

Eventually the time will arrive when either the bad software is backed out, shut down, or made to work in some fashion. It may be costing the company millions a day but the company will push ahead with it anyway. This isn't the time for you to ease up. Carefully now record all of the failings of the various teams and fire off an email suggesting “steps for improvement”.

Now sit back and wait for the fun to begin. Within a month of so, you will likely find yourself in a new job at a higher salary.

Note: This little posting was inspired by Roedy Green's essay “How to Write Unmaintainable Code”.

After a three day outage with my prior web host company, I've relocated to a new company - one that actually has somebody who will answer the phone. The odd thing is that I am not paying an arm and a leg for the new hosting. As a matter of fact, the cost is almost the same as the old one.

Obviously there are a lot of companies out there trying to sell web hosting and it's hard the tell the good ones from the bad ones.

I should have suspected things were going downhill when the servers were mysteriously relocated several months with virtually no notification.

With the latest outage, I noticed email was down first. Then I checked the site and it was down. I went through the standard support procedures - filed tickets, waited. I checked the tickets periodically. Of course, since email was down, the support team couldn't email me anything. The tickets would be closed but still nothing was working. I filed more tickets. The site mysteriously came up briefly, although I still don't know how since I couldn't ping the name server. I got a few emails, then it was down again. Three days later and more ticket filing. Finally, I'd had enough I moved everything in about two hours.

If the new guys work out, I'll let you.