Pinderkent

Today I shared the experience a friend had with one of the companies he works with. It involved a failed transition from what was mainly a console-based suite of applications powered by Sun systems and Oracle, to an AJAX and Web-based system running on Windows, .NET and SQL Server. It seems that that entry was submitted to Reddit, and so I've been reading some of the comments that were left there.

Some of the comments were quite insightful. But there were two that I found to be just plain funny! Here is the first comment, and here is the second comment.

In those comments I am accused of being "biased against windows and ajax" and guilty of "discrimination against Windows & dot-Net". Well, I would like to address those allegations!

First of all, I've been doing this long enough to not get to attached to certain products or technologies. In the end, it's all about solutions that work to solve the client's problems in an efficient and financially-sound way. I'm glad that I get to mostly work with Solaris, HP-UX, AiX, FreeBSD, Linux and other UNIX-like systems. But I've worked with Windows many times before. As long as the job gets done properly, I really don't care what software is being used.

In this case, my feelings regarding Windows, .NET and SQL Server have absolutely no impact on the problems that that company experienced with their transition. Beyond hearing about it from my friend, I had no involvement with the development of the old system, nor any involvement with the development of the new system.

Furthermore, the fact remains that the old, UNIX- and Oracle-based system worked just fine. The new .NET-based system did not work in a suitable manner. Pointing out that certain software did not perform in an adequate fashion in a certain situation does not indicate bias. All it indicates is that the software in question was not capable of performing what needed to be done.

Likewise, the AJAX-based UI proved inefficient compared to the previous curses-based interface. That's just how things worked out. Again, my feelings, thoughts or biases would have had absolutely no impact on the situation, as I was not involved.

I do thank the two comment authors for their thoughts and opinions. However, I also urge them to be more careful in the future when accusing others of bias. Just because a particular technology fails to work in a particular situation, and this failure becomes a topic of discussion, there is not necessarily bias against that technology. Sometimes technology fails. We must admit this, and learn from such failures.

Last night at the pub, a friend and colleague of mine was telling me of a recent experience he had at a company he was doing some IT work for. I think the lesson learned is a very important one, and thus I wish to share it. But first I'll describe the situation he encountered.

In the mid-1990s, the company in question built their IT operations around systems from Sun. They wrote much of their in-house code using C++, and used Oracle for their database needs. On the front-end, they used PCs running a mix of Windows NT 3.51, FreeBSD 2.x, and even OS/2, depending on the department. While that is not a unique setup by any means, what is somewhat unique is that they essentially continued to use those same systems up until 2006.

One of the main reasons why they didn't switch is because their software systems worked just fine, even if the UIs were somewhat archaic. Their software was mature and well-understood by the company's employees. They even got extremely lucky in the first place, as the developers who initially designed and implemented their software systems did so in a way that allowed for the systems to easily scale as the need arose over time.

The hardware proved to be the main instigator of change. After a decade, many of the front-end PCs they were using started to exhibit a variety of physical problems. Some had been replaced earlier, but eventually it was decided to replace them all with newer systems. However, to the best of my friend's knowledge, the back-end Sun systems were working just fine.

However, at the same time they decided to also replace the back-end systems. A variety of consultants were apparently called in to appraise the situation. For whatever reason, it was eventually decided that the new back-end systems would be built around Windows Server 2003 and SQL Server 2005. The new back-end software was to be built upon .NET, while Web-based client-side apps would be developed and used. My friend wasn't sure exactly when this effort started, but he believed it was in early 2006.

By the end of 2006, the consultants and developers deemed the new system ready to go. Over the course of the December 2006 holidays, the new systems were rolled out. It turned out to be a pretty major disaster. The first problem they ran into was a complete lack of performance. As they moved into the first weeks of 2007, their back-end systems just wouldn't scale. As an emergency fix, they ended up throwing more hardware at the problem, which did ease the burden on the existing servers somewhat. But it was in no means a permanent solution.

The front-end software systems proved to be an even bigger disaster. Many of the AJAX-based applications used Internet Explorer-specific functionality. But the IT managers of some of the front-end networks would not allow IE to be used, for security reasons. They only allowed for Firefox to be used. So the Web-based front-end software needed significant modifications right away, as well.

What was perhaps the worst failure involved the in-house users and their productivity. Large portions of the old system were built around a curses-based UI. Although it apparently wasn't very pretty, it did allow for a great deal of user productivity. One of the main complaints about the new Web-based software was that the keyboard support was quite poor, requiring the user to select input fields using the mouse, and at times even having to scroll the page to input or manipulate certain data. With the earlier system, the navigation could rapidly be performed using just the keyboard. Some of the more experienced users were apparently so efficient with the older system that their productivity was reduced to 25% of what it was before the switch.

My friend and his colleagues were called in to try to remedy the situation as best they could. The company was not willing to invest in a completely new system, but instead insisted that the old system be brought to a usable, if not optimal, state. The work is still on-going, as we speak, five months later.

There are many lessons to be learned here. The one my friend emphasized the most was that it's often a good idea to leave existing systems as they are. What they had worked, for the most part. The problems they experienced with their front-end hardware could have been easily dealt with by buying new PC systems. But the decision to replace their working server hardware, and to rewrite their existing (and well-functioning) back-end software, were obviously terrible ones. The use of AJAX and Web-based software for their front-end systems was also a poor idea.

I think some of the other major lessons are as follows:

• Use mature, well-tested, effective software (eg. Solaris, Oracle, FreeBSD).
• Avoid immature fad "technologies" like AJAX.
• Traditional applications offer more flexibility than Web-based applications.
• Always give much consideration to back-end scalability.
• Sometimes a text-based interface is far more efficient than a GUI.
• Get user feedback on software early and often.
• Maintain a reasonable level of heterogeneity, when it comes to software, hardware and vendors.

Hopefully we can all learn from these lessons made obvious by this situation. Although given my years of experience, somehow I think that won't be the case.

Those who follow GNOME have probably read about the GNOME Online Desktop. After reading about this concept, I find myself very confused at what it is they're actually trying to accomplish.

Take what is, at the time of writing, the second paragraph under the "Philosophy" section: Imagine an OS that keeps all its information online, so you can use a live CD as easily as a full installation. When you start up a newly-installed computer, or visit a friend's house, your whole environment will be waiting for you, with no setup to redo. For the techies, think Stateless Linux Desktop; your files and settings are somewhere else.

Why do I need to imagine that sort of an operating system? I've had that for years now. It's really quite simple: I have a system at my house running Solaris, connected to a broadband Internet connection. Using SSH, I can connect to it from virtually any other network-enabled computer. And over that secure connection I can run X-based applications quite well. All I need to bring with me is a USB key with an X server installed. Since most UNIX or UNIX-like systems, like Solaris, Linux and Mac OS X often already have an X server present, it's really only a matter of using Xming on Windows.

Best of all, I get to use real desktop applications. I don't have to bother with lousy JavaScript-based web apps, and I have full access to all of my data. Also very important, I have much more control over how my data is stored, copied and backed up. Yes, it's a little bit more effort on my part, but I think it's well worth it to know how my private files are being stored and used.

So I find it difficult to understand what exactly the GNOME developers here are trying to accomplish. Using my setup, it's already possible to use the existing GNOME applications from other computers quite comfortably. We get the benefits of web apps, without what is often the poor quality they exhibit, and without having to worry about who else has access to our information.

Now is major turning point for the GNOME project. KDE 4.0 is coming soon. GNOME isn't prepared. We may very well see a mass exodus of users from GNOME to KDE, just because KDE 4.0 will be so far ahead of GNOME. It's doubtful that this GNOME Online Desktop idea will bring any benefit.

I'm sure that most people who follow developments within the open source community have read about Mark Shuttleworth's high-end, free-software-only laptop idea. While his focus appears to be more ideologically-driven, I think such a laptop would be useful for those of us with more pragmatic concerns.

Understandably, his writing about this topic focuses mainly on the use of Ubuntu-derived distributions on such a laptop. But I think it would also be very valuable for users of systems like FreeBSD, NetBSD, OpenBSD, Solaris and even Haiku.

The obvious benefit would be the ability for drivers to be written that have excellent support for the hardware being used. This has been one of the main benefits of buying a system from Apple, where you know the software you're getting has full support for the hardware it is bundled with.

The benefit may not be as great for Solaris. After all, we have been able to buy Sun workstations for decades now, and of course Solaris integrates very well with the hardware being used. While there are UltraSPARC-based notebooks running Solaris available, Shuttleworth's proposed laptop could bring Solaris to a wider audience.

FreeBSD, NetBSD and OpenBSD may have the most to gain from such a system. FreeBSD and NetBSD would both provide very usable, general-purpose environments. OpenBSD may even be ideal for such a laptop, where its high degree of security would prove useful when connecting wirelessly to questionable networks at universities, airports, malls, and other public areas. Not having to worry about hardware incompatibilities would likewise make such systems available to a far wider audience.

The realization of Shuttleworth's proposal for a high-end, free-software-only laptop would be excellent for the open source community. It would allow operating systems like FreeBSD and NetBSD to become a far more viable alternative to Windows, and even to Linux to some extent. This is the sort of initiative that we all should support.

At far too many companies I have witnessed the effects of homogenized enterprise-grade networks. While many claim that it's easier to support such networks, I often find that difficult to believe. The benefit brought on by the widespread similarity is often overshadowed by the severe negative consequences when things go wrong.

In the past, I have seen failed automatic updates take down entire offices for a day or more, leaving several hundred people idle. That is a complete disaster for most businesses! Such a scenario can happen when the administrators test on one system that is fairly similar to what the other users are using, but some slight difference in the configuration causes the problem to go undetected. Soon enough, the update is rolled out to everyone else, and the major problems begin.

Another major problem with such a setup is that of the security. A security flaw can simultaneously affect hundreds of systems. Depending on which software is affected, and the spread of its deployment, things can get pretty hectic. ZDNet has an article about a flaw in Java that may be extremely widespread. It will be very interesting to see how this situation develops, considering how Java is used at both the enterprise extreme of computing, as well as on mobile devices.

Now, we must remember that enterprise-grade computing consists of effectively making a number of tradeoffs. It's a matter of balancing usability, cost, security, maintainability and a whole host of other factors. But we must never allow ourselves to fall into the fallacy of thinking that uniformity will solve many of those problems.

So in my experience, I have noticed that companies with a fairly wide range of computing platforms tend to be the best off. They have just enough variety to segregate their network in a way that limits problems affecting one piece of software or hardware. But likewise, they don't have so much variety that it becomes difficult to manage.

One company in particular had what I'd consider a very sensible setup. Their backend database, mail, web, etc., servers ran Solaris and HP-UX. They used PCs running a variety of Linux distributions throughout the rest of their office, as a frontend to the Sun and HP hardware. The similarity in concept between HP-UX, Solaris and Linux, but the difference in implementation, proved very helpful. The administrators of the Linux systems were quite easily able to comprehend what the HP-UX and Solaris admins were dealing with, and vice versa. But a security problem affecting Solaris usually wouldn't hinder the other systems.

They kept the variability reasonable. They were able to effectively track security advisories for the different software they were using. Their use of high-quality, high-reliability systems further made their lives easier, and also more productive. In short, it was a setup that did a very good job of maximizing the benefits of similarity with the benefits of diversity. And we tend to only find this with UNIX-style systems, which tend to share similar concepts, but differ enough in implementation.