Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 4 Issue 9, September 2000
Corporationally Incorrect: Advocating and Selecting Technology
Copyright (C) 2000 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

[ Troubleshooters.Com | Back Issues ]


Editors Desk

By Steve Litt
Step 1 in the Universal Troubleshooting Process is "Get the Attitude". A basic principle of The Attitude is "don't get mad". I can usually keep anger out of the equation. But sometimes, when a particularly bad technology choice leads to excessive work, it's difficult.

Bad technology choices are nothing new. When I repaired stereo gear there was a company that specialized in making junk. Their stuff broke right and left, and repairing it was a mess. Even when repairs were made, these cheap units were never the same. But customers would buy them over and over again.

So why did they buy equipment from this manufacturer? The equipment offered more features for the price. Never mind the equipment would break annually. You got the features cheap. The company aimed their marketing at non-engineering people who couldn't understand durability or operability.

The more things change, the more they remain the same. Today I'm a programmer, and the software I'm often called to work on is quirky, delicate, and breaks on a regular basis. But it offers more "features" for the money. The non-technical managers who make the acquisition decision think they're getting a great deal. Never mind the majority of these features are never used. Never mind it crashes daily, sometimes hourly. Never mind the maintenance costs. The "features" are there, if a guy like me can just tweak the software into functionality with those features.

For technologists like us, the challenge is to work with management in procuring quality technology having the needed features, and a reasonable track record of reliability. Management knows the business, and we know the technology. Put us together, and the right decision will be made. Pit us against each other, and projects will be late, overbudget, and often dead on arrival. We need to learn to be a functioning part of the decision process.

This issue of Troubleshooting Professional explores the process of advocating and selecting the right technology for the job. If done properly, the results are profit and reduction of work, especially the silly firefighting type of work so often thrust upon us. So read this issue, and evaluate how its information can be useful in your situation. And remember this is your magazine. Enjoy!.

Steve Litt can be reached at Steve Litt's email address.

Technologists: Beware of Local Optimization

By Steve Litt
Doesn't it sometimes seem like management doesn't have a clue? That they make unbelievably counterproductive policies and systems? Isn't it obvious that we technologists can do better?

Here's a typical fictional example. Our department is in charge of scanning, indexing and cataloging every lease document for the past 7 years. Other departments also handle these documents. Instead of having a single place to find all these scanned documents, they have two places: a fireproof fileroom, in a different building a mile away at a storage company. That fileroom contains the majority of the documents. Secondarily, there's a local file cabinet, in our building, containing the rest of the lease documents. To find which place to find a document, we check a list. If we take a document from the fireproof fileroom we must, after finishing with it, return it to the local file cabinet, and update the list. If we take a document from the local file cabinet we must check it out on the list. Perhaps the most ridiculous, on the first of every month we must go over the local signout list, find each document that hasn't been signed out or in during the past month, cross it off the list and return it to the fireproof fileroom. MANAGEMENT IS JUST MAKING OUR LIVES DIFFICULT WITH THEIR STUPIDITY!

Be careful of saying this without knowing the whole story. In fact, the preceding system description is the paper equivalent of memory caching, and we all know caching works. In the preceding description, our department is the CPU, the fireproof fileroom is dynamic RAM, the local file cabinet is cache memory, and the list is the caching algorithm.

Memory caching places a substantial extra load on the CPU in order to reduce the load on the system's dynamic RAM, which is extremely slow. The CPU does a lot of extra work synchronizing the fast cache with the slow RAM, and moving information between them. But overall, the reduced load on the slow RAM greatly increases system throughput, because it offloads from the bottleneck.

Getting back to our paper equivalent, for security the records must be kept in a fireproof place, and the nearest one is a mile away. Typically a document is scanned once, indexed once, Q/C'ed once, and possibly revisited for further indexing. It takes several minutes to sign out a doc from the storage company, and an hour or so to transport it. You can't afford that every time you access the paper document. So you keep it locally, and keep a record of what's where.

Now of course, this is just an example to prove a point. In real life a single image would be indexed, Q/C'ed, etc. And probably the image would be shot at the storage company. But the point that this admittedly contrived example proves is that optimizing the performance of your department does not necessarily optimize the performance of the organization. That's why our gripes about selection and use of technology are often greeted with "you're not seeing the big picture".

So be very careful before declaring management "idiots". From the CPU's perspective, caching is idiocy. But if you've ever tried to run a computer with both primary and secondary memory cache disabled, you know it's necessary. Be very careful of local optimization when making technology and system design recommendations.

Steve Litt can be reached at Steve Litt's email address.

Managers: Respect is the Key

By Steve Litt
Technologists aren't the only ones who don't see "the big picture". I wish I had a dime for every time I've seen management shoot themselves in the foot by completely, utterly and insultingly disrespecting their technologists.

Perhaps the best way to respect your technologists is to listen to them. If they tell you a certain tool won't work, don't brush it off because some case study in Infoworld included an example of it working, or because one of your business buddies claims it works. Not listening to your technologists leads to the supernova phenominon.

We've all seen the supernova phenominon. It starts when management insists a technology can do something it can't, or that it has no business doing. They tell their technologists to make it work. Progress is slow, and then the technologists deliver the news that it won't work, and explain why it won't work.

Management's response: fire the technologists and hire some who claim they can get the technology to work.

Of course, under the new guys progress is horribly slow. So management hires more technolgists for the new technology. More cooks spoil the broth more, so progress slows. Management response -- hire even more. The shop becomes a supernova, visible to the naked eye of every headhunter within a hundred miles. The shop temporarily assumes the employment importance of a Fortune 500 company. Then cash flow realities set in, everyone's laid off, and the supernova becomes a dark star.

How many times do you hear managers insult technologists, sometimes to their face. How many times do managers call technologists "techies", and say in plain English that techies have no communications skills (tell that to those who have worked with Linus Torvalds:-). Managers delight in telling technologists they "don't see the big picture", which is especially insulting in those organization where technologists aren't allowed to talk with users and top management.

Respect. Such a simple thing. Almost free. Why is it so hard?

Then there's the disrespect for the technologist's time. Work em 60 hours a week with no overtime pay. Heck, work em 80 and make em wear a beeper 24/7. Make em work 120 hours a week to make a deadline, and then after they miraculously meet the deadline, don't give em any time off.

And by all means, fire all techologists over 40 years old and replace em with H1B Visa slaves.

And after all this, ask why technologists are so mercenary :-).

Back to the Subject at Hand

OK, OK, the subject is advocating and choosing technology. It's simple. When your technologists talk to you, listen. Take their opinions seriously. If their opinion differs from your Gucci-shod golfing buddies, find out how and why. When you find an explanation, let the technologists in on it. Don't just talk teamwork, team up with your techologists to create a great product. Let the technologists take pride in making a great contribution to a great organization.

Do all that, and believe me, the right technology will be chosen, and your projects will be on time and within budget.

Steve Litt can be reached at Steve Litt's email address.

Everyone: Can We Talk?

By Steve Litt
It's so cliche I almost can't say it, but it's a fact. When it comes to selecting the right technology, the key is communication. Communication is simply informing others of your views and how you came to those views, and listening to the views and derivations of others.

It's talking and listening. It's not a program of the month. It needn't be taught by outside consultants. It has nothing to do with "diversity" or "team building" or any other such pablum. It's talking, listening, and mutual respect. We learned it in grade school.

Technologists -- walk a mile in your manager's shoes. He or she must contribute to the productivity of the entire organization, not a little department. Listen to his or her problems and assignments. Figure a way to accomplish them.

Managers, walk a mile in your technolgists' shoes. If they evaluate a technology and find it won't work in your environment, listen now. Don't wait a couple years to have a million dollars work declared a total loss. If your technologists need training, train em. Sure, you can get other technologists who know the technology, but will they know your company and your industry? Will they know proper design techniques? Do you know they're reliable? A technologist in the hand, plus $2500 for training, is certainly worth more than two technologists in the bush.

Steve Litt can be reached at Steve Litt's email address.

Microsoft: What Do You Have Against Modularity?

By Steve Litt
When choosing a technology, be very careful to discard marketing hype. Especially the hype coming out of Redmond.

I'm sometimes asked why I hate Microsoft so much. Do I begrudge crash-prone Windows? No, that's no threat to me personally, and I don't need to use it. Does their abuse of monopoly power offend my populist sensibilites? No, monopolism and ogliopolism rear their ugly heads frequently these days. Am I jealous of Bill Gates' wealth and power? Sure, who isn't. But if jealously caused hatred of a company, I'd hate all corporations.

My beef against Microsoft comes from the fact that they force us to use inferior development tools. And now that Judge Jackson has spoken, my use of the word "force" gains legitimacy. For years, there was no practical alternative to Microsoft. If you don't believe me, ask Judge Jackson.

What makes Microsoft's development tools inferior? The judge did not address this issue, so I'll need to express it as an opinion. It's my opinion that Microsoft's distain for modularity causes its tools to be inferior. Examples of anti-modularity exist all over the Microsoft world. Let's start with the Windows Registry, which allows every app to tamper with every other app. And the registry's close cousin, the .dll files. All of this in the name of "interoperability". More on that later.

I haven't been keeping score in the Microsoft world for a while, so pardon me if I don't know today's exact object lingo, but let's look at OLE/COM/DCOM/ActiveX etc. These cool little inventions allow program code at various websites to intimately interact, at an operating system level, with your computer. Oh yeah, that contributes to modularity. And now, introducing C# and the Microsoft.Net framework, a Windows only alternative to Java and Enterprise Javabeans.

When all is said and done, the average Microsoft system is a thoroughly entangled mess reminiscent of ancient tube radios or no-local-variable Cobol programs. But oh, my, it "interoperates".

The Interoperability Shuffle

The superiority of modular systems was first proven in the Industrial Revolution. The progress of electronics has been a continuous march toward better modularity. In software, continuously improving modularity brought software improvements through the evolution starting with wild west assembly, do-anything Fortran, subroutine-delimited Cobol, data scoped C, and finally object oriented languages like C++ and Java. Then Microsoft reversed the trend. How could they stop evolution? They did it with monopoly power. More on that later.

Microsoft championed Basic -- a 2 decade old non-modular teaching language. They connected it intimately to their operating system. What little modularity there was came from COM/DCOM/ActiveX "objects", which basically had to know about each others every detail. Check the specifications -- they hugely describe interaction with the Windows clipboard. Security -- don't ask. Most apps must have what would be called "root privileges" in a real operating system.

But wait -- Microsoft also champions C++ -- as long as you use one of their "object frameworks". MFC (Microsoft Foundation Classes) is truly amazing. Instead of providing objects for the problem domain (single line edits, multi-line edits, dropdowns, radio buttons, graphic canvases) like Inprise VCL languages, tcl/tk, or Java, they offer their triumvirate, the Document, Frame and View, as well as low level pens and canvases, all of which need to know each others business. And don't forget invalidating rectangles, and the "do not edit" set of C++ macros that substitute for the Windows message loop. Ughh!

Microsoft is quick to tell you the benefit of all this non-modularity is interoperability. Every Microsoft app can talk to every other one. Over the 'net! Yep, when MS technology doesn't crash, it's truly interoperable.

But how deep is Microsoft's committment to interoperability? We all know how they supported the computer language built from the ground up for interoperability -- Java. They kidnapped it and tried to make it Windows-only (Visual J++). How bout their little incompatable addition to industry standard security connection kerberos? How do they rationalize their newfound love of interoperability with their support of the vile UCITA legislation, which facilitates outlawing of reverse engineering, even for interoperability purposes?

The explanation, of course, is that Microsoft doesn't care a hoot about interoperability. So why do they shun modularity, which we all know yields quality? To answer that question, we must examine Microsoft's core competency.

Microsoft's Core Competency

Every company has a core competency. What is Microsoft's? Bill and Steve continuously hawk "innovation" as their core competancy. I'm not so sure. MS-DOS was bought from Seattle Computer. The GUI interface? Wasn't that started by PARC? Maybe they invented NT? Oops, NT started out as IBM's OS/2. Internet Explorer? Nope, much of the technology was from the Mosaic browser, licensed from Spyglass. So if they don't innnovate, what do they do?

The trade mags are fond of telling us Microsoft's core competancy is marketing, which they do excellently. That sounds to me like calling an armed robber a "great salesman". Judge Jackson tells me, and I believe it, that Microsoft isn't required to market in a level playing field. They're able to lock applications to their OS, and their OS to their applications. According to books and articles I've read on Bill Gates and Microsoft, this goes all the way back to the days of DOS. Could Microsoft market in a level playing field? I doubt it. If trends continue, we'll soon be finding out. But anyway, marketing isn't Microsoft's core competancy.

So what's Microsoft's core competency? My view of the marketplace tells me that their core competancy is monopolization. Let me repeat that:

Microsoft's core competency is monopolization

Steve Litt, 9/6/2000

Microsoft's main business strategy is the acquisition, exploitation and defense of monopoly power in various marketplaces. Now at last we can explain Microsoft's loathing for modularity. Modularity enables third parties to interact with Windows. While most normal companies would see this as a customer benefit, Microsoft sees this as a threat to their monopoly. If you can use one piece of non-Microsoft software, and if you can later use that software with somebody else's software, you can migrate to non-Microsoft software. Would people be tempted to migrate away from crash-prone, intermittent and bloated software if given the chance? Better not give them the chance. Destruction of modularity removes the migration path.

Selecting Your Technology

Getting back to technology selection. There are some who believe Microsoft's line that their software provides "interoperability". Don't fall for that line. Microsoft's technology provides crash-prone non-modular systems whose primary design feature is to enhance Microsoft's monopoly power. You can do better than that. Just say no to Microsoft.
Steve Litt liked Microsoft until forced to use Microsoft C in the mid 1980's. Since then, he's spread the word that the king has no clothes. He can be reached at  Steve Litt's email address.

Linux Log: Advocating Linux

Linux Log is now a regular column in Troubleshooting Professional Magazine, authored by Steve Litt. Each month we'll explore a facet of Linux as it relates to that month's theme.
My first advice in advocating Linux is to keep doing what you've been doing. It's working. We got Linux in the back door of the Enterprise, and now IBM, HP and other biggies are now escorting it in the front door.

How have we come this far? It started with excitement. We were excited about our new OS that could do almost anything and do it well. Our excitement was obvious and contageous. Next we documented how to accomplish various tasks easily and cheaply using Linux. Only when a critical mass of credibility was established did we mention that "by the way, Linux gets you out from under Microsoft's thumb".

Perhaps the next step is, as the old saying goes, to "question authority". I mean that literally. Don't argue, just ask the question, "why do you see Microsoft technology as being superior for our use". Listen closely. If Microsoft technology really does fit your situation better, use it. But be sure to evaluate *all* of Microsoft's costs. The per-station cost is often the tip of the iceberg.

Gently guide management to discuss training costs as Microsoft flits from strategy to strategy, plugging ever more holes in the dyke holding the waters of Free Software out of their monopoly. Yesterday OLE, COM, DCOM, MFC, IIS, ASP. Today C# and Microsoft.Net. What next? The Open Source world is one of continuous improvement. The Microsoft world is on of continuous U turns.

Cost of actual licenses is often immaterial. But how about the cost of *tracking* those licenses? Have you been forced to buy license tracking software? Have you been forced to hourly rate lawyers go over license agreements? How much does all this cost? How much will it cost in a future UCITA encumbered world?

How much is spent on maintenance, troubleshooting and firefighting? Mention that the Linux User Community won the Infoworld 1997 Technical Support Product of the Year. Ask about the quality and responsiveness of Microsoft's tech support. Compare the reliability of Linux and Windows software. Do crashes cost your company business? How much does that cost? Is it better to have every last imaginable feature, or a simpler, well featured system that is continuously reliable?

Mention that Linux/UNIX talent is harder to find and more expensive. The classic figure for Linux salary premium is 15%. Ask whether, given the superior reliability of Linux and the quickie education given by the MCSE mills, Linux technologists are over 15% more productive than their Microsoft counterparts (my opinion is a resounding YES). Ask them if they have visited the local LUG to see how many LUG members are just itching to get into a Linux position. Ask whether, after all is said and done, employment costs might decrease from adoption of Open Source technology.

And above all, continue to sneak in with Open Source. Every time they assign you to perform a miracle with absolutely no budget, they're asking for Open Source. Every time they want some little server somewhere, they want Open Source. A little web server? Open Source. Linux, Apache, Samba, DNS, DHCP, Sendmail, VNC. Python, Perl, tcl/tk, Java. FREE! On CHEAP hardware.

Let your buddies at work know what you've accomplished with Linux. Let them know what others have accomplished. Help them visualize a work environment without continuous glitches. Without daily licensing hassles. Without going through purchasing to procure an install CD. Help them feel what it would be like for work to be fun. Linux will take care of the rest.

Steve Litt is a member of Linux Enthusiasts and Professionals of Central Florida (LEAP-CF). He can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process, or articles on tools, equipment or systems with a Troubleshooting slant. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

By submitting content, you give Troubleshooters.Com the non-exclusive, perpetual right to publish it on Troubleshooters.Com or any A3B3 website. Other than that, you retain the copyright and sole right to sell or give it away elsewhere. Troubleshooters.Com will acknowledge you as the author and, if you request, will display your copyright notice and/or a "reprinted by permission of author" notice. Obviously, you must be the copyright holder and must be legally able to grant us this perpetual right. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that by submitting this article I am giving the publisher, Steve Litt, perpetual license to publish this article on Troubleshooters.Com or any other A3B3 website. Other than the preceding sentence, I understand that I retain the copyright and full, complete and exclusive right to sell or give away this article. I acknowledge that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.
After that paragraph, write the title, text of the article, and a two sentence description of the author.

URLs Mentioned in this Issue