Advocacy
Dojo (HowTo)
Reference
Markets
Museum
News
Other
Myths
Press
General
Hack
Hardware
Interface
Software
Standards
People
Forensics
Web
CodeNames
Easter Eggs
History
Innovation
Sightings
Opinion
Martial Arts
ITIL
Thought
|
The value of something is directly related to how much it does what you need, and doesn't try to do that which you don't. Think about that. Think about what that means to System and Application design. This statement is anti-FUD, anti-Windows and often anti-Unix.
FUD (Fear, Uncertainty, Doubt) was first applied to IBM's marketing and sales which used to scare companies into going with them (the biggest). Later it was applied to Microsoft's sales and marketing and tricks to make competitors "incompatible" -- so they scared people into buying safe (Microsoft). Microsoft took it a step further -- into features themselves. They didn't try to compete on quality of package -- but they were big. So they competed on quantity of features. It doesn't have to do much well, if it does a whole lot of things poorly. If you are big, you can afford to make these behemoths of the software world -- and the little guys can't compete with all that. Then the features became FUD, and a way of scaring customers based on what they might need, into buying your product because it had more features -- most of those features they actually don't need. They buy your product because they MAY need those features some day. Those people pay the price every day, since the extra features take up space, make the system more complex -- which costs in support and user errors, as well as the opportunity for more bugs -- but they buy out of fear of being incompatible or because they MIGHT some day need some feature that it has (and the competitors does not). To me this is like buying a gas guzzling truck, when you need an economy car, because some day you might want to haul something.
Free Features
Windows, and most products Microsoft puts out, are very heavy in features that you don't need. The first rule of software developement is, "There are NO free features". Every feature you add increases complexity, docuementation costs, potential bugs, support costs, testing time, training time and so on. To be a good engineer (or to engineer a good product) you need to know what to leave out. All of those "don't needs" hurt a product. If only 1% of your users are using the feature, then it may be a detriment to the other 99%. Many of the problems with setting up and supporting Windows and Microsoft Applications can be traced directly to those same unneeded features. Think how much better the system would be if it did only what you wanted. Which group are you designing for. It is clear that Apple (and Claris) design for the 95 - 99%, and just as clear that Microsoft (and some others) design for the 5% (or 1%).
Unix Rants (Over Configuration)
The biggest place this lesson needs to be learned is by Unix programmers -- but Windows programmers pull up a close second. They create System layers like X-Windows -- which was going to be a way to do Windowing and User Interface (cross platform and cross networks). Of course it does almost nothing because it wastes so much effort trying to do everything and be all things to all people. So X was near worthless on it's own -- you had to add layers on top to actually get things done. XLib was the basics, but it needs X intrinsics on top. Then you need Motif on top of that to define how things will actually behave. Then many Windowing systems are built on that (like CDE, GDE, Gnome, and so on). It was a bottoms-up approach to design that added more complexity than value, and none of the geeks ever asked, "What do users want?" -- instead they focused on adding features and configurability, even if there was no need.
In fact that is my problem with Unix itself. It isn't written for users. It is the most user hostile system I know of. Yes, RedHat and many new "one-button" installs help hide that complexity, but it is all lurking under the surface. It is written for programmers, and by programmers. They want to be able to do anything, or change anything, at any time. So everything in unix has some text file controlling every aspect of configuration. If something goes wrong, you reconfigure it. Every geek is out there trying to tweak something to make it go faster -- when the real solution is to just design it right in the first place. I'd wisely take a 1% performance hit if it meant I never needed to know the implementation details of something and the support costs would go down accordingly (since no one could set it wrong) -- many UNIX people won't.
Configuration and choices are often a cowards way out. An engineer doesn't want to do all the studying and analysis to figure out which way is best or "right" (or better for most things) -- so instead they just make it an option -- then they don't have to think about it. Push the engineers problem on to the user or support people, and dodge their responsibility. Whimps! It is much easier than create the numbers to justify a position and make a stance (and stand behind it).
If that was bad enough, some engineers dodging though configurability becomes so ingrained that they start to attack the others that make a stand (and choose something) because it has one or two things that it is worse at (instead of looking at how much better it is for everyone if they can assume it just works one way).
This is why a few of them just hate the Mac -- Apple makes implementation decisions and doesn't allow everything to be configurable. This is why it costs so much less (in lifetime costs) for laypeople to set up and manage Mac networks. But it also means that some don't have the levels of control that they think they need. It can be tough learning that your child (or OS) can survive and make good decisions without you.
All systems have good and bad points. And there is some good in being able to change something -- but many refuse to admit the bad and costs associated with it. Imagine you could reconfigure a car so that the pedals could be reversed. Some might like that -- but the costs are too high. That inconsistancy means everyone must know that the pedals MIGHT be reversed on the car they get into. They should also know how to switch them back. Of course there may be no known logical reason for reversing the pedals -- but in computers that extra feature sells, and only an idiot wouldn't design it without that possibility (or so the anti-logic goes). It doesn't matter that drivers will making mistakes since their reflexes can be trained only one way. It doesn't matter if those mistakes cost lives (or time and money). Many want their BAD configurability anyway. But since it has so many costs, and so few returns, less choice is often better.
Standards
That brings me flying into my next rant -- standards. Think of this as Dave's Standards Equasion:
TrueStandards = 1 / number_of_competing_standards
The number of true standards is equal to 1 divided by the number of competing standards.
If you have 4 different UI's, then you really have 1/4 of a User Interface Standard. If you walk up to a machine at random (assuming balanced distribution among "standards"), you have a 1 in 4 chance that it is running what you'd want to make the machine usable -- there is a 3 in 4 chance that you'd have to change it to make it usable for yourself. You also need to know enough about how to install YOUR version of UI on YOUR system. Others need to know the same. It becomes standards anarchy.
Unix keeps trying to approach 0 when it comes to their standards. Of course that may be better than MS products which often get a "divide by zero" error, but 1 (and only 1) would be best.
Think about Scripting Systems, or CLI shells. Ask a Unix user what is the "standard" shell, or what it should be -- or ask which scripting language should be the "standard" (1). There are probably a dozen of each (or more) on Unix -- so you have 1/12th of a standard. Everyone installs their own, or every flavor of UNIX has their own favorite, or there are dozens pre-installed -- it isn't is exactly clean and simple. For now users need to be burdened about all the options, and which one may be best (or default), and so on -- and know that it can change on anyone else's system.
(1) If there are a few Unix geeks in the room a geek-fight may ensue -- with clawing and spewing techno-terms, and insults like "You don't grok awk!"
Balance
Of course life is about balance. All those different choices give people options. Most of the options are wrong, most of the time. That is the cost of those options. Of course a small fraction of the time, one of those options is far superior than the others, and you get a pay off. Geeks and Unix people live for that -- finding the perfect tool.
So on the Mac people choose AppleScript 90% of their time to do scripting (with maybe an augmentation tool or two to help) -- it is a higher level tool, easier to use, and in many high-level ways, it is more powerful. Unix people still war over what is the best shell and scripting language -- with 90% of the time it not mattering (or not mattering enough to justify the choice). The remaining 10% of the time, you can add that tool to the Mac anyways -- but at least there was A (one) standard to begin with. But in some low-level ways, you can do more with the Unix tools, with only 5 times the effort -- and for some task (rarely) there is a gain by using the specialized tool.
Conclusion
The point is not to trash Unix. It's versatility and power are second to none. The Low-Levels of Unix make it a programmers paradise -- and a god-send to the control freaks who want to be able to tweak their own kernel, or modify timing issues on their networking stack. It took 20 years, but a fair amount of Unix features did get one standard (POSIX) -- of course that is only a small fraction of what Unix is -- and POSIX is mostly "Lower Level" things (that only a programmer would love). But it is a start. At this rate UNIX will mature into a nice OS in another 30 to 50 years (if the fragmenters and configurationalists don't have their way).
UNIX is a raging success as a Server OS, because once configured, it runs like a dream. It is fast, elegant, and just works damn it! But UNIX has failed, and will continue to fail, to be anything other than a Server OS (or programmers OS, or turn key solution) strictly because of the configurability and amount of options and potential tweaks and so on. Hopefully the UNIX types figure out what I'm saying, and can generate enough consensus to override the "featuritists" and get over the religious wars over every implementation detail (and accept "good enough") -- or the UNIX industry learns a little pragmatism. But I'm not holding my breath. UNIX is the playground for the purists and where they all make their final stands. It is a great geeks OS because of all that -- but that is exactly why it is not a good User OS, and won't be until they get over that.
It requires years to become proficient in all the UNIX possibilities (at least weeks to get the basics, if you are already technically savvy). Companies can't afford to pay for the huge learning curves to get most people comfortable with Unix. Users don't have much tollerance for all that configurability -- they are looking instead for usability. It is usable (for users) if IS/IT preconfigures a System with everything a user needs, and makes it a complete "turn-key" solution -- but that rips all control (and sense of empowerment) from users (and that has quite a few other hidden costs as well). So that is not a perfect cure.
There are claims of returns in productivity -- but I was doing VAX/VMS, UNIX and DG's AOS/VS before many of the New-Hacks were in diapers. There are some returns, rarely -- but that doesn't forgive the losses for most of the time, which most of them ignore. It is like scripting anything -- if it is going to take you more time to script something than you are going to gain by having it scripted, then it probably is a LOSS! But that won't stop some from wasting 10 times more time than they will ever see a return on -- "because it's cool". They like the challenge, and ignore the sensability of what they are doing. But I don't even want to go down this path more -- I'm already going to get 3,000 eMails from rabid UNIX types, and I don't feel like doubling that number on the great Holy debate (that still rages in UNIX circles) over CLI versus GUI, or the mythical returns on productivity by having to learn great series of uninteligible symbols for the sake of saving having to click on something twice.
Despite the negatives (or because of them), I look forward to when a Unix Kernel is underneath the Mac OS (Mac OS X). UNIX is the best CLI and old-school OS that is around. Mac OS is the best GUI and new-school OS that is around. All those years of tweaking and geeking has made Unix pretty clean and fast underneath (even if you do have to know too much). UNIX is still a programmer and geeks dream (and users nightmare). What Apple can bring to the game is one clean STANDARDIZED user interface, and lots more standardized behaviors (and Apps). They can make a UNIX that is designed for users (not just geeks). Apple stands the best chance of bringing UNIX functionality to the masses (by hiding most of it) -- while hopefully still giving the geeks enough of what they crave. Let's hope Apple can walk the fine line and give us the best of both worlds, and not the worst. The closer Apple comes, the more they will be ridiculed by the extremists -- so I'll measure Apple's success by the number of complaints coming from UNIX purists (and the number of praises coming from the rest).
For the record, I do know of many good UNIX people, and UNIX people who get the high level, interface, and ease of use stuff. A few even know about the tradeoffs of complexity and configurability. Unfortunately they seem to be the silent majority -- the extremist minority has the bull-horn. Trust me, I know. For trying to explain some of the flaws in UNIX I will be email blasted for days.
|
