Troubleshooting Professional Magazine
|
Corporationally Incorrect: Advocating and Selecting Technology |
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!.
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.
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 :-).
Do all that, and believe me, the right technology will be chosen, and your projects will be on time and within budget.
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.
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".
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.
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:
|
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.
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.
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):