All Posts in Technology

|In: Industry Commentary|Last Updated:

The redoubtable Carl Reiner asked Mel Brooks’ 2,000 Year Old Man what the greatest invention of all time was. Brooks replied, “Saran Wrap.” It’s clear, you can wrap a sandwich in it and see if it’s still good …

When, in protest, Reiner asked about space travel and modern medicine, Brooks answered, “Oh, those are nice too.”

That pretty much describes my level of excitement for 802.11, the impending standard for wireless LANs Chad Dickerson writes about so enthusiastically. It isn’t that 802.11 is a bad thing. I just don’t see this as being worth a CTO’s time and energy.

LANs are infrastructure. Infrastructure is important but it isn’t strategic from a business perspective unless it enables a fundamentally new way of working. For example, 802.11 would be business strategic if a company used it to organize around ad hoc teams instead of a fixed organizational chart. Just imagine every employee with a golf cart instead of a cubicle, equipped with an 802.11-capable laptop and a wireless IP-telephony-enabled telephone. Instead of remodeling every time the company reorganizes, employees could park next to today’s manager and co-workers.

Infrastructure also isn’t strategic from an internal IT perspective, unless, that is, it lets you shift a significant share of the budget from maintenance to creating new business value. But even if 802.11 were fast and sturdy enough that it could eliminate LAN wiring altogether, it wouldn’t have a big enough impact to qualify.

And it isn’t. 802.11b, the more practical of the two (it costs less and has a 100 meter range) runs at 11 Mbps. 802.11a runs faster — 54 Mbps is possible under ideal conditions — but is limited to 20 meters.

Since the payload we deliver to the desktop continues to become bulkier, the 100 Mbps switched, dedicated, noise-resistant bandwidth that’s now what you get at dirt-cheap pricing in the wired world still looks a lot more attractive than wireless, especially since the placement of wireless transceivers is as much black art as it is engineering.

Don’t get me wrong. 802.11 has its place — in niche situations like trade shows where fast set-up and take-down are the dominant requirements for a network, and home networking where pulling cable means punching holes through walls and ceilings. And one of these years, a successor to 802.11 just might perform well enough to become the dominant network topology in most companies.

Even if it does, it will still be infrastructure. Most CTOs should have bigger fish … stored, of course, in Saran Wrap(R) … to fry.

Comments

|In: Leadership|Last Updated:

I wonder if any skill remains relevant by the time we’ve mastered it.

Take prototyping as an example. The idea has been around as long as engineers have been designing gadgets, but we in IT resisted the notion for decades, even though business users clearly would have preferred it to the “waterfall” methodologies we insisted on, secure in our conviction that the prophets of methodology knew whereof they spoke.

If it isn’t justice it’s at least a delicious irony: Just as the apostasy of prototyping — built into the heart of such disciplines as Extreme Programming (XP) and the Rational Unified Process (RUP) — has replaced our faith in waterfall methodologies, events have overtaken us.

In the old world of information technology we automated previously manual processes. Prototyping worked fine for the business because the work being performed didn’t change in any fundamental way.

There is, however, no longer any such thing as an IT project. Every project we’re involved in is about business change. We’re redesigning the business — processes, the roles employees play in the business, the skills they need, and probably reporting relationships and a bunch of other aspects of the business besides.

What good is a software prototype when it will only make sense in the context of a different way of doing business? Sure, we can produce one and give it to end-users to play with, but what will we learn by doing so? Nothing. The end-users won’t have the faintest idea as to whether the software is doing anything useful until they’re performing business the new way.

Don’t give up. The logic in favor of prototyping is even more valid when dealing with serious business change, because the cost of a business design being wrong is far higher than the cost of a software design being wrong.

Which is why it’s so important to build a pilot implementation — in effect, a prototype of the new way of doing business — into any software project. A business prototype has to be small enough to be controllable and “tweakable,” while also being both real and complete enough to provide a useful test of the new way of doing business. Satisfying these criteria is far from easy. That, however, isn’t what concerns me about the discipline.

What concerns me is what we’ll have to become good at once we’ve mastered this!

Comments