Critical Thinking

Maybe I'm just being cynical, but I fail to see why Apple's decision to move to the Intel architecture is such a big deal. Let's get real here folks, it's simply a change in CPUs.

OK, so maybe there's more to it. So the Macs may drop a touch in price, and/or get a bit faster. Personally, I've been wanting to get a Mac for a while, ever since I put together a server on BSD. I loved BSD's reliability and speed, especially compared to the Windows 2003 Enterprise server that it replaced. Put simply, BSD rocks, and the idea of using a computer built on BSD, plus a usable GUI (call me crazy, but I think X Windows, at least in every X environment I've worked in, is total garbage to deal with, just a fancy way of handling multiple shell sessions) would be really nice. When Apple announced the Mac mini, I was extremely happy, and started saving my pennies. Sure, I could get a pretty decent PC for the same money, but I'd still have the same PC problems. And frankly, the perceived lack of software for Macs doesn't bother me too much, because my home PC doesn't do anything that I can't do on a Mac or a BSD system. So I was already prepared to take the Mac plunge. I've even downloaded installers for all of my common software, just wanting to FTP it over the moment I get it plugged in.

Am I holding off on getting that Mac mini because I want Intel. Heck no. I'm holding off for the same reason my home PC is an Athlon 1900+ with 256 MB RAM: I have higher financial priorities at the moment. But I'm looking forwards to it.

When Apple announced that they would be switching to Intel chips, everyone made such a big deal about it. I didn't see the cause for the hoopla then, no do I see it now. OK, maybe IBM didn't have the roadmap for the G5 that Apple wanted, and maybe they were having some bad karma with Motorola. But at the end of the day, none of my Mac using friends ever complained about having a slow Mac, they are all delighted with it. The current G5 chips are good enough for now, and moving to Intel is a simple business decision to keep the future as bright as the present.

So I started asking around, trying to find out what the big deal is. My Mac friends could not care less. As long as they're using Mac OSX, they don't care if there are ferrets running inside the box handing delivering piece of paper with ones and zero written on them to each other. They just love the OS. My PC friends are all delighted because they have these grandiose dreams of dual booting.

Sorry folks, I've been down the dual boot route. NT4 & Windows 95. OS/2 Warp and Windows 3.1. Windows 98 & BeOS (yes, I tried BeOS, loved it to death, no applications or drivers, sad to say). Indeed, BeOS was originally designed for the PowerPC, then ported over to x86 when Be couldn't sell any of their boxes. I did Windows 98 and Windows 2000 for a while too. But at the end of the day, I always despised dual booting. Life is always more miserable when you dual boot. Many advantages of each OS are tied to the file system. NTFS is the cornerstone of NT/XP's security system. HPFS was integral to OS/2 Warp. And I'm sure that HFS+ plays a large role in OSX's capabilities. Yes, I'm aware that many of the OS's I've listed can read NTFS. But they can't write to NTFS. No Microsoft OS reads or writes to anything other than FAT16/32 and NTFS (actually, NT 4 may have been able to handle HPFS if memory serves). The point is, you're going to have a situation where you're going to end up sticking a giant FAT32 partition somewhere in your system for your common data files, plus have two more system partitions, one for NTFS and one for HFS+. And to be honest, I 100% hate that idea. I jump through hoops to only have one volume mounted in my system, I don't like dealing with drive letters (I know that MacOSX doesn't use drive letters). It's a pain in the rear to have to figure out which directory a file goes into, not just based upon its contents, but also upon which directory or volume or whatever has space remaining.

Plus, dual booting is a huge waste of time and interupts my workflow. People buy faster computer parts because they don't want to wait thirty seconds to two minutes starting an application. But with dual booting, this is exactly what you'll be doing. Need an application that runs on the OS you're not currently working with? Well, you get to stop EVERYTHING you are doing and reboot. Heaven help you if you miss the boot loader and end up in the wrong OS. Furthermore, isn't one of the reasons why we like our newer operating systems is because we have to boot less often? Every new version of Windows certainly advertises this as a selling point. No one enjoys having to drop everything because something (or a crash) requires a reboot.

OK, now there's the hypersior option (Microsoft's Virtual PC, Xen, VMWare, etc.). Call me silly, call me crazy, but a modern OS sucks up a good amount of RAM and CPU time, even the more efficient ones like the *Nix's. Unless all of the OS's you're running are using microkernels, or aren't doing much of anything, you can count on having to double your RAM and increase your CPU requirement by at least 25% in order to have two OS's running on the same hardware simultaneously. And if you have one OS running CPU intensive activities on a regular basis while you work on the other OS, you should go ahead and increase that CPU power by 50% to 100%. Well, what if you are already running a top-of-the-line CPU, or close to it? I guess you'll just have to suffer performance way below what a single OS would deliver on the same hardware. Not to mention hard drives. Unless you want to have two hard drives (in a hypervisor situation, where each OS has its own volume, and a shared volume for common data, I'd reccomend three drives), each OS is going to be trying to read and write from opposite ends of the disk simultaneously. Hooray. It'll be like deliberately making myself use tons of swap file space in terms of speed. And we still haven't overcome the file system issue. I hope you enjoy having all of your data readable by anyone who gets access to your system, because all of that shared data will be on a FAT32 partition. Not to mention that FAT32 is just about the least efficient file system out there, unless you count FAT16. Not to mention the lack of nifty features like NTFS's built in compression and encryption, or HFS+'s metadata support (a big selling support for MacOSX), journaling, hard and symbolic links, etc. Or alternatively, you could just have everything in NTFS, and the MacOSX system wouldn't be able to write to it. Just what I've always wanted, a 250 GB CD-ROM disk. My other option (probably the best one, sad to say) is to have the common file system be in a native format for one of the two OSs, and then share it via SMB. Yucky, but at least both OS's will be able to read and write to the data, and maintain some of its native file system benefits. So let's add up this hypervisor nonsense. You are almost doubling your hardware power to acheive the same results, the only thing that you're sharing are the peripherals and optical drives. At that point, doesn't it almost make sense (except for power consumption) to get a Mac and a PC separate and  a KVM switch from a cost standpoint? Going to the high end of the CPU chain (and the motherboard to support all of this RAM and the fancy CPU) is about as expensive as having the two machines sitting next to each other.

Even with OSX running natively on Intel hardware, the applications are not running natively on Intel hardware. They are being emulated, via "Rosetta". I'm not a big fan of hardware emulation, even when it isn't buggy, it is still slow. Quite frankly, I'd prefer a Mac that is 10% slower on the hardware running native apps, than a Mac running 10% faster emulating another chip for 80% of my apps. That's just common sense.

Oh yeah, and there's one more catch: MacOSX x86 will only run on Apple hardware. I'm sure that there will be XP drivers for this hardware soon enough, that's not a concern. But do you honestly think that Apple will stop charging the "Apple Tax" just because they've switch to Intel? Sure, G5s are more expensive that x86 chips on a pound-for-pound basis, but not nearly by the same ratio that a Mac is more expensive than an equivalent machine. Compare the Mac mini to some of the low priced options from Dell and eMachines/Gateway. The Mac mini costs about 20% more, and comes with less goodies typically. So yes, the price of a Mac will come down, but by what? $50? Maybe $100? It still puts a PowerMac or even an iBook out of the price range of mortal men. It makes the Mac mini, and the eMac slightly more affordable, that's it.

But all of my eagerly-waiting pals say, "but I won't use Apple's hardware, I'm sure someone will release a 'patch' to let me run MacOSX x86 on my existing hardware, and someone will have drivers." Good luck my friend. First of all, I'm not a big fan of ripping a company off. The profits that Apple makes from their overpriced hardware directly support their continued development of OSX. Deprive Apple of their R&D budget by not buying their hardware, and either the price of OSX goes up (the operating system that charges you for minor version upgrades as it is), or they put less money into developing it. Furthermore, if there is one thing I'm very particular about, it's stuff like hacking the internals of my operating system and messing with my device drivers. This is the kind of thing that leads to OS instability. I'm not a big fan of OS instability, otherwise I might still be using Windows 98, which would run a heck of a lot faster than XP does for me. This is why I avoid third-party "system tweak tools" like the plague. This is why I don't let spyware or rootkits on my system. This is why I don't upgrade my drivers unless I'm actually having a problem, or unless the drivers supports something I desparately need to do. This is why I avoid real-time virus scanning. I don't do these things because an operating system is under enough stress as it is, without some bonehead messing with its internals. Furthermore, is someone who hacks an operating system up to make it run in violation of its license agreement someone I trust to give me an otherwise clean and unmodified OS? I think not. People downloading warez and MP3s through P2P services like GNUtella and BitTorrent are getting killed by virues, spyware, etc. like the plague. Someone who goes through the effort of cracking an installer could just as easily through something nasty in there for you as well. I would not trust my OS to come from such a source, and neither should you.

So at the end of the day, where are we? To effectively use Mac OSX on Intel architechture, it won't be any different than it is today. It won't be too much faster, if you want to use PC apps you should still have a PC sitting right next to it, and you'll still be paying through the nose for Apple's hardware. As excited as I am to get onto OSX as soon as my wallet allows, I don't see how this gets me there any different or faster.

As a parting shot, to all of those who were actually surprised that Apple had an x86 iversion in the works, I simply point you to the "Ask the developers" page on Apple's site (note the date of when this page was put together, 2001). Also take a look at the source code tree. Darwin (the underlying OS) has been available on x86 architecture since Day 1. Sure, the GUI isn't on here, but the OS itself is half the battle. Microsoft had a PPC version of NT when it was NT 3.1, 3.5, and 3.51 (they also had a version running on SPARC!), and maybe even in NT 4 (memory is weak on that one too). An XBox today runs on a PPC chip; it also runs on what is admitedly a modified version of Windows 2000. Every OS manufacturer out there keeps a seprate port tree for CPUs they don't support, it's common practice, and a smart one too. It leaves their options open in a way that's a lot cheaper than if they suddenly find themselves without a chipset to support anymore. Plus, it gives them leverage with the hardware folks.

At the end of the day, no matter how I slice and dice it, I simply fail to see why OSX x86 is such a big deal. Yes, Intel chips are better on power usage, a win for the laptop users out there (BTW, has anyone noticed how battery technology lags so far behind power usage?). Yes, Intel has a better roadmap than IBM has for the G5 line. My heart rate might have gone up for a split second if Apple announced that they were witching to AMD64 technology, but they aren't. There is nothing to be worked up over on this, and this is certainly not a world changing event. If anyone can explain in a reasonable way why this is actually worth getting excited about, please let me know and  I'd be grateful to concede defeat.

For some reason, a huge number of people on ZDNet, both in TalkBacks and in articles (Mr. Berlind, are you reading?) confuse a central file server with "thin computing".

Mr. Berlind's example situation (a really bad one, at that) is simply using a web browser as a thick client application to access a central file server. Especially in the AJAX world, clients get thicker not thinner! For example, I have been doing some writing on this website right here. Their blogging software puts such a heavy demand on my system at home, that it was taking up to thirty seconds for text to appear on the screen. Each keystroke caused my cursor to be the "arrow + hourglass" cursor. Granted, my computer at home is no screamer (Athlon 1900+, 256 MB RAM) but that is what AJAX does. It requires an extraordinaily thick client to run. If I compared that AJAXed system to, say, using MS Word (a "thick client" piece of software) or SSHing to a BSD box and running vi ( a true "thin client" situation), that AJAX system comes out dead last in terms or CPU usage. And after my system does all of the processing for formatting and whatnot, what happens? It stores the data (via HTTP POST) to a central server, which stores that information somewhere, performs a bit of error checking and then makes a few entries into a database table somewhere. If I compare the CPU usage on my system by the AJAX interface, to the CPU usage of the server to file my entry, it sure doesn't look like a "thin client/thick server" situation to me! It looks a heck of a lot closer to "thick client/dumb file server" story.

Some of the comments to this story are already making this mistake. "Oh, I like the idea of having all of my data on a central server." So do I. This is how everyone except for small businesses and home users have been doing it for decades. The fact that most business people stick all of their documents onto their local hard drives is due to a failure of the IT departments to do their jobs properly, for which they should be fired. Why are people in marketing sticking their data on the local drive instead of on the server? Anyone who saves data locally and loses it should be fired too, because if their IT department did the job properly, this would not be possible without some hacking going on. The correct setup (at least in a Windows network, which is what most people are using, even if it's *Nix with Samba on the backend) should that there is a policy in place which sets "My Documents" to a network drive. This network drives gets backed up every night, blah blah blah. The only things that go onto the local drive should be the operating system, software that needs to be stored locally (or is too large to carry over the network in a timely fashion), and local settings. That's it. And if someone's PC blows up, you can just flash a new image onto a drive and they're up and running again in a few minutes.

Now, once we get away from standard IT best practices, what is "thin client computing"? We're already storing our data on a dumb central server, but doing all of the processing locally. Is AJAX "thin computing"? Not really, since the client needs to be a lot thicker than the server. Is installing Office to a central computer "thin computing" but having it run locally? Not at all. Yet people (Mr. Berlind, for starters) seem to think that storing a Java JAR file or two on a central server, downloading it "on demand" and running it locally is thin computing.

Thin computing does not occur until the vast majority of the processing occurs on the central server. That is it. Even browsing the web is not "thin computing". Note that a dinky little Linux or BSD server can dole out hundreds or thousands of requests per minutes. I challenge you to have your PC render hundreds or thousands of web pages per minute. Indeed, even a Windows 2003 server can process a hundred complex ASP.Net requests in the amount of time it takes one of its clients to render on the screen one of those requests. I don't call that "thin computing".

Citrix is "thin computing". Windows Terminal Services/Remote Desktop is "thin computing". WYSE green screens are "thin computing". X Terminals (if the "client" {remember, X Windows has "client"  and "server" backwards} is not local) are "thin computing. Note what each one of these systems have in common. They are focused on having the display rendered remotely, then transferred bit-by-bit to the client, which merely replicates what is rendered by the server. All the client does is transfer the user's input directly to the server, which then sends the results of that input to the client, which renders the feedback as a bitmap or text. None of these system require any branching logic or computing or number crunching or whatever by the client. That is thin computing.

Stop confusing a client/server network with "thin computing". Just stop. Too many articles and comments that I have seen do this. They talk about the wonders of thin computing, like being able to have all of the data in a central repository to be backed up, or have all of my user settings in a central repository to follow me wherever I go, or whatever. I really don't see anyone saying anything that is "thin computing" that does already exist in the current client/server model. The only thing that seems to be changing is that people are leaving protocols like NFS and SMB for protocols like HTTP. It's a network protocol folks. Wake up. It's pretty irrelevant how the data gets tranferred over the wire, or what metadata is attached or whatever. It does not matter. All that matters is what portion of the processing occurs on the client versus the server, and in all of these siutations people are listing, the client is still doing the heavy lifting.

Well, here it is, Thanksgiving! And I'm trying to find some technologies that I am thankful to have in my life, since lately technology has been doing its best to make my life unhappy. So here's what I've come up with:

CD Players: Storage capacity and size aside, there is nothing that an MP3 player can do that a CD player can't. And CDs are easy. Most importantly, the players are cheap now. CDs have been part of my life for 15 years now, and I'm always happy to have them in my life. And unlike just about everything else tech now, I've never had one crash on me.

IBM ThinkPad 390E: Never heard of this model? Not surprising. It's a PII 300 mHz system with 160 MB RAM (I'm sure it's more, but I don't know how kmuch was allocated to video). Sure, it's slow. The CD drive doesn't recognize that a disc is in there. I got a floppy jammed into the drive a few nights ago (trying to find a good floppy to start a BSD install with). With XP on it, it is so slow that it can't play the wave file Windows sounds properly. It's fairly heavy and has few features. It is so outdated that it does not have a built-in Ethernet port. But it has one thing that no other piece of equipment in my life has: durability. The thing is a tank. If I got into a fight, I would rather be armed with the 390E than a knife. And I'm sure it would still work afterwards. It doesn't crash, either. For the two or three times I go on the road a year, I know that I can count on it to give me just enough connectivity to survive. Most importantly, when I have a major hardware problem, it tides me over until I can resolve the problems with my other machines.

Microsoft's .Net Framework: I don't care that is is nearly as sloppy and inefficient as Java, or that it is not cross-platform. .Net has saved me hundreds of hours of coding time, and Microsoft's fantastic documentation has saved me at least a few dozen hours in the last year. Compared to working in Java, .Net is a dream. Visual Studio is a great IDE, and its tight coupling with IIS gives me debugging powers on web dev projects that I never found with Java, Perl, or PHP. This saved me even more time and leads to better code.

Cell Phones: I live and die by the cell phone. I haven't had a landline in nearly four years, and don't miss it at all. My cell phone is cheaper than a landline, too. I like not having to take personal calls on a work phone, being able to leave the house and not interupt a call, and I appreciate the ability to send text messages and email on the road, miserable as the interface may be, in those clutch situations. There are a lot of great things (and important things) that I would have missed without the ability to be reached wherever I may be, since I am so infrequently at home.

USB: The number of peripherals has skyrocketed since the invention of USB. High speed, easy device connectivity, easy to add multiple devices and not be limited by thenumber of ports on the machine... USB has introduced us to a whole new world of computing options. Digital cameras, scanners, web cams, all of these cool things would not be nearly as widespread as they are today without USB.

Digital Cameras: OK, so my ex is holding on to mind lately because she's been wanting to take a lot of pictures. But when she isn't, I carry mine around everywhere. I used to do the same with a film camera, but then it would sit until I got around to getting new film, and I hated the development costs and wait and everything else. I love digital cameras, and have since I got my first one.

Inexpensive Broadband: Ever since 2000, I've been a cable modem user. It is as cheap as a second phone line + and ISP account, a billion times faster, and super-reliable. Broadband has made my life infinitely less frustrating, and for that alone, it gets my thanks.

So that's my list for now. What's on your list?

J.Ja

"Apple Sales Mushroom, Thanks To Intel CPUs"

That is one headline that we will definitely not be seeing in 2006. Standard business practice to making a product sell, is to accomplish at least one of the following: better product for the same price, equal product at a better price, or superior customer perception of product, regardless of price. In other words, it either needs to be better, cheaper, or marketed as such.

I am not going to dispute Apple's back office reasons for switching to the Intel CPUs. They had a rocky relationship with IBM and Motorola, and the PPC platform was not going where Apple needed it to. Intel offered them a way out, and Apple had conveniently been maintaining an x86 version of OSX the whole time. If Apple had been maintaining a SPARC version of OSX instead of x86, we would be hearing about a Sun/Apple partnership right now. The decision has been made, the code has been written and is being tested. It is a done deal.

But those who think that this deal will significantly boost sales of Macintosh computers are dead wrong. The Intel architechture simply does not add value, reduce prices, or make the product more marketable. Here is why.

Increased Value

This is a simple question to ask. "Does the Intel architechture make a Macintosh any better?" Currently, no, it does not. Yes, the Intel chips are running at a higher clock speed than many of the G4 and G5 CPUs that Apple will be replacing, particularly on the low-end. The mini and iBook are running fairly old chip designs. But remember our business rules here: Apple needs to offer a better product at the same price.

Better Product?

The switch to Intel CPUs will not make the Macs better at first. Yes, the Intel architechture offers a better roadmap for the future, which means that the Macs a year, two years from now will be better than they would be had Apple stayed with the current PPC chips. But if IBM had devoted as much time to Apple as they have to Sony and Microsoft (for the PS3 and XBox 360, respectively), then the PPC Mac roadmap would be a five lane highway compared to Intel's dirt roads. The x86 architechture also is not offering any new features above and beyond what PPC should have been offering. It isn't like they are building ATI Radeon 800's or integrating 200 GB hard drives onto the CPU or something.

Yes, the Intel chips of today may have a higher clock speed and even perform more FLOPS than the PPCs of today. But without x86 native binaries, and nearly every piece of software running through the Rosetta translation layer, I am positive that for the first six months minimum, if not as long as two years, software running on the Intel Macs will not be noticeably faster than software on equivalent PPC Macs. I am pretty sure that it will actually run slower for many, if not most applications, for some time.

I have also written extensively about how the Intel switch will not bring any other tangible "value adds" to Mac users.

On the "better product" angle, the switch to Intel CPUs simply allows Apple to continue at the rate of improvement that they should have had with PPC, which simply means that (at best) they will be producing the same numbers as Dell, HP, Gateway, etc. That is hardly an "imporvement". Any speed gains they get will have to come through superior OS design, and relies upon the availability of x86 native binaries. Considering my experiences with finding x64 native binaries and device drivers for my new Windows x64 XP Professional PC, I think that the Mac users are going to be quite shocked at how little will be available for them, at the time of launch for sure, and even much further down the road.

Same Price?

Paul Murphy, over at ZDNet, recently wrote a very interesting article regarding the Intel CPU switch. To summarize: a low-end Intel CPU costs $240, the G4 that is used in the iBook costs $72. That is a price increase of about $170. Apple's number one barrier to entry is the cost of their products. Mr. Murphy's numbers seem sound to me. To be honest, I stopped watching CPU prices around the time I bought a 486 DX4 120 mHz system, so I cannot verify them. But they seem about right.

No Value Added

If Apple had gone with AMD (particularly the AMD x64 CPUs) or even SPARC, I would not need to write this article. They would be delivering superior performance at the same, if not less price, then they are now. But they went with Intel. They are paying more money for less performance. Which means that they must either be offering the same value at a better price, or find a way to increase its markeability.

Same Product, But Cheaper

Same Product?

As discussed earlier, the Intel Macs will be, at best, as good as the current Macs, and the Intel roadmap is no better than what the PPC roadmap should have been. I am going to give both Intel, and the Rosetta translation layer the benefit of the doubt, and allow that the Intel Macs will be as good as the current offerings. It isn't inconceivable, that is for sure. I have no way of knowing without seeing some cold, hard numbers when the final version is released. None of the reviews I have read of the developer kits mentioned performance in any memorable way, so I am guessing that performance was not on either extreme of the scale. So we can assume that (once again) at best, the Intel Macs will be the same product as the currents Macs.

Cheaper Price?

This section definitely feels like deja vu. The Intel Macs will not (and cannot!) be any cheaper, at least on the low end, than their PPC counterparts. I have not seen prices for the high end G5 chips, but it is possible that the big PowerMacs will be $100 - $200 cheaper than they are now. Considering their current prices, that is a welcome price drop, but still hardly enough to suddenly make them a bargain.

No Pricing Advantage

Once again, I do not see the Intel CPU architecture giving Apple an advantage that they do not currently have. Since Apple isn't going to be making a better product, or a cheaper one, that leaves them with only one way to significantly grow Mac sales...

Marketing

Without a better product or a better price, Apple must rely upon the arcane art of product marketing, based around the switch to the Intel CPUs to make sales jump at all, and possibly even to reassure the faitful that this is not a Bad ThingTM.

"Intel Inside" is one of the most pervasive ad campaigns out there. The vast majority of the computing users worldwide use a computer with an "Intel Inside" sticker on it. But "Intel Inside" will not bring a single advantage to the Apple marketing strategy. There are a few reasons for this, based in the "Intel Inside" campaign, as well as Apple's current marketing efforts.

Intel Inside

What does "Intel Inside" promise to the end user, to make it something worth paying extra money for? Let's look at the History of "Intel Inside" website to find out. Apparently, "Intel Inside" was designed to present the following ideas to customers:

• It matters who makes the CPU within your system. Intel wanted the consumer to equte "Intel" with "safety", "leading technology", and "reliability".
• There is an easy way (the stickers, the little noise in ads, the logos in ads, etc.) to easily identify what computers use Intel CPUs and which ones don't.
• Early "Intel Inside" campaigns stressed "speed, power, and affordability".
• Current "Intel Inside" efforts focus upon "technology leadership, quality, and reliability".

When one looks at Intel's overall branding efforts, this is definitely what we see. They stress that Intel CPUs are the gold standard for x86 compatability, that PCs work best with Intel CPUs (the Centrino campaign takes this message to nearly scandalous lengths, presenting users with the idea that their computer will not work with non-Centrino equipment through dodgy wording), and that Intel is constantly innovating.

Apple Switch

To grow market share, Apple needs to cut into the PC market. Yes, having 3% - 5% of a market the size of the PC market is still a very nice slice of revenue, but they want to, and need to grow it. They have known this for a long time now. Apple counts on existing Mac owners to keep buying new Macs. From what I can tell, with the exception of those forced to go to PCs for financial or business reasons, that holds true. I have never met a Windows user who actually seems delighted to be using Windows. I have never met a Mac user (one who chooses to use a Mac, that is) who fails to provide free advertising for Macs. They definitely have something good going on there. The fact that Apple's market share hasn't been shrinking while the computer pie gets bigger says that Apple is signing up new users as fast as the market expands. That is a good thing for them. Due to the nature of the situation, Apple has been throwing their energies (rightfully, in my opinion) at existing PC users. Let's take a look at the "Apple Switch" marketing campaign.

• "It just works"
• "As easy as iPod"
• "Picture-perfect photos"
• "It's a musical instrument"
• "Home movies in HD"
• "Online streamlined"
• "Join the party" (about Apple's support and community)
• "It loves road trips" (portability, easy connectivity)
• "It does Windows" (ease of opening/editing files produced on Windows PCs)
• "It's beautiful"

I do not see any convergence, synergy, or shared edges (how's that for some buzzwords!) with the "Intel Inside" campaign. In other words, "Intel Inside" does not offer any additional zing to the Apple Switch campaign. Indeed, most of the "Intel Inside" campaign actually works in reverse for Apple. OSX on x86 is untested, there are (and will be for some time) few native binaries, it will not be faster (and quite possibly be slower), and so forth. Chances are, OSX on x86 will be less reliable than OSX on PPC. OSX suceeded laregly because the "Classic Mode" worked so well. If people running Mac OS 9 programs had huge problems, no one would have upgraded, or have been willing to buy a new Mac with OSX installed. But Classic Mode worked, and worked well, and worked fast, and OSX was adopted.

"Intel Inside" will certainly be a tough sell to the current Mac market, and it will not help Apple at all in competing against Windows. It reduces their hardware, in the minds of the consumer, to a commodity device, equal to a PC. Will a potential buyer be happy about paying significantly more money for nearly identical hardware, simply because the OS is different? Probably not. In terms of marketing, I think "Intel Inside" is dismal. Sony is not a super-huge PC seller for this reason. Sure, their computers have nice design and are packed with features. But if you are willing to settle for an uglier case, keyboard, mouse, etc. then you can save hundreds of dollars by purchasing a similarly equipped HP, Dell, eMachines, etc. PC. With Intel hardware, Apple positions itself as another Sony, and still has to overcome the problem where consumers perceive a Mac as being incompatable with what they want to do.

Conclusion

"Intel Inside" will not drive Mac sales at all. If Apple sales rise significantly in the near future, it will be because they are either able to substantially improve the value of a Mac, either by being able to offer faster/more hardware for the same price, or by dropping the price quite a bit. The mini shows that people are willing to buy a Mac, if the price is right. Apple needs to get that price even better. That is how they will grow market share. If the Intel CPUs could do that, I would beleive that the switch to Intel will drive sales. Unfortunately, Apple chose Intel, instead of Sun or AMD to work with, and we are going to be stuck with overpriced, underpowered Macs for the foreseable future.

As I was setting up FTP access for our clients, I got upset, once again, at how we handle our policy regarding customer access. One of our customers does this right: each person in our company who needs to access their network has an individual username and password. My boss, and most of our customers, just want a single username/password for anyone in their organization to use. Already, this gives me a stomach ache. The idea that someone who does, or used to, work for our customer would have access to our network, with me having no way to block them by IP address, or be able to tie a login attempt to a particular individual is a frightening thought to me.

To make it worse, a number of the higher-ups got upset at the passwords that were being assigned. "They won't be able to remember these passwords!" was the main complaint. Well, Windows 2003 won't let me assign easier passwords, unless I change the default policy. I'm not going to do that. Our customers have been accessing our systems with username/password combinations like "companyname/companyname" for far too long, as far as I am concerned. We process sensitive data, such as sales figures. As it is, I am considered an "inside trader" as far as blackout periods and whatnot are concerned, because I have access to all sorts of raw data, and that data in turn becomes finished reports. It is extremely important that we safegaurd this data to the best of our abilities.

My stance is, if our customers cannot be bothered to learn a complex password to protect this data, they need to get out of the industry. NOW.

This entire situaiton got me thinking back to some of the other security faux pas that I have witness during my time in IT. Here are a few of my personal favorites:

• A major US bank outsourced its network management. Us peons at the Third Party Vendor had a habit of writing down router usernames/passwords. Even the HQ routers used the same usernames/passwords. Sure, it was all VPNed with IP address filtering, so no one outside of the "green zone" could access their routers. At least not over VPN. Sadly, all of their routers had either ISDN or dialup failover interfaces. The ones with dialup interfaces could also be accessed by dialing in, for troubleshooting purposes. There was no differentiating what you could do based upon which interface you came in on, so in theory, anyone with one of those phone numbers can dial in to one router, telnet to a HQ router, then access then entire network from there. It would be trivial to shut down the entire bank's network of ATM machines and branches in a matter for an hour or two with a well written script or program that can dial a modem. With no accountability, other than the phone number from where the initial call was placed. Oh yeah, did I mention that they have never onced changed their passwords, and that the passwords, as well as all troubleshooting information are freely available within the TPV's intranet to all who want to see it?
• At one company I worked for, we had a massive Solaris server running HP OpenView. Sadly, HP OpenView is probably the worst engineered piece of software ever to be sold outside of the $10 "Instant Website Maker!" section at Best Buy. It is a testament to Solaris' abilities that the server kept running, because HPOV was leaking memory like a torpedoed ship leaks water. Here's where we had a nice little hole in our security: because HPOV was such a steaming pile of garbage, every user had the root password, so they could kill and restart HPOV. You might as well just make everyone a root user, at that point.
• Growing up and learning COBOL on an ancient system, what a fun time. too bad we were all umasked so all of our work was chmod'ed to 777. It's not hard to cheat or destroy someone else's project (as happened to me, someone changed one of my PIC statements, and it took me two months to find out why my final project never quite seemed to work right) when hacking is a matter of "cd ~username".
• File permissions are a favorite security faux pas of mine. A company I used to work for (let's just call them "a Fortune 500 company who's former CEO now runs one of the top three computer makers" and leave it at that) used network storage space for all sorts of important documents. A lot of these documents, frequently pertaining to things such as the status of sales to customers, layoffs, offshoring, outsourcing, contractor conversions, employee pay rates, and so forth were typically created with read permissions to the "Everyone" group, because some nitwit sys admin had turned on inheritable permissions (fair enough) but set the top level permissions too loosely.
• Microsoft Indexing Service = "Intranet That Can Find The Documents I Am Not Supposed To Find". Just do a search within many corporate intranets for phrases and words such as "layoff", "consolidation", "India", "sexual harrassment", and so forth, and you find all sorts of embarassing things that were never explicitly linked to. What a great thing it is when "out of the box" defaults, mixed with ignorance on the part of a sys admin or a user, can result in anyone within the organization finding what should be restricted to a few top officials. It's even funnier when the mistake occurs not on the corporate intranet, but on the company's public website.
• Security through (barely) obscurity. This one always gets a chuckle out of me, when I see someone attempt to hide "top secret" information through such crafty ruses as HTML comments to hide the text, turning off the right mouse button via JavaScript, "burying" important information with a piece of Flash, and other easily found out methods. It's especially funny when you find it unintentionally, like if you view the source code to a document to see how they got a nice piece of design to work, and find a database password in there. The folks who write their code like this are typically pretty shoddy on their backends as well, you can usually hit them with a SQL injection attack because their super nifty search system is simply doing something like "sSQLStatement = "SELECT * FROM MY_DATABASE WHERE ID_CODE LIKE '%" + request.item("search_query") + "%"" or something along those lines. These same people often have really shoddy exception handling too, and let their database errors get sent to the client.

This is just a very short list of some of the most common/pathetic security flaws I have personally witnessed. All it takes is for someone to be as curious as me, with less boredom-related motivations and more malicious motivations to exploit most of them. About half of these I found while simply looking for the information I needed to do my job, and finding myself in a "forbidden" directory, or seeing something else on the screen that caught my eye.

Many of these are common mistakes on the part of end users that were enabled by poor systems administration. The vast majority of your end users have no idea that creating a directory for their supervisor in the common network area is going to expose that directory by default to everyone who wants to see it. Sys admins need to make clearly labelled "management only" directories, with the appropriate subdirectories for individual teams. Processes need to be clearly defined for systems operators at the low level for things such as department moves, new hires, employee termination, and so forth that ensure that users have only just as much access as they need. Group policies need to be put in place to disable USB ports from being used to hook up keychain drives, disable file transfers outside the corporate network over instant messaging, and so forth.

Some of these are problems with programmers who simply don't know better, or are too lazy to do better. These problems are trickier to find. There needs to be a rigorous code-review process in place, checking code for things like SQL statements without parameterization and whatnot.

For both groups of people, sys admins and programmers, there needs to be a combination of education and discipline in place for slip ups. All it takes is for one "wrong person" to get a hold of a document to bring your company's stock price tumbling, or have the SEC investigating, or any number of other problems. Why risk your company's well-being?

Unfortunately, systems administrators are often self-taught or trained in a haphazard manner. Too many people in IT have a certification with no experience to back it up. Programmers get cranked out of CS programs now with a lot of "this is how we do it today" knowledge, but little understanding of "why we do it like this". All it takes is for one of these people with paper qualifications but no true understanding to have to work with a new technology or a different language to be in the dangerous land of ignorance. And that will sink your business. Beware, and conduct regular inspections to ensure that standards are met.

J.Ja

I have been a long-time opponent of SaaS (Software as a Service) in general. Indeed, I think most of the "new ideas" in the IT industry are half-baked at best. But SaaS and thin clients (they go hand-in-hand) are nearly total bunk. Phil Wainewright (ZD Net blogger) and myself have been trading ideas back-and-forth lately regarding this topic. We both come at it from different perspectives, and there is a lot more agreement than one would think just by reading what we have written.

Mr. Wainewright beleives that SaaS is quite possibly the way we will do most of our IT in the future. I beleive that SaaS is doomed to fail, except in certain small niche markets. He and I both agree on two things. The first, is that SaaS vendors need to do business in a better and more ethical manner than traditional IT vendors. The second, is that SaaS vendors, so far, are not doing so.

But I also beleive that SaaS penetration will be limited for other reasons, not the least of which are technical.

SaaS will not make large gains where the data goes both ways. It will be primarily a read-only operation. The reason for this is that smart companies with IT budgets of their own will not trust a third party vendor (TPV) with their data. It is not just a matter of whether or not that data becomes unavailable momentarily. What if there is a slip up on the TPV's end that exposes one comapny's data to another company? That is potentially a major catastrophe. In addition, there is the issue of importing/exporting the data should you choose to leave that vendor. Even if they allow you to export your data in some common and open format that the new vendor is able to import, how many SaaS vendors out there are going to provide you with a bulk exporting system? How will your system interface with that? A SaaS vendor is set up to allow small, discrete data transactions, not massive rivers of data. For these reasons, companies will tend to primarily use SaaS services where the data transfer is read-only.

The Web is a miserable way of working on anything other than data which is easily put into a Web form. In other words, if the application requires anything other than textual input from the user, and input that is best displayed with standard Web widgets, then it probably won't fly very far. In addition, binary data streams traveling back and forth over a network are really not a fun way of getting your job done. Imagine trying to use a photo-editing (or worse, video-editing) application over a network. In a typical corporate environment, bandwidth is at a premium. Any cost-savings generated by a move to a SaaS vendor will quickly be chewed up by bandwidth costs. Is a 3D Studio Max liscense really cheaper than a dedicated leased line per employee?

SaaS will do well for applications that only a few users access, or that most employees use rarely but regularly. If more than a small number of users within an organization use a particular application, the economics of scale come into play for the customer. If an application is so important that a large portion of their employees are using it every day, the application becomes part of that company's daily bread and butter, and as such it makes sense to bring it in house.

SaaS will appeal mostly to small and medium sized businesses without a dedicated IT staff. For those companies where the "IT department" means someone in the office who knows to reset the cable modem when no one can get to the Internet, SaaS makes a lot of sense. For example, a small business that needs to have ODBC connectivity for small databases would be much better served by a company running Oracle on their end who gives them an EZ Installer CD that makes the right ODBC connections, and a web-based interface for creating new usernames and tables, than to have an Oracle server sitting in their backroom. It also makes sense from an financial standpoint. For a business big enough that they would need someone on hand who is either a DBA, or knows enough to fake it, SaaS'ing their database work simply does not make sense.

Companies with locations in technological hinterlands will be well served by SaaS. Imagine a call center or a factory or whatever in the middle of nowhere. They do not need a highly educated population, and they save a lot of money by putting their facility in a backwater (lower cost of living, lower prevailing wages, employees have nowhere else to work, less unionisation, etc.). The company can choose to either become their own SaaS provider, with the applications hosted at a home office where they will be able to hire qualified personell, or they may pay a TPV to provide SaaS, particularly if it is an application which only the remote location uses. In all honesty, it is downright difficult to find competant, qualified, and experienced IT workers in the boondocks.

SaaS will not be used for mission critical applications. The name of the game for mission critical applications is to reduce potential points of failure while providing redundancy wherever feasible. Email is considered mission critical, and therefore very few companies bigger than about twenty or thirty employees outsource their email servers. Once your website becomes a major part of your business, you either bring it in house, or at the least put a server in a co-location facility. It is one thing to have the nifty 3D map on your "how to get to our office" webpage be offline. It is another thing for the entire website to be offline. The data link between the SaaS vendor and yourself is a giant point of potentially dangerous failure. The last situation you ever want to be in is for a down telephone five miles away to put your entire company out of business for a day. It does not matter what promises the vendor or your carrier or whoever makes to you: stuff happens that you cannot prevent. You can only work to minimize that possibility. An SaaS situation multiplies your possibilities of disaster by a fairly large amount. Would you fly into an airport if you knew that the air traffic controllers were sitting five hundred miles away and communicating with the airport with VoIP? Neither would I.

I think that SaaS will be best delivered in the form of appliances. When someone signs up for SaaS services, they already accept that it will be a black boxed operation. The customer has no idea what happens on that server; there could be a few trillion lightbulbs switching on and off in their data center instead of hard drives for all you know. Since the customer is already accepting a black box service, why not sell them a purpose built appliance? A totally sealed, rack mount box (or blade system, for bigger enterprises) that just plugs into the network, picks up a DHCP address, registers itself in DNS, and is ready to go? Even better, it does not need to be a web-based application. Because it is residing within the network, large amounts of data transfer, such as an application installation are not a problem. It could very easily have an installer run on the clients to install software from itself. It could run out to the vendor's system periodically to fetch updates (and push them out to clients) and report usage information in the case of a per-usage billing situation. Alternatively, it could act as a web server or some other thin client server. It could even be running Citrix or Terminal Services. It doesn't matter. The point is, if SaaS vendors sold an appliance that delivered the service to the customer, instead of having them need to interact with a vendor's network in real time or nearly real time, the vast majority of the technical and business problems with SaaS will be overcome.

Tell me what you think.

Jakob Neilsen has posted what I beleive to be an extremely import article, which discusses the effect that search engines have on revenue for commercial websites. Mitch Ratcliffe at ZD Net also has a good blog up about the need to pay people for their contributions to websites.

How are these two ideas connected?

People do very little without motivation. Money is a great motivator. What Mr. Neilsen's article is pointing out is that it is getting increasingly difficult to make a profit on the Internet. Quite some time ago, search engines replaced DNS as the way people find sites. Now, to get found in search engines, it is requiring an increasingly larger amount of money to be fed into the gaping maw of per-click search engine advertising. When Yahoo! first started their paid review system, it was acceptable. You paid once, and that was that. Users could find your site. Now, you need to pony up cash each time someone comes to your site, unless you are lucky enough to be in the first page of the organic search results.

With more and more websites seeing visitors come directly into one page, and not leaving that page, they need to monetize their website on every single page, and make enough money for every single page to pay for that expensive per-click advertising. If a user does not find what they were looking for on the page that the search engine sent them to, they go right back to the search engine. Your site's "stickiness" is no longer important.

Unless you are selling a product with a great profit margin, you are in big trouble. Content websites do not have a great profit margin on a per-visitor basis. Take a news-related website. Let's say they make five cents per page view, on average, from advertising. They can't very well be buying their hits for a dollar each, can they? In other words, producing content online is increasingly less profitable, thanks to search engines.

The end result, I beleive, is that many if not most professional websites will go under. It is already happening to many newspaper websites. Their print sales are being ruined by online news, and their online sites are being forced to have paid subscriptions or to lose money. Users are increasingly going to blogs, wikis, and other amatuer websites for their news. I will admit, I have always been predjudiced against blogs, wikis, and other "community created" websites when it comes to objective (or "as objective as possible") information. Why? Because most of them are not making money and have no editorial control. Blogs are primarily done as vanity projects, for someone to put their thinly disguised opinions up as "news" with links to like-minded blogs as "proof" and solicit comments which stroke their egos. Wikis are great examples of groupthink, which a bunch of like-minded people democratizing Truth. When this replaces professional, reletively objective websites, we are in trouble.

There is a solution out, and that is for the content websites to find ways to generate traffic in a way that works around the search engines. RSS and traditional email newsletters are one way; you need only get the user to your site once through a search engine to get them to subscribe to your RSS feed or email newsletter. Search engine optimization is another path, as it allows you to get traffic through organic search engine results rather than paying for the placement. As Mr. Neilsen points out, increasing website usability is another solution: multiply the amount of money you make per visitor enough to offset or exceed the increased costs of getting the visitor, and you're in good shape. There are lots of ways. Confederations of content sites are another idea; it is probably much easier to get someone to pay a subscription fee (even a higher one) to have access to a group of websites (or better yet, incofrmation from a number of websites aggregated into one site) than it is to convince them to pay a fee to a number of different sites. For example, I would be very willing to pay, say, $100 a year for access to The New Yorker, The Economist, The New York Times, The Washington Post, and say, Encyclopedia Brittanica than I would be to give each one of these sites $10 per year. Indeed, I would love to see content websites bundled up like cable TV packages.

In any event, this is not some Chicken Little, "sky is falling" scenario. This is actually happening right now. Try buying space on Google; prices are going up, much faster than the profit margins of any product that I am aware of. The entrepenuers who try breaking into business online are going to find that their marketing costs are a lot higher today than it was five years ago. Doing business online is not as cheap as it used to be, and the inexpensive nature of online business was a major driver behind the Internet's explosive growth to begin with. The Internet reminds me more and more of the California Gold Rush, where the people who made the real money were the people selling picks, shovels, provisions, etc. to the prospectors. Search engine advertisement is now more critical than ever, and sadly, it is now a recurring, variable cost directly tied to the number of customers you have. Imagine if a store in the mall had to pay a fee to the mall for each person who walked into their doors, instead of a flat fee for rent each month. That is where we are headed, and it totally changes the game. Or worse, if everytime someone resolved your IP via DNS you had to pay a fee. Because more and more, that is what search engine advertising is looking like.

Tell me what you think.

I just read a pretty good article on CodeProject (http://www.codeproject.com/gen/work/standaloneprogrammer.asp) about how to be a successful programmer when you're the only programmer at a company. The suggestions in the article are all good. I am in that situation as well. Not only am I the only experienced programmer in my company (there are other people there who write code, but on a very limited basis, and nothing very in-depth), but I am also the systems administrator.

All in all, it is a pretty daunting task. If the servers blow up while I am facing a deadline to write an application... well, get the coffee brewing because it's going to be a long night. Our customers have the luxury of having dedicated IT people - here are the DBAs, over there are the programmers (sub-divided into Web dev folks, desktop application developers, specialized Excel/Access people, etc.), the sys admins are hidden in the data room, and so forth.

In some ways, I envy these companies. What I would not give to have to keep flipping between Windows 2003 Enterprise Edition troubleshooting, FreeBSD troubleshooting, database optimization (let's not forget, I get to run MySQL, Microsoft SQL Server, and Oracle, to add to the confusion), and programming in a hundred different languages - half of which seem to be VB variants to keep me on my toes at all times.

The confusion can be pretty funny sometimes, especially when I am multitasking. I recently told a customer to try "telnet'ing to port 443 to check for connectivity" when I meant to tell her to "comment out the if/then block" because I was troubleshooting an SSL problem on my server while helping her troubleshoot our code over the phone. Another classic is when people ask for a piece of code advice, and I give them the right answer... in the wrong language. Too many times, I have crafted a great Perl-ish regex for someone to elegantly solve their problem in one statement, only to remember that they are using VBA (or worse, SQL).

The situation has its rewards, however. I get to build experience along parallell lines, for instance. I can honestly say that in one year at this job, I have "1 year Oracle, MySQL, and MSSQL DBA experience, 1 year VBA with Word, Excel and Access, 1 year Windows 2003 and FreeBSD systems administration, 1 year VB.Net, 1 year ASP.Net, 1 year blah blah blah..." If I was one of those specialised IT people, I would need to work for 20 years to get one year experience in so many technologies. Of course, I came into the job with plenty of experience in a lot of different things, otherwise I would not be qualified, but still, it's great to get a wide variety of experiences all at once.

On that note, the work is rarely boring. I don't get mentally stagnant, and there is always something to do. If I am not working on a project, there is always some systems administration that need to get done. If I don't have any internal projects to get done, my help is always welcome on someone else's project. Do I get bored? Sure I do. But I get bored a lot less often than I did when I was a pure programmer, or a pure systems administrator, or a pure whatever.

To all of the other lone wolves out there, my hat goes off to you.

Note: this was originally posted as a comment (http://www.zdnet.com/5208-10532-0.html?forumID=1&threadID=17796&messageID=350047&start=-1) to David Berlind's article Yes. You should outsource your e-mail

Mr. Berlind is absolutely correct is quite a large number of his statements, and he does indeed provide a compelling arguement for outsourcing email. But he has made some mistakes, which is where we differ on this topic.

The first number one problem here, is that Mr. Berlind's original blog post is titled "Google to provide email hosting?" and is 100% about outsourcing your email to Google. I put forth the question "Now, let's look at the premise: assuming I would outsource my email, why would I outsource it to Google, of all companies?"

Mr. Berlind has not even addressed this at all. Not in the slightest. He provides a good (but flawed) arguement in favor of outsourcing. He does not even touch the idea that Google should be the one to do it. Mr. Ou adds a quick little list of why, even if outsourcing email is the right choice for your company, Google is not the one to do it (http://www.zdnet.com/5208-10532-0.html?forumID=1&threadID=17781&messageID=349545&start=-1). Admittedly, he did not go into nearly as much length or detail as I would have, but his comments really don't need much explaining (except for the user interface bit; GMail is pretty decent as far as web mail goes, and is garbage compared to a desktop app, is a good way of putting it).

Now, onto the topic of the current blog post by Mr. Berlind: "Yes. You should outsource your e-mail".

I say, "No. You should NOT outsource your e-mail".

"So, one question I have for Mr. James is, of all the stuff being outsourced today, what of it isn't mission critical?"

That all depends on the business, but I have not encountered a business that did not consider email to be mission critical since about 1998, if not earlier than that. Furthermore, the fact that companies *are* outsourcing portions of their business process does not mean that they *should*. I can think of a number of anologies to this, but this principle is best summed up by David Hume: "One cannot derive an 'ought' from an 'is'". If everyone in New York jumped off the Empire State Building, that certainly does mean that I should as well.

"But aside from the handful of hand-built customized competitive advantage-driving systems that integrate messaging and email into their functionality, are any of us really that deluded to believe that insourcing something as basic as email can make us more competitive than the next company (setting aside those companies with real security concerns that can prove their insourced system is more secure than the outsourced one)."

This is a correct statement on the technological level, but an incorrect statement on the business level. On the business level, it is not the email system itself that matter; if carrier pigeons were ferrying letters printed up on Guttenberg presses at the speed of light, businesses would use it. What matter on the business level is the contents of the email, that is the mission critical part of email. Email is the lifeblood of companies, having replaced to a large extent phones, couriers, postal systems, fax machines, and so forth. What is contained in an email is often of an incredibly sensitive or important nature. Furthermore, archived emails are a frequently a knowledge repository. There is a reason why my personal email archives reach back to 2000 (and would go back to 1996, if I did not have a lapse in judgement in 2000). My major disappointment with email is that the tools are still rather primitive for mining that data.

Any outsourcing situation has to acheive at least one of two goals: better value, or less cost. There are two ways to handle outsourced email: one is the way most small business do it, to have an external host, and they pick up the mail via POP3 and store it internally. The other way is to have an external IMAP or Exchange server offsite, and leave the data there. In the first situation, all you have outsourced are two TCP/IP transactions, one for SMTP and one for POP3. There is no added value here. And there is no reduced cost. If this is all your needs are, get the cheapest server you can find, load a Linux or BSD on it, and load qmail. For $500 in hardware, and the recurring fees for DNS and domain name registration, you are providing the same level of service to your company that the external provider is. Heck, your existing Windows server (nearly every business larger than 10 employees has one now) comes with an SMTP and POP3 server on it. So outsourcing this level of email service adds zero value and costs a lot more. Use those, if you don't feel like getting a second server. The second option also adds no value (again, you can put Exchange onto a server yourself) and costs more. Look at the numbers you quote from Centerbeam: $45 per user per month. In a company of 10 people, that is $5,400 per year. That is more expensive than a server with Windows 2003 and Exchange, plus a lot of data AND a backup solution! Go the open source route (didn't you guys just blog about Scalix a day or two ago?) and you have enough money left over to buy every employee an XBox 360 for a bonus. Gee, that doesn't seem like such a value at all, does it?

"What we offer to do is the hard work for people that they can't afford to do themselves."

I know this is you quoting someone else, so I am now arguing with them, not you. As I show above, anyone who isn't working on the US Government's budget can see the math problems here. How much does it cost to run your own SMTP/POP3 server? It takes what, a few hours to properly setup and establish a server using either *Nix with qmail or Scalix, or Windows with the built-in servers or Exchange? The Windows route is especially useful, because all of your account management is being handled via Active Directory, so that is one less system to learn. Is an outsourced server, regardless of what it is (POP3 or IMAP/Exchange) going to integrate with your in-house identity management system? I think not. What, you're going to set up a PPTP connection to their system, do a trust delegation to their AD system and yours, just so you don't have to manage separate usernames and passwords? Or would you prefer some awful webadmin system to go in and change stuff?

"That covers desktop management (anti virus, backup and restore everyday, 24/7 800# dial up helpdesk, server management, email management, VPN services, etc.)."

The in-house solution, except for 24x7 support, is still cheaper. Sorry.

"All a banker wants is more bankers and salespeople on staff. They don't want a Microsoft Certified Exchange Engineer on staff who is only available for one shift a day.   Even if you do run an Exchange Server with three shifts of engineers 7 days a week, they'll be advising you on best practices such as backup and restore. They'll say you need a Storage Area Network (SAN) and need to send tapes to Iron Mountain everyday."

This guy makes me forget just about every bad example I have ever given in a ZDNet TalkBack. Bankers have all of these things anyways. Bankers run a 24x7 database of millions if not billions of database entries where even a moment's worth of downtime can cost millions of dollars. This organization is going to be unable to support an additional few servers for email? But let's pretend he didn't say "banker". Let's pretend he said "small business owner". If having these hordes of MSCEs on staff is a problem for him, he may want to check out *Nix+qmail. I personally cannot vouch for Scalix (never used it, relatively new), but *Nix+qmail is a time tested, battle hardened system. It requires zero maintenance. None. Heck, Exchange, when properly configured, doesn't need any maintenance anyways. And at the end of the day, what good is his elite commando team of MSCE's going to do for a business owner if that business does not have someone on their end who can actually understand what they are saying and how to work with them? The only time his MSCE army is a decided advatnage is when their server starts behaving erratically and the problem is definitely on their end. If their software does something like that, where you need an MSCE to troubleshoot something that was working fine, then maybe that software isn't very good.

"[T]he point is that a leveraged model (where an outsourcing outfit spreads the infrastucture costs across more users than you can) is not only going to save you a lot of money, but headaces (sic) too."

Economics of scale is an idea I can buy into. But if they are leveraging economics of scale so well, why do they need to charge $45/user/month? Earthlink charges me $6/month for a POP3 only account. Is Centerbeam's economics of scale really so bad that they need to charge nearly 8 times as much for Exchange services? Maybe I need to reconsider those Exchange servers at my company, and put my new BSD server there to task with the email duties, the idea that Exchange is 8 times more expensive (with economics of scale, so it must be a few dozen times more expensive for our 5 person company!) than basic POP3 is total hogwash. Economics of scale distributes the cost of a Windows & Exchange license to something like 25 cents per user. So they're just ripping you off. Sorry, I don't like to be rpped off, and neither does my boss.

And what headaches are they really solving for me? Managing and maintaining an email server? It seems to me like they are giving me new problems, not taking away any existing ones. Let's make a headache list:

In-house:
- Hardware failure
- Network failure (immediate Internet connection and LAN only)
- User maintenance
- Initial installation and configuration
- Backup/restore
- Patching
- Security (95% of this is a subset of install/config)

Outsourced:
-/+ Hardware failure (should be be a problem if they are doing their job right)
- Network failure (their network AND immediate local Internet connection and LAN only, we've doubled our headaches)
- User maintenance (compunded by it not being part of my local authentication scheme)

So really, all I am giving up is responsibility for the hardware, backups, and maintenance. As I have already stated, email servers require nearly zero maintenance. I am patching my internal systems anyways, adding one more item to the list. Backups, again, I should be doing this anyways, what's one more server to have dump to tape/SAN/NAS? And for this I would be paying $45/user/month, which is much more expensive than a single Windows server in a 10 person environment? And if I have a large company, I can apply economics of scale to myself. An Exchange server can handle 1,000 users without a problem. Can my IT budget handle $45,000 per month for email alone? That's the cost of adding 6 MSCEs to my staff on a full time basis! And then I could have two of them monitoring my servers 24x7. Hmm, maybe I had better stop discussing Centerbeam's business model before his investors pull out now. Or better yet, maybe I should call those investors and ask them if they'd be interested in this bridge I have to sell, it connect Brooklyn to Manhattan...

"Raise your hand if you've used GMail, Yahoo Mail, AOL's mail or HotMail because you needed to send mail but couldn't get access to your corporate email system (for whatever reasons)."

I'll agree with you on this one. It's happened to all of us. On the other hand, this is an apples-to-oranges comparison. If I had the money to pay for Centerbeam's services, I would have the money for redundant email servers, in which case the only thing that would take me down would be a disaster (natural disaster, virus/worm, fire, etc.) or a complete network outtage, in which case my users would not be able to reach GMail, HotMail, etc. or Centerbeam's servers. So once again, this flounders on the cost issue. And also remember, I'm comparing Centerbeam's Exchange servers to in-house Exchange servers. If you compare a plain old outsource POP3 to an in-house *Nix server, the numbers are even more in favor of the in-house solution.

"Email systems, as it turns out, aren't that easy to run 24/7."

I have been doing it for years. The only thing that ever goes wrong are things that take down an entire server, or the whole network. Again, the price of in-house vs. outsourced makes this point hard to argue.

"Lastly, for a commodity system like email, what leverage do you have over your certified email engineer to keep the email systems up and running 24/7?  His or her job? Oh, that's what you want.  You'd rather spend time hiring and firing email engineers than making money for your company? Service Level Agreements (SLAs) are a lot easier to negotiate and enforce with service providers than they are during an employee's annual review."

Ah yes, my most favorite topic in the world! I guess I *do* have to rehash this topic. OK, time to brew a fresh pot of coffee!

First, some links to the extensive library of my thoughts on this subject:

* http://www.zdnet.com/5208-10532-0.html?forumID=1&threadID=16070&messageID=318442&start=-1

^^^^^^^^^ Number one most important post about the subject

* http://www.zdnet.com/5208-11406-0.html?forumID=1&threadID=16244&messageID=321399&start=-1

* http://www.zdnet.com/5208-11406-0.html?forumID=1&threadID=16278&messageID=322734

* http://www.zdnet.com/5208-11406-0.html?forumID=1&threadID=16324&messageID=324436&start=-1

* http://www.zdnet.com/5208-10532-0.html?forumID=1&threadID=16070&messageID=318442&start=-1

Wow! There's a lot of real-world, real-life, in-the-trenches experience in those links!

Now, to be fair, I don't always think that outsourcing is always bad, indeed, I have presented a compelling business case for it under certain circumstances: https://www.techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1921068&id=2926438

My direct response to Mr. Berlind's statement. Have you ever worked someplace and had a hard time with the customer, and the boss pulled you aside and said, "look, I know you're right and the customer is wrong, but we have to swallow our pride and give them what they want"? I have. That's the way companies work, as long as it is profitable for them. As soon as giving the customer want they want is no longer possible, they say "no". If a company cannot deliver on SLA (no measurability, no proof of failure, little enforceability, blah blah blah TPVs stink blah blah blah, just some self deprecation there at this late hour), you are tied to them for a contract. And what are you going to do? Spank the CEO for being naughty? It isn't like the underpaid, underexperience, fresh-from-working-at-McDonalds-but-know-how-to-setup-a-CounterStrike-server kids who fill Third Party Vendors are going to be held responsible if a customer is lost. I am a big fan of "The Buck Stops Here". TPVs always manage to find a reason why it isn't their fault, SLA wasn't truly violated, etc. For a TPV, "The Buck Stops Here" really means "Your Money Ends Up In Our Bank Account".

Employee annual reviews are a lot easier to manage than SLAs. I can directly measure and manage my employee's success. SLAs are notoriously difficult to manage. I have seen cases where a customer spent nearly as much time and money simply managing SLA than they did to manage the service themselves. That is rediculous. If you think SLAs are easy to manage and enforce, try an experiment: call your cable company to make a service call. You will get a 4 hour time frame where you must be home (heaven forbid if you're in the bathroom when they come by, "The Cable Man Knocks Once" would be a good film), and chances are they will be late anyways. If you're lucky, they'll give you some excuse about it. I remember working for a TPV and being instructed by managers to "invent" weather conditions that caused SLA misses, since poor weather was an SLA escape clause. How much money will you spend just hiring lawyers to 1) write the SLA 2) help you get out of the contract when SLA keeps being broken 3) sue to recoup the costs to your business when SLA is blown? If I have a bad employee who makes a serious goof, I can take them to task, or even fire them if need be and replace them with a more competant person. If SLA is blown, there is no recourse.

Finally, there is the issue of commoditization itself. Declining levels of quality are the largest result of commoditization, outside of pricing. Look at cars. The only reason why cars improved one bit after 1972, is being foreign competition started selling better cars at a better price in the 80's. Before that, American cars had become commoditized to the point where they were all equally junk. Now, American cars are often significantly better than their foreign counterparts, because they were forced out of commodity status. Consumer electronics is another example. Even though cell phones are cheaper now than five years ago, I spend more on them because their quality stinks. My year-old cell phone has worse battery life now than my friend's 5 year old analog phone. The worst thing that can happen, outside of a destructive monopoly, is commoditization. It freezes the desire to improve quality and replaces it with ruthless cost cutting to match the price cutting. When you cannot compete on features or quality because everyone is the same, then no one cares about it. Again, cell phones. At this point, consumers expect poor service, because that is the price we paid to save money. There are no "premium" or "luxury" carriers out there (well, Verizon is a bit pricey, and they do seem to have slightly better coverage, from my experience), but in general, cell phones stink. Why? Because with today's price slashing, no one can afford to innovate.

J.Ja

I just spent an hour writing a blog post. Only to have my connection drop as I hit "Submit". When the connection came back up, "Refresh" would not resubmit my entry. "Back" restored all of the form field entries EXCEPT the article itself.

This is why hosted solutions stink. This is why on-demand stinks. This is why thin clients stink. This is why AJAX stinks. Because a desktop application would have been performing an automatic save to disk every few minutes. And none of those other applications get write to local disk priviledges, because that would be a gaping security hole. It has been well over ten years since I used a desktop application that could lose more than a few minutes worth of work in the event of system failure, network disconnection, etc. It was five minutes ago that an online "application" did this to me. What a complete and utter bummer.

I have to remember to write these blogs in a plain text editor then copy/paste into this form to make this thing work right. It's bad enough that every character I type, every single keystroke causes JavaScript (save me from JavaScript, please, the interpreters are slower than my aunt's driving) to reevaluate the entire article and try to WYSIWYG it. which means that the more I write, the longer the delay between me hitting the key and the key affecting what is on my screen. All of this for a totally of 7 dinky buttons that do bold, italic, link, unordered list, ordered list, image insert, and "switch to code mode", and a drop down that lets me choose a block type for the current paragraph. This is stupid. How about if instead, the system have a little timer, and wait until I either key a command key for the function, click the function button, or have stopped typing for a few seconds to evaluate it. Whould that be too much? Is it necessary for it to re-download 14, that's right, FOURTEEN images everytime I type a letter? Thankfully I'm not on dialup, and as it is I feel like I'm trying to type via telnet on a 2400 connection. Heck, old BBS's on a 2400 modem would do a screen refresh faster than this junk.

AJAX, thin clients, etc. is is like going back to 1989 without the cool ANSI/ASCII art by ICE, The Jargon File, 256 color GIFs of women in bikinis, the DOOM 1 shareware installer, The Bastard Operator From Hell, Legend of the Red Dragon, 2600 magazine, Phrack, music in MOD format, and all of the other fond memories of my youth.

J.Ja

UPDATE (2/28/2006): I've posted a follow up to this article that presents positive ideas on how to change this situation.

Last night I read a great article (http://www.veen.com/jeff/archives/000622.html) from about 16 months ago about how lousy most open source CMS (Content Management Systems) packages were. While focused upon open source, the author made mention numerous times in the article and follow up comments that his compalints also apply to commercial CMS's.

Sadly, all of his complaints are still true, and apply not just to open course (or closed source) CMS's, but to about 90% of the web applications out there.

The simple truth of the matter is, web developers generally stink, not just as programmers, but as user interface engineers.

Over the past year-and-a-half or so, I have spent countless hours installing, trying, and uninstalling literally dozens of various open source CMS systems, without once finding something that works right, if at all. The best one out there, for my needs, was WebGUI. Too bad it broke the moment I tried to upgrade it, Apache, mod_perl, perl, or just about any other dependency it had!

Ten years after the Web revolution began in earnest, I still find myself using systems that are not much better than the systems I was using ten years ago. Part of the problem is the continual state of change within the Web development world. Every time a new language or framework or web server or technique (like AJAX) or whatever starts to gain momentum, all development on existing systems seems to halt, and everyone decides to do everything in the new system. By the time the new systems are about as good as the old ones, another technique, language, or whatever seems to come out. By the time the server-side Java and ASP web apps got to be as good as the CGI/Perl they were replacing, .Net and PHP came out. Now that .Net and PHP apps are getting as good as the Java and ASP pages they replaced, .Net 2.0 and AJAX are suddenly the rage.

The fact of the matter is, if all of that time had spent spent making things work in CGI/Perl (or whatever system had come first), I might have a chance of finding a quality web application.

AJAX is the current fad. It seems to be predicated on the fact that since Google Maps are so good, and they use AJAX, that AJAX should be used everywhere. Here's the truth:

• Any thing you do with AJAX also has to be written server side, because otherwise your application will not gracefully degrade on a browser without JavaScript or JavaScript turned off.
• The tools to write and debug JavaScript, ten years or so after it came out, are atrocious.
• Different Web browsers still do not agree 100% how to render HTML and CSS, nor do they implement JavaScript identically, forcing you to stick with either HTML/CSS/JavaScript that renders and executes identically or "good enough", or cut yourself off from a significant portion of visitors.
• People are using XML for something is simply was not designed to do. XML was designed to be used in such a way (in conjunction with XLST, XSD, and UDDI) so that systems could automatically discover and use each other. Thus, XML is written for the "lowest common denominator", which makes it extremely wasteful, in terms of resources needed to create it, transmit it, and consume it. People are using XML to pass data back and forth between different parts of their code (server-side to client-side, and vice versa) because it is quick and easy for them to code that way. The fact is, their applications are significatly slower, both server-side and client-side than they need to be because of this. It is much quicker, if you know the data format, to pass fixed length or delimited data back and forth, and nearly as easy to write the code. But because programmers are lazy, they would rather save 30 - 45 minutes of code writing, at the expense of creating scalability problems (just compare the file size and parsing time of XML vs. CSV to get an idea of what I mean).
• JavaScript interpreters are incredibly slow. I recently worked on a Web application where the customer wanted some customer validation done client-side on a 3,000 record, 3 field data set. The web browser would lock up for a minute on this. Actually sending the data to the server and handling it there was faster by a factor of about 10. I don't consider that "progress".
• HTTP is a connectionless, stateless protocol. In other words, it is pretty much so useless without a zillion hacks laid on top of it to accomplish what a desktop application can do with minimal, if any, coding. Look at the design of application servers. They need hundreds of thousands of lines of code, and basically all they do is receive GET/POST/etc. data, pass the appropriate information to an interpreter or compiled software, then return the results. In the process, they perform validation, maintain connection states (either via cookies or session ID's in the URL, both of which are hacks, when you think about it), and so forth. This is utterly rediculous. Desktop and server software is using Kerberos and other harded authentication management systems, while Web applications are sending plain text, occassionally protected with SSL. Is this really the best we can do?
• Web developers are still clueless about interface design. Half of the problem is that a Web developer is frequently forced to work with some sort of graphics designer who was brought up in the print world. Sure, bandwidth is cheap now. But with all of the hoops that an application server jumps through to process each result, a significant portion of the response time of an application is dependent upon how fast the Web server can build up and tear down each connection. An application that increases the number of HTTP requests, regardless of how small they are, is an application that won't scale well. AJAX goes from "make an HTTP transaction with each form submission" to "make an HTTP request with nearly every mouse click". I don't call this a "Good Thing". I call this stupidity. AJAX multiplies, quite significantly, the amount of data going to/from the servers, switches, routers, load balancers, the whole architechture. All in the name of "improving the user experience." At the end of the day, "user experience" is determined less by what "gadgets" are in the software, and more by "how well can the user accomplish their goals?" A slow application doesn't "work", as far as the user is concerned, regardless of the features it has.
• AJAX "breaks" the user's expected browsing experience. All of those cute XmlHttpRequest() statements don't load up in the user's web history. That means that the "Back" and "Forward" buttons don't work. If you're providing the user with an interface that looks like a normal Web page, with "Submit" buttons and so forth, breaking the browser's interface paradigm is a decidedly bad idea.
• And last but not least, JavaScript (as well as Java applets and Flash, for that matter) do not get local disk access. Their only recourse, if they want to save the progress of your work, is to periodically submit the work-in-progress to the web server.

Has anyone actually tried to make something basic even work right? It sure doesn't seem like it. TechRepublic's blog system is a great example of how even basic JavaScript can create a lousy user experience. With every keystroke (and mouse click within the editor), it re-parses the entire blog article. It also refreshes the simple buttons at the top. In other words, with each key I press, it is making 14 (yes, FOURTEEN) [correction: 28!] connections to a web server. That is patently rediculous. This should be re-written in Flash, or dumbed-down so it doesn't need to do this.

In fact, just about the only AJAX applications [addendum: I'm talking about just the AJAX portion of the functionality, I'm not particularly impressed by Google Maps' results] I have seen worth using is Google Maps and Outlook Web Access. The rest seem to make my life more frustrating than whatever problem they thought to solve.

Google's success is a great example of just how lousy web applications are. Google Maps took off like a rocket, because their competitors, despite having five, six (or more) years lead on them, had wretched interfaces. Mapquest hadn't seemed to become any more usable since Day 1. Yahoo was making changes, but came out with them after Google Maps did. Same thing for search. Sure, Google's results were (and still are, but less and less so) better than their competitors. But their interface is a joy to use [addendum: this is rapidly changing as Google becomes more of a portal]. GMail's biggest "feature" isn't even its interface, it is the amount of storage space. All of a sudden, you can use Web-based email with much of the benefits of a traditional POP3 client. Outside of the storage capacity, GMail wasn't much different from Hotmail or Yahoo Mail.

Google cleans up because they find a market where the current market leaders have a great idea, maybe even great technology, but provide a lousy user experience anyways. The fact that Google can break into an extremely mature market and blow it wide open is proof that Web applications, by and large, stink. Because even with five, ten years of market domination, the original players still provide a lousy customer experience.

And at the end of the day, even the most basic network aware dekstop application is easier, faster, more secure, blah blah blah, better in every measurable way than the best Web application.

J.Ja

Want to see who's next On the Soapbox? Find out in the Blog Roundup newsletter. Use this link to automatically subscribe and have it delivered directly to your Inbox every Wednesday.
Subscribe Automatically

What To Do About The Sorry State Of Web Development

A commenter on previous article (The Sorry State Of Web Development) make a good point: I put out a lot of negativity without offering anything constructive in return. Well, I?m going to make rectify that mistake.

Here is what I think needs to be done to improve the Web, as far as programming goes. I admit, much of it is rather unrealistic considering how much inertia the current way of doing things already has. But just as Microsoft (eventually) threw off the anchor of the 640 KB barrier for legacy code, we need to throw off the albatrosses around the neck of Web development.

HTTP

HTTP is fine, but there needs to be a helper (or replacement) protocol. When HTTP was designed, the idea that anything but a connectionless, stateless protocol would be needed was not in mind. Too many people are laying stateful systems that need to maintain concurrency or two-way conversations on top of HTTP. This is madness. This applications (particularly within AJAX applications) would be much better served with something along the lines of telnet, which is designed to maintain a single, authenticated connection over the course of a two-way conversation.

HTML

HTML is a decent standard, but unfortunately, its implementation is rarely standard. Yeah, I know Firefox is great at it, but its penetration still "isn?t there" yet. More importantly, while being extremely standard compliant, it is still just as tolerant of non-standard code as Internet Explorer is. If Internet Explorer and Firefox started simply rejecting non-standard HTML code, there is no way that a web developer could put out this junk code, because their customer or boss would not even be able to look at it. Why am I so big on HTML compliance? Because the less compliant HTML code is, the more difficult it is to write systems that consume it. Innovation is difficult when, instead of being able to rely upon a standard, you need to take into account a thousand potential permutations of that standard. This is my major beef with RSS; it allows all sorts of shenanigans on the content producer?s end of things, to make it "easy" for the code writers, which makes it extraordinarily difficult to consume it in a reliable way.

When developers are allowed to write code that adheres to no standard, or a very loose one, the content loses all meaning. An RSS feed (or HTML feed) that is poorly formed has no context, and therefore no meaning. All the client software can do is parse it like HTML and hope for the best.

JavaScript

This dog has got to go. ActiveX components and Java applets were a good idea, but they were predicated on clunky browser plug-ins, slow virtual machines, and technological issues which made them (ActiveX, at least) inherently insecure. The problems with JavaScript are many, ranging from the interpreters themselves (often incompatible interpretation, poorly optimized, slow) to the language itself (poorly typed, pseudo-object oriented, lack of standard libraries) to the tools to create it (poor debugging, primarily). JavaScript needs to be replaced by a better language; since the list of quality interpreted language is pretty slim, I will be forced to recommend Perl, if not for anything else but its maturity in both the interpreter end of things and the tools aspect. Sadly, Perl code can quickly devolve into nightmare code, thanks to those implicit variables. They make code writing a snap, but debugging is a headache at best, when $_ and @_ mean something different on each and every line of code, based on what the previous line was. Properly written Perl code is no harder to read and fix than JavaScript. Perl already has a fantastic code base out there.

Additionally, the replacement for JavaScript needs to be properly event-driven, if it is to ever be able to work well in a web page. Having a zillion HTML tags running around with "onMouseOver()" baked into the tag itself is much more difficult to fix (as well as completely smashing the separation of logic and presentation which I hold to be the best way of writing code) than having TagId_onMouseOver() in the

So here I am, checking out the Excel spreadsheet that my customer is using to compare it to what I am currently working on. To see if they made any changes to the ODBC queries, I popped it open in a hex editor. Guess what? Not only were the queries there (as I expected), the connection string, INCLUDING THE PASSWORD was there, in plain text! Unbloody real.

J.Ja

[addendum 3/5/2006] Just hand me the "Putz of the Year" award. There was a patch out there for Partition Magic which removed the error code I kept getting; it was blaming its inability to copy on a bad file system, when in reality it itself was the problem. Also hand our a "Putz of the Year" award (dated 2001) to the person(s) at PowerQuest that allowed that bug to escape their QA process, and to take quite a number of months (a year?) to fix the problem to their software.

I've been struggling with a bad hard drive for a few days now. Five, to be more exact. Not the "struggling" where I don't know what to do or how to replace it, but struggling with various utilities to get it to copy the data over to the new drive that came on Wednesday (today is Sunday). So far, I've tried the Windows XP Install CD (XCopy so graciously will not copy most of the files, even in Safe Mode), Partition Magic (keeps finding errors with the drive that CHKDSK isn't finding/fixing), Maxtor MaxBlast, and Western Digital's Data Lifeguard. What does this have to do with floppies?

All of these tools, except for the Windows Install CD and Maxtor MaxBlast, let me create a "Recue Diskette" of some sort, but don't have the option to burn this diskette to CD! Computers have been coming without floppy drives standard for quite a number of years, but the utilities haven't caught up. If it was a matter of simply hooking up a floppy drive, there would not be a problem, I have a spare floppy drive on the shelf just for this type of situation. But the sad fact is, the motherboard on the current PC simply does not have a connector for a floppy cable! I bet 95% (or more) of people who purchased a computer from an OEM (HP/Compaq, IBM, Dell, Gateway/eMachines) during the last three or more years are in the same boat that I am.

Without being able to have something that works with its own boot loader, this operation just does not seem to be working. For whatever reason, upon booting with the new drive, certain things are not working right; my Windows toolbar is lacking the address bar, and more important, Office 2003 just isn't working right. It requests a reinstall, but the installer/uninstaller says that it is an invalid patch file. I tried the fix from Microsoft, and it worked, but with those two really obvious errors in the disk copy, I really did not feel like taking my chances and sending the original drive back.

It is just a bit frustrating that system utility makers (especially Microsoft, who helped puch boot-from-CD for Windows installations, as well as pushed OEMs to ditch floppies) don't take into consideration how many people simply lack a floppy disk. I'm sitting here, knowing that all I need to do is a standard Windows backup, create an Emergency Repair Disk, then run the Automated System Recovery, and I can't.

Have I ever mentioned how amazed I get by the lack of conseration on the part of developers for the users?

J.Ja

Yes, this is another insentive, inflammatory "Programmers Stink" post.

Why?

Because THEY. MAKE. MY. LIFE. MISERABLE.

Today's problem?

Visual Studio 2005.

[addendum: 3/16/2006] A few commenters have made it clear that I didn't explain the problem very well. I am not working with SQL Server. That has excellent management tools. I am working with SQL Server 2005 Express. It is the same database engine, but works off of files and is designed to be able to be installed onto a client when you install the software, this way you don't need to worry about having the customer have a full database installed on a server. SQL Server 2005 Express has absolutely ZERO management tools outside of Visual Studio that I have found. No other tool that I am aware of "knows" how to access a SQL Server 2005 Express database, unless I were to set up an ODBC connection to it (I haven't tried it, but it may work). The point is, I followed the directions in the help files, and they were incredibly difficult to use (this is the first time in the nearly 20 years that I have used computers that I had a problem with COPY/PASTE), and the software did not make it easy at all. Especially frustrating was the "You have an error!" box that popped up for each and every error without explaining what the error was or providing a way of stopping the process causing the error without killing the entire process. I want to see you click "OK" 24,000+ times and tell me that you're working with smart software.

I'm writing a small application and I want to use the SQL Server 2005 Express database engine. I have the data elsewhere, in a FoxPro table, that I want the application to use. I exported the data to CSV. Visual Studio won't import that to the SQL Server 2005 database. FoxPro didn't work either. Excel didn't work. Text file didn't work. In fact, there is no "import" feature at all, unless I want to write Transact-SQL code. At the end of the day, Visual Studio won't copy a table from one data source to another. I can't do a "SELECT INTO" between data sources.

What do the help files say? Open the data and do a copy/paste. So I tried that. For hours, it was just trying to do one row at a time, and paste the contents into one cell. Eventually I figured out how to get it copied right. Why do I need to figure out how to "copy correctly"? Am I missing something?

The piece of garbage decided to have an error on one column. Instead of telling me what the error is, it decided to be vague. To make it worse, it pops up an error on every single row that I'm pasting. All 24,000+ of them. It was faster and better to trash the whole Visual Studio session. Your "error handling" should NEVER make the user's life worse. The joke is, Access does this well, it does the import, then create a second table with the errors. Simple. Elegant. Quick. Useful. Non-annoying.

To all of you lazy programmers, stupid programmers, and other jerks who never actually thought about how your users would use your lousy software: I HATE YOU. I want to find where you live and cause you as much aggravation as your products cause me. For every hour of my life that a computer has saved, bad programming and poor user interface design wastes two. I want to find the moron who wrote this, go to their house, and waste 8 hours of their life, maybe force them to watch Bloodsucking Freaks 4 times. EIGHT HOURS OF MY LIFE HAVE BEEN LOST TO WHAT SHOULD BE A 5 MINUTE TASK. I am eternally grateful that I get paid salary and not per-project, I'd be eating out of Dumpsters at this rate...

And the sad part is, this problem has caused me significantly less pain than Google's Customer Dis-Service Department has recently.

I swear, I want my next job to be 75% done with paper and pen...

J.Ja

This is a response to a comment on a previous article: "Yeah, why can't the software do what I want it to do, rather than what I tell it to do...."

<sigh>

This is one of those cases where I get mad that computer communication doesn't carry vocal inflection. If you're being serious, then you truly understand what my gripe is. If you're being sarcastic, it's exactly that attitude that is the problem.

The user should not have to adapt to the software. The software should adapt to the user. The user pays to use software in order to gain productivity. The software designer is not paying the user. If your software is not easy to use, the customer can always go get someone else's software. If the user experiences any pain while using your software, whether through your poor design or their own ignorance or incompetance, someone else will be more than happy to write software that helps that user and take their money away from you.

I recommend that anyone who writes software that interacts with humans try using Perl for a few months. The whole language has "does what you mean, not what you say" as an explicit design goal. As a result, it is one of the most pleasurable languages to work in that I have ever used. The language itself vitually never gets in your way. It is such an incredible world of difference. .Net languages, Java, and other langauges I have worked with (recently) have only been able to keep up with Perl in terms of the ability to rapidly develop software because they have such gigantic libraries. As languages in and of themselves, they are lightyears behind.

Why am I mentioning all of this here?

Because of the concept of "gee, well you're the one who clicked on the wrong thing." Wrong. Unless the user makes an accident, such as a typo or a mis-click, the user has always done precisely what they thought would accomplish their goal. ALWAYS. To beleive otherwise is designer hubris, an attitude that needs to be eradicated from your thinking if you ever want to be a great (or even good, let alone employed) programmer, engineer, or any other designer.

Here's an example: propositions on ballots. If you have ever lived in a state that does these, you know exactly what I am talking about. You are presented with one to five paragraphs of dense legal text, and end the end, asked to vote "yes" or "no". Here in South Carolina, a proposition barely passed that was heavily demanded. Exit polls indicated that it had won overwhelmingly. What happened? A significant number of portion of voters simply did not understand which of the two choices they were presented with would actually vote for the proposition. I know that I re-read it three or four times, and still was not sure if "Yes" would vote for the end result that I knew I wanted. Post election polls that asked what choice people made, and compared it to what result they wanted showed this. The ballot was poorly designed.

Software is all too often designed by people who have this designer's hubris. If your software reacted badly to a user's input, it is because you failed to perform proper error handling. More importantly, you failed to comprehend your user's needs. Web forms are notorious for this; instead of anticipating that a user may put dashed or spaces (or no delimiters at all) into a credit card or phone number entry field, and stripping out non-numerics, then trying to process the card, they limit the user's input. The user doesn't find out that the field is limited to 16 digits, then they need to go back, remove the dashes or spaces, then finish entering the credit card number. Frustrating! Just make the field bigger! More importantly, those dashes/spaces help the user ensure that the numbers were put in correctly. It takes but one line of code to strip the junk characters out and reformat that credit card number (in Perl; other languages need a zillion lines to make and use a regex object...). Either way, five minutes of programming will make your users happier and provide you with more accurate data input.

Instead, we get websites that kick you back with an error message (often hard to find the error message on the screen, to make it worse). That's designer hubris in action.

Let's review some of the comments the previous article received to see some of this designer hubris in action:

"I know it's not much consolation when you have to use specific proprietary applications for work, but you might try using more open source software. For the most part, open source software is developed by people who want to use it, not by people who are just being paid to produce something for others." - apotheon

Sadly, much (if not most) open source software has even worse user interface design than proprietary/commercial code. All too often, the answer to even a simple item is in the manual, not the interface. A user should never have to read the manual for anything but the most complex tasks. How to accomplish simple, day-to-day tasks should be intuitive and easy. Too often, I have found using open source software to be like using a website where many of the pages aren't linked to, but need to URL typed in manually.

"You have to figure out how to copy correctly, because like everything in life, if you don't do it correctly it won't work, pretty obvious really. This idea that somehow the system should figure out what you're trying to do and how is ridiculous." - gbently

Wrong answer. When someone has table data in the clipboard, and is pasting into a table object, it is fairly obvious that the user is trying to populate the table with data, not an individual cell. If the program is in doubt, it should simply ask "what are you trying to accomplish, how can I help that to occur?"

"IMHO Visual Studio is for programming, not database manipulation." - dancoo

I agree 100%. To load the data into MySQL, I used the LOAD DATA statement. If I wanted it to go into SQL Server 2000, I would have (probably) used the Import Wizard. If I wanted it in Oracle, I would have used sqlldr.exe. But I wanted it in SQL Server 2005 Express, which has no management tools that I could find. I followed the directions in the help system. They said to use copy/paste. The database tools in Visual Studio aren't so hot. But they are still better than nothing, much of the time, and in the case of SQL Server 2005 Express, they seem to be the only thing going.

"LMFAO an even better question is why don't you use php5 or python or something like that where YOU CAN ACTUALLY PROGRAM YOUR OWN ERROR MESSAGES! OMGZ! and use it fast and learn it easy." - mindilator

Wow, this one had me laughing. I am not quite sure how me using Visual Studio compares to me using PHP or Python. The last I checked, I was trying to load data into a database; what language I was writing my software in is 100% irrelevant. Even if it was relevant, this poster makes a really stupid assumption: that I had much of a choice in my language. This person is obviously trying to make me look stupid, saying that I am too stupid to use PHP or Python, and that I'm a fool for using Visual Studio. What if I told this user that I was using IronPython for Visual studio, or Perl.Net? Would that make them happy? Probably not. It also shows this person's ignorance. Visual Studio does a lot more than write web applications. In this case, I am writing a desktop application. This is why I was using SQL Server 2005 Express in the first place. PHP and Python aren't too much help when writing a Windows desktop application!

"just stop blaming others for not building an IDE that reads your mind." - mindilator

This is actually one of the things that a good IDE does. A good IDE, for example, when debugging, doesn't just say that an exception occurred; it shows me the error. That's a form of mind reading, it knows that I want to see the error that occured. More to the point, I was simply following the instructions. My intial thought was to find either an import wizard or an import utility. The documentation did not mention either of those. Most importantly, a well designed system does exactly what I need it to do. If I need to treat my computer like a newborn puppy, I might as well give up now.

"i could easily moan that his lack of comments wasted two days of figuring out what implements what, but that's just the breaks." - mindilator

Not only could you, you should be concerned about his lack of comments. You wasted two days of your time working with his system. If he had spent a few hours writing some basic documentation, you would have saved a lot of time. Furthermore, what if he had chnaged the function of a parameter, but not the name? Without that documentation, you would need to inspect his code line by line to see what each parameter is sued for. Additionally, the process of writing comments serves as a code review. Many times, it is during the comment-writing phase when it becomes obvious how to streamline architechture, add in additional functionality, and so forth. Good and great programmers write comments. Bad and average programmers don't. I'm not saying that writing comments is enjoyable; it really isn't. But the lack of comments is disturbing, particularly if he was aware that this was code that other people would be working with.

"you really want a job that's 75% pen and paper? what's the other 25%, using an abacus?" - mindilator

I'm actually glad you mentioned the abacus. Many abacus users are significantly faster at performing math than many computer users. What does that tell you? Yes, I want a pen and paper job. When I am programming, I spend about 50% of my time not writing code, if not more. I spend a good portion of time performing planning on paper. I spend time talking to my customer or end user determining their needs. I spend time sketching potential screenshots and showing them to others for critque and input. By the time I'm actually sitting down and writing code, it is a fairly quick and trivial process. It doesn't take much time to write the code itself, and debugging is typically fairly quick as well, assuiming I have access to a quality debugger. Things like breakpoints and watches (vs. "print 'Executing line 678, the value of sFileName is ' . sFileName;") cut debugging time by about 75%, and often help you find problems before they even occur, because you get to watch the logic you wrote in action.

The point is, the user does not pucnh themself in the head. A user who "clicked the wrong button" and wiped out their data is the victim of a bad interface design, not an idiot. Users don't say to themselves, "gee, I want to wipe my hard drive", they do these things because the design stunk. It is my beleive that user interface stinks, because many programmers simply do not pay close attention to the needs of their users, do not test with real-life users, and have a bad attitude towards users. It's time the designers started paying better attention. Look at Google. Google went from a nobody to a market giant, by simply helping the user accomplish their goals (searching the Web for data) better than anyone else. They did this by providing a significantly better user interface, and by taking the time to write a better search algorithm. They identified the user's need, and wrote software that met that need while simultaneously working the way the customer needed it to, instead of making the user work the way the software did.

J.Ja

I've been blogging a bit lately about poor user interfaces and the developers who create them. Sometimes, the problem with the end result of software is caused by the initial project specifications. Here's are of some of the major pitfalls that can occur in any project.

The initial project specifications are not correct

All too often, the user has an idea of what they want in mind at the beginning of the project, and that vision is completely different from what they want by the end of the project. A project that takes a long time to develop is sure to not be finished before the business rules or needs change. Another problem that I have seen time and time again, is that until the user gets their hands on a working version of the product, they do not get to find out if their initial perceived needs are their actual needs. At the beginning of a project, the user may only want a few options, but once they see the power that the software is giving them, they want a lot more options. Or to go the other way, they ask for a thousand options or ways of doing slightly different taks, but find out that in reality there are only a few features they actually use, and the rest are waste.

I combat this by providing sketches and mock screenshots throughout the development process. I try to involve the user as much as possible, because I have found that it is always better to spend an hour giving them a prototype (even if none of the widgets work) that let's them get an idea of how things will work, than it is to spend weeks or months writing code that they don't want.

Users seem to think that low-output projects are low work

This is one of my favorite user misconceptions. They seem to think that the number of results directly impacts the length and difficulty of the development process. Something happened today that is an excellent example of this. I am currently working on a system that ties maps to the user's sales data and sales representatitve data. One of the people in my company sent me some information to think about using "as a demonstration." He seems to think that it should be easy or trivial for me to create results based on this data, because the data set is significantly smaller than what we normally work with. Wrong! It is no more difficult to program to handle 1 million rows of database data as it is to handle 100 rows of data. It is almost always the number of columns and the complexities of the data transformations that make a project more or less difficult. I frequently have customers ask me to run a report ad hoc that will only generate a few "bottom line" numbers. They think that because they are asking for only one row of data that this is a trivial task. It is just as much work to produce the "bottom row" numbers as a full report, because the full report needs to be made to generate the bottom row of it anyways.

The only way to beat this one is through educating your users. But there is a way to be nice about it, and give them a value add as a bonus. For example, in the bottom line number scenario, I go back to the user and say to them, "listen, to generate those bottom line numbers, I need to do a full report anyways. Would you prefer to get the full report while I am at it? It will take only a little bit longer to be able to provide a full report to you, and then you will be able to have the individual numbers as well." This way I have impressed upon them that while the amount of output they are asking for is low, the amount of work is the same as a high-output request. In addition, I am giving them the option of having information that they might not have asked for because they thought it would be too much additional work to produce. The users are very happy with this approach, and after a certain point they come to you and say "would it be much harder to do XYZ versus ABC?"

The project specifications do not match the users' goals

This one is always a problem, particularly when the people performing the work are separated by one or more degrees from the users. In fact, like a game of "Telephone", the more layers between the developers and the users, the worse the problem gets. For example, I recently had a user who needed to get names and addresses from an Excel spreadsheet, insert the information into some text to generate a form letter, and be able to print those letters at Kinko's. This was their actual goal. My project specifications were "take this Excel spreadsheet, insert these values into the text already entered into these cells, then save the individual sheets to PDF format, and make sure they look good." Between trying to take flowing text in Excel and making it "look good", and producing PDF output, I could tell that someone had given me project specs that were not properly aligned with the user's needs. They had given me project specs that matched what they thought would be the best way of performing the task, not the task that the user actually wanted to be done. I dodged this by asking to know what the user had actually asked for. Once I found that out, the project was much easier - it took a few hours as opposed to a few days.

Whenever you are given project specs, you need to get access to the user. In some companies, you may need to demand it. Many project managers get the attitude that you, the developer, needing to speak to the user reflects poorly on them as a project manager. That may be so, or it may not. But at the end of the day, you are going to be writing the code, not the project manager. It is in everybody's best interest for your project specs to accomplish the user's goals, not to fulfill a PM's vision of how you should accomplish what they perceive the user's goals to be. A PM who refuses to allow users to interact with the developers is a bad PM. Currently, my customers have my direct number. They take their requests directly to me, and they love the "self serve" aspect of it. Does my boss get involved? Sure he does, he needs to make sure that one customer's needs don't interfere with my time on other projects, that they are aware of what is within scope and out of scope of the contract, and so forth. But at the end of the day, the user is getting exactly what they need, they are in control, and they are delighted to spend the money because we are doing for them what their own staff cannot or will not do.

At the end of the day, the smaller the gap between the user and the developer, the better the product will be in terms of meeting the user's needs and expectations. Good communications between the suers and developers, while being sometimes difficult, tend to save significant amounts of time and frustration. It is always better to spend an hour talking to the user, even if they are some empty-head sales manager to get to know their real needs, than it is to spend three months designing and developing a proejct, only for the user to never actually use it, or reject it outright, because it doesn't actually do what they need, even if it does what they asked for,

More to come on this topic over the next few weeks...

J.Ja

I want to send my thanks out to all of the readers and commentators who have been spending so much of their time to post comments, debate, criticism, and more on my most recent string of blog posts. You guys are the greatest, and I think it is really awesome that you are putting as much, if not more, time and effort into discussing this blog as I spend writing it. My recent post regarding the relationship between users and developers has started a great thread of comments. One of the comments, from gbentley, provoked quite a bit of thought in my mind:

"One of the respondents made the comment that software only exists to make tasks easier. Disagree vehemently. There are whole ranges of applications that have only become possible due to cheap fast computers. They weren't done at all before. Simulation, various kinds of graphics, deep analysis of histroic data, etc." - gbentley

This quote contains two commonly accepted ideas. The first is that "software only exists to make tasks easier." The second idea is "[t]here are whole ranges of applications that have only become possible due to cheap fast computers."

Are these two ideas actually in opposition? Are either of these ideas even true?

"Software only exists to make tasks easier."

I will call this ?the assistant argument?. This one is so close to being a truth with no questions required of it. But it has a really big problem: the word "only". Without "only", this is a "duh" statement, of course software exists to make tasks easier. But to claim that software's only purpose is to simplify tasks, without enabling new tasks? That's a pretty bold claim. But it is easy to see why people hold this idea. Email replicates the postal system or letter and packages, spreadsheets replicate ledger books, word processors replicate typewriters (which themselves merely replicate paper and pen), and so forth. Indeed, with the exception of software that are directly related to computers, there are very few pieces of software which do not replicate an existing task that can be done without a computer (the qualifier is in reference to things like development tools or backup software; without computers there would be no need to write software and nothing to backup).

"There are whole ranges of applications that have only become possible due to cheap fast computers".

I call this idea ?the enabler argument?. This claim seems to be much more reasonable than the first one does. It does not deny that software simplifies many tasks, but simply states that software and computers allow work to be done that could never be done before. This claim has two possible variations. The literal variation boils down to ?there are certain things that simply cannot happen without a computer.? This is pretty hard to prove. Even in the examples given by gbentley are all things that someone with amazing patience and/or dexterity, or a huge team of people, could do without anything more than paper and pencil. From there, we have the pragmatic variation: ?there are certain tasks, that while able to be performed without a computer, that it is unrealistic to expect them to be done without a computer.? gbentley?s examples, I believe, fall firmly within this argument, and quite nicely at that.

It is actually impossible to evaluate either of these claims without an understanding of what a computer is.

For example, I could state, ?a ledger book is a form of computer, albeit a mechanical one; it is a mechanical database where all C/R/U/D (Create/Read/Update/Delete) is performed by the user with a pencil, and all calculations must be performed by the user, but it is a database all the same. With that statement, we have essentially said that even a checkbook is a computer, and more or less, even the most basic accounting is impossible without either a computer, or superhuman memory and math skills.

Or one could interpret ?computer? to mean any electronics device using a binary storage and logic system to represent arbitrary data. This would be more appropriate; anything that we accept as a ?computer? is a binary device. Or is it? Scientists are working very hard to develop computer that make use of quantum states, where the answer set is expanded from ?on? and ?off? to include ?maybe?. Other scientists are working on computers incorporating organic matter, which requires an analog interface. Even a hard drive is hardly a ?binary? device. It records magnetic states. Magnetism isn?t an ?on? or ?off? property, it is a relative property. A hard drive is really reading the relative strength of tiny magnetic fields. If a field has more than a certain amount of strength, it is considered ?on?. So it is hard to say that the use of binary storage or processing is what qualifies a device as a ?computer?. We could also try to make a derivative argument, which is that a computer needs to have transistors, but again, there are established computing devices without transistors, with more on the way.

Luckily for us, The Enabler Argument makes it clear what kind of ?computer? it means: ?fast and cheap?. That rules out anything below, say, a four year old PC. A checkbook, abacus, etc. should be unable to perform any task faster than a piece of modern computer hardware, given the right software. And therein lies a major problem. The software.

This takes us back to where the whole argument began in the first place, the relationship between software creators and software developers. We can safely ignore the folks who think that we are on the verge of having the group groups suddenly overlap. I?ve been told countless times that ?Application XYZ is going to let users create their own code without a developer needed, with simple drag ?n drop interface (or ?plain English queries? or ?natural language queries? or ?GUI interface? or ?WYSIWYG interface?, or whatever)!? Luckily for me and my career, this magic application has never been written, nor do I see it on the near horizon.

For one thing, it would require an entirely new way of writing and maintaining computer code. I have been thinking about this quite a bit lately, but I am unable to share my thoughts at the moment for a variety of reasons. Hopefully I will be able to share them in the near future.

Another problem is the way developers go about thinking about the concept of how users perform their tasks. This also relates to the problem of user interfaces. Developers ask users certain key questions when writing code to help them translate the users? business needs into Boolean logic and procedural code (call it what you will, but even event driven and OOP code is actually procedural code, once the event is fired or method executed). Developers ask questions like:

If this value is higher than the threshold you have laid out, should I reduce it to its maximum allowed value, or produce an error message?

Is this data going to be in a list or a spreadsheet format (when a developer says ?spreadsheet? to a user, they really mean database, but users understand the idea of spreadsheets better than databases)?

Under what circumstances do I need to highlight this data in the output stream?

These are questions that are needed to be asked to code business logic, and there is nothing inherently wrong with them. But where this model of specification creation fails, is in not understanding what the users? actual needs are. We are finding out how they do their job, but not why. A great example of this is the Microsoft Office Macro Recorder. Sure, the end result may be a bunch of VBA statements, so you could claim that the MOMR turns ordinary users into developers. But look at the code it produces; it creates code that replicates every stray mouse click, key pressed, etc. It replicates how the user does their job. This is why the MOMR code is so useless for all but the most trivial tasks. It does not have any understanding of the user?s intentions. If the user selected a particular column and ten made it bold, the macro simply says ?select column C and then make it bold?. It isn?t even clever enough to reduce that to ?make column C bold? and eliminate the selection aspect of it! Running that macro while the user has another column selected loses the user?s prior selection. A developer will re-write the code appropriately. But even then, the software has no idea why the user made column C bold. This code will always make column C bold every time it is run, even if column C was the correct column to make bold when the macro was run. If that decision was based upon the contents of the column, or maybe the nearby columns, the macro does not accomplish the user?s goals in the least.

This is where the developer fits is. The developer sits down with the user and asks question like ?under what circumstances do we make column C bold?? Even better, the developer will ask ?under what circumstances do we make any particular column bold?? The best question to ask, though, is ?why are we making columns bold?? That is when we transition from programmer to me ?how? and start programming to meet ?why?. There is an amazing thing that happens at this point in the conversation: the developer may learn at that point that the user?s ?why? is not best served by the ?how? that was requested in the project specifications. The user may say, for example, ?well, we want to column bold, because any bold column indicates poor sales numbers.? The developer could turn around and say, ?it sounds like what you need out of this is a method to identify underperforming accounts, would it be better if we created a second tab on the spreadsheet that contained only the underperforming accounts along with the relevant information to help you see why they are not doing well?? All of a sudden, our job just became a lot more difficult, but at the end of the day, we have a much happier customer.

It is at the point when software ceases to be written to replicate the how and fulfill the why that we actually answer the questions that started this article.

Up until relatively recently, software creation was merely a how oriented task. You could throw as many new languages and pieces of hardware as you wanted at the situation, but that is where we were. Only recently has software started becoming a why oriented task. When software is only written to meet the ?how?, then we end up with software that only makes existing tasks easier. When we write software to accomplish the ?why?, we are writing software that allows things to be done that could not have been done (meeting either the literal or the pragmatic variations) through the use of software. The user?s why is not to slightly alter the color code of some pixels. That?s the how. The user?s why is to remove the red eye from a digital photograph.

When we begin to address the why, we write great software. Bad red eye removal software will turn any small red dot in an image into a black dot, after the picture has been taken. Good red eye removal software will hunt only for red dots in areas that are potentially eyes and turn them into black dots. Great software will first find a face-like shape, then search for eye-like shapes, and then turn the red dots into black dots. The best red dot removal software doesn?t even need to exist on a computer; it would be in the camera! The camera would alter the flash (length, brightness, maybe have a few different flashes that use different spectrums) to use as little flash as possible and maybe even do something to prevent the red eye from even making it into the image file, let alone reach the lens.

That?s just one (probably not great) example of what I mean. And this is where we are seeing the user/developer gap. The developers are simply too far away from the user?s, in so many aspects, that they have a very hard time understanding the why of the software. I am certainly not claiming that the develop needs to know how to do the user?s job (it certainly helps though!) or that we find a way to make tools to allow user?s to generate software (impossible to do well at this point). I am saying that developers need to work to determine the user?s why as long as the how, and figure out how to code to the why as opposed to the how. Some developers (including myself) are lucky enough to be writing software that will only have a handful of users. We are able to have these conversations with our users. Imagine trying to write a word processor that meets the potential why of every potential user! Some users use word processors as ad hoc databases like grocery lists. Others use it to replicate typewriters. Others don?t even create content, they use a word processor to review and edit content. And so on and so on. From what I have read about Office 12, I think Microsoft has the right basic idea: make the interface present only the options that are contextually relevant to what the user is trying to accomplish. But it still isn?t anywhere near where it needs to be. It is still working with the how.

File systems are another great example of a system that meets how but not why. When computers were fairly new, the directory tree made sense. The information contained within the directory names and file names themselves was a form of metadata. ?Documents/Timecards/July 2005.xls? is obviously a spreadsheet from July 2005 that is a timecard document. This met the how which was the filing cabinet metaphor, that was how these things were done for 100 or so years prior to the computer. The why was ?identifying and finding my data?, which is what the directory tree structure does not accomplish very well. In reality, the user would be much better served by a system that would assign certain properties such as ?Timecard?, ?Document?, ?Spreadsheet?, ?pertinent to July 2005?, etc. to a file object. All of a sudden, we can do away with the ?Timecard? directory, and have a ?Timecard? group that contains all documents marked as timecards! That is a very powerful change indeed.

Again, all too often our design and development process gets sidetracked by how and not why. How many times have we as users said something like ?I think a drop down box for that information would be great?? We think a drop down box is best, because that?s how we saw it done somewhere else for something similar? not knowing that there may be a much better interface widget that we simply were not aware of. As developers, how many times have you heard a customer dictate architecture details to you to the point where you wonder if it would be easier to just teach them a programming language and let them do it themselves? This is because the user/developer conversation is focused on how. As a developer, in the most metaphoric sense possible, it is my job to translate your why into a software how. That is it. Writing software that accomplishes what you need to do better than how you are doing it now. And that is the crux of the problem. If the user?s current methods are so great, why are they asking me to write software for it? When we begin to address the why instead of the how, we are no longer replicating what may be an inefficient process (or taking what is a great process when performed manually, but inefficient as software), but helping to create a whole now process appropriate for the medium.

A large part of the problem, from my viewpoint, is that programming languages are still how oriented. There is no why in writing software. Some languages are a bit better than others. Perl, for example, with its ?Do What You Mean, Not What You Wrote? attitude is a better one. C is a very bad one. C will be more than happy for you to alter a pointer itself instead of the bits it points to, when anyone reading the code would understand that you wanted to alter the code itself. This is at the heart of my complaint with AJAX. People are using AJAX to replicate rich client functionality, with tools that were simply never designed to do that. Of course it will be sloppy. I won?t go into the technical details at this time, I have been over them a number of times already. But AJAX, and many other Web applications are replicating what is frequently poor rich client how to begin with, and compounding it by inventing a why that does not exist. The user does not use a word processor because they need to be able to type from any computer with an Internet connection. Thus, a Web based word processor does not address any actual why, but creates a bad one, then replicates a horrendous how in the process, using bad tools to boot.

I have a lot more thoughts on this topic, and what changes need to occur for developers to become empowered to address the why while not sweating the details of how. Stay tuned.