The Dot-Com Demise by pengxiuhui

VIEWS: 42 PAGES: 9

									The Dot-Com Demise
October 2001

In the San Francisco Bay Area, a.k.a. Silicon Valley, hundreds of Internet start-
ups—more than a third of the nation's Web businesses—have shut down in the past
year. You've read about the crazy business plans, the excessive perks and the
manic spending, but what about the software side of the dot-calm?

by SD Staff

How bad was my dot-com nightmare? Well, first off, I was wide awake, not dreaming. The bad karma
started at the top with our clinically paranoid chief executive, who self-medicated with little white pills,
$5,000 escorts and "the best bottle of white wine in your cellar." He once flew to China on five days'
notice (first class, of course) to pitch our classroom management software to the Ministry of Education,
but mistakenly flew to Beijing instead of Nanjing, where the ministers were waiting. They never got
back to us about rescheduling. In the year I worked there, the company grew from 12 employees to 65
and then shrank to 40, with more than 100 people revolving through the doors. Nine months after I left,
the company went bankrupt, having consumed $15 million in capital and leaving additional millions in
debt. Eight weeks before I quit, the company had been flirting with a valuation of $400 million. When
the wheels came off, we didn't even rate a mention on www.f***ed company.com, despite a colleague's
brilliant resignation note that borrowed from Shakespeare's Julius Caesar to say of the CEO: " …
therefore think him as a serpent's egg/Which, hatch'd, would, as his kind, grow mischievous,/And kill
him in the shell."

Ah, the dot-com days! For three years, the San Francisco Bay Area experienced a second gold rush, a
speculative fever that raged here and in various silicon cavities: alleys, gulches and canyons. Powered
by triple-shot espressos (called "depth charges" for both their caffeine blast and their devastating effect
on one's kidneys), PowerPoint slides depicting "hockey sticks" (potentially exponential revenue growth),
and 60-hour workweeks, in retrospect it seems as absurd as a 28-year-old CEO commuting to a $7-per-
square-foot, unheated warehouse conversion on an electric scooter, his $600 duster blowing in the wind
and his Motorola StarTac phone bleating the William Tell Overture.

One Hand Clapping
So you would have thought that Software Development's call for tales from the dot-com crypt would
have caused a deluge of submissions. Not so. Although we received some, the best of which are
presented here, the truth is that, despite the zeitgeist, programmers did pretty well for themselves in the
past three years. At least, a lot better than anyone whose job title includes the words "business
development."

For one thing, programming for a dot-com was, aside from the long hours, generally kind of fun. New
languages such as Java, cool interfaces designed by graphic professionals (even if few had barely
rudimentary training in user interface design), exploding salaries and absurdly high visibility ("When
you're done with your sushi, Mr. Venture Capitalist, we'll visit Engineering.")—what's so horrible about
that?
I once had to stop on the road home because my eyes were so shot from a 20-hour coding session that I
was seeing double. It was four o'clock in the morning and in two days we were presenting to venture
capitalists for the $7 million in our Series A round of financing—the series that would, we thought, put
us on rails toward an initial public offering in 12 months. "Win or lose," I thought, stopped in the middle
of the road, "This is something. Remember this." And I have.

                                                                                           —Larry O'Brien
                                                                                   Interim Technical Editor

Fitness Flop
I like to think that I was clever enough to entirely avoid the siren song of the dot-coms, but that's not
true. The lure of excitement and money sometimes overwhelms judgment. I almost succumbed to the
desire to be part of what everyone else was talking about. Thus, I briefly flirted with one of the dot-
coms—and turned my back on it.

A friend of mine with a good history of corporate success had started one of those infamous dot-com
incubators. One of the fledglings was a fitness dot-com. A simple idea: a Web site where fitness buffs
could subscribe to have a customized fitness program designed and monitored by a professional trainer.
Such a system would dramatically improve the trainer's productivity, and therefore their income. Also
conveniently located at the Web site would be an online store selling fitness products. Not a bad idea, as
far as most dot-coms went. But I couldn't quite ignore my inner voice: I'm into fitness, but I'm loath to
even pick up a pencil to record my workout, let alone boot up a computer, log onto the Web and start
typing.

The development team was having problems delivering the product and my friend wanted to see what I
could do. Even at the height of the dot-com boom, most investors still wanted to at least see a product
demo. The team was housed in a regulation dot-com building: the old part of the city, loft-style
warehouse, with the mandatory exposed brickwork. Open plan with tables and workstations and servers
everywhere. Netscape cofounder Marc Andreessen calls this style "creative, exciting and stimulating." I
thought it was just noisy and confusing. The team itself was young: most had either just graduated from
college or had taken time off to cash in on the dot-com wave. The architect/team leader/software
development manager was a graduate student who was working on the project part-time.

I sat down with the part-time software development manager and asked him to tell me about the project's
risks and problems. The first risk he mentioned was the danger of "too much process." He knew he had
no process—he also knew why I was there, and was making sure I understood that things at a dot-com
were "different."

They certainly were different: In three months, these guys had bought tens of thousands of dollars' worth
of high-end enterprise development tools such as WebSphere, Oracle and VisualAge for Java. After
three months, they had finally managed to get WebSphere to work, and they were just getting familiar
with Java. The main area of technical interest was the object persistence framework they were
designing. No one seemed to have an interest in delivering a product. Aside from a few screen shots that
had been created by another Web design company, there was nothing that could be called
"requirements" or "progress."

I told my friend that the development team was far more interested in playing in a technological sandbox
than delivering a product, but he was reluctant to take any action that might annoy his "engineers"—
after all, in those days, warm bodies were hard to find. Even though I'm a mercenary and my friend was
offering me the opportunity for great money, I know a bad bet when I see one, and I bowed out.
It turned out that my inner voice was right. As I understand, the company folded about five months
later—after delivering nothing.

                                                                                         —Steve Adolph
                                                                                      Contributing Editor

Presto Change-o!
During the dot-com gold rush, I taught a project management workshop for a company that had a
historically successful but aging product: a 10-year-old data management system based on a five-year-
old architecture.

Product revenue was falling, so senior management decided that, given the "new economy," it was clear
that they should transition into a strictly e-business consulting company instead of upgrading the
architecture and continuing to sell the product. The project managers practiced eliciting requirements
and managing projects with external clients, since the project managers now had to work directly with
customers rather than internal marketing or service people.

Before, the project managers had easily understood the technical details of their company's commercial
products. Now the emphasis was on managing teams as they built front- and back-ends for Web sites.
Learning what their clients wanted and figuring out how to translate those desires into something the
engineers could produce was dramatically more difficult than it had been while creating their own
products.

While the project managers were learning how to manage differently, senior managers had to change,
too. Previously, senior management had determined technical direction, but now they had to focus on
marketing: Should they take on work from this client? Should they take on this kind of a project?
Suddenly, the company's strategy could change from project to project, something that hadn't happened
when they were selling and creating products.

Managing a consulting company, even a consulting company that deals with only Internet-based
projects, requires different skills than running a product company. Throughout each quarter of the next
fiscal year, revenue decreased, the roster of clients dwindled, and each project took more time—and
more money—than the company had expected.

During my workshop at the struggling firm, the project managers and I developed a checklist for each
potential engagement to help resolve the management issues. Some of the questions were:

   !   Have we done a project like this? Were we successful? If so, why?
   !   Is this project a strategic project for us? What makes it strategic?
   !   Is this client a strategic client? What makes them strategic?
   !   Do we have any doubts about our ability to do this project? What are those doubts?

Senior management, however, was unwilling to consistently use the checklist we created, and agreed to
a number of projects that lost money and didn't support the company's transition into the services realm.

Moving from a product company (even one whose product wasn't producing much revenue) to a service
company was beyond this organization's ability. These folks are out of business now, their new funding
gone and everyone laid off. And the old product? Well, the assets were sold to another organization
that's revitalizing the data management software quite nicely.
The moral of this story: Don't assume that just because you can get funding to jump on the bandwagon-
of-the-year you can execute the work necessary to succeed.

                                                                                       —Johanna Rothman
                                                                                         Editorial Advisor

Consultants: Silicon Bloodsuckers
I was employed as a consultant at several dot-coms during the Internet boom, working at a couple in
Silicon Valley and one on my home turf of Toronto. From the point of view of a consultant trying to
increase business, it was one of the most horrifying experiences imaginable. Dim the lights, gather
round the fire and let me tell you a tale of Extreme horror.

This company was typical of many dot-coms—they were providing a free online service to individuals,
paying for it in part through advertising, and acting as an application service provider to companies that
wanted to outsource the management of this online service to them. When I joined them, they had
received venture capital funding, had been in operation for over a year, were growing at a phenomenal
rate, and were working toward an initial public offering, which was eventually very successful.

The developers worked together in small teams, using a shared code base and writing very clean code as
a result. Usually I can convince a client to start running code reviews, but their code was effectively
being reviewed as it was being developed because anyone could work on it. Darn it!

Although skill levels varied, for the most part, individual developers filled multiple roles on their team,
requiring less documentation as a result because there were fewer artificial hand-offs to deal with.
Furthermore, to my horror, I quickly discovered that few models were developed—and those that did
surface were often just simple sketches on a whiteboard or paper napkin. Had this been a large,
established organization, numerous people would have whiled away hours creating lots of pretty
pictures and mounds of documentation, expending significant effort reviewing their artifacts and
ensuring traceability between them. Heck, I could have sold a large company on the concept of a
several-month thorough CASE tool review—but not these folks. Unfortunately, these developers were
focused on creating software, not documents, and modeled only when it actually added value. And you
know what? Their software worked—and was robust enough so that it could be modified to meet their
growing transaction load (remember, this was an Internet company). All I could do was mentor
developers in various modeling techniques, but that was about it.

I then looked for what's always a consulting gold mine in any established organization: trying to make
the data department effective. In most cases, this is a hopeless task—which is why it's so lucrative for
consultants. Unfortunately, this company took an agile approach in this area, as well. The database
group was small, and maintained the corporate data model, the development databases and the
production databases. They worked closely with both the development teams and the operations
department, and I often saw them working through issues with people outside of their group. They didn't
waste their time with logical modeling or extensive documentation of their data dictionary; instead, they
realized that the physical data model was their true focus. They didn't build any artificial barriers
between themselves and the developers, didn't require people to follow a complex and document-heavy
process, and shared any models and documentation they had with anyone who asked. It was horrible!
Not only weren't they an impediment to progress—they actually helped people get their jobs done.
These guys wouldn't have lasted five minutes in a large corporation, let alone a government agency.

Whenever two groups, such as the business stakeholders and the operations group, needed to interact,
they wrote an informal contract defining the roles and responsibilities of each group. They didn't define
a formal process, nor much of an informal one, yet they were very successful at developing software.
Foiled again! At a government agency, I could have set up a process improvement group (PIG) that
would have held meetings for months, if not years, to define a software process that would have been
ignored by the developers. We could then have rammed it down people's throats—oops, I mean
"mentored staff"—for the next several years. Alas, it was not to be.

Because this company took an agile approach to software development, there was little room for
improvement—exactly the wrong situation if you're trying to sell consulting services. In cyberspace, no
one can hear consultants scream.

                                                                            —Scott "Don't hate me because
                                                                                    I'm sarcastic" Ambler
                                                                               Senior Contributing Editor

P.S. Yes, at the time of this writing, the company is still in operation, despite its wacky business plan.

Devil in the Database
For six months in 2000, I worked for a dot-com Internet directory. Yes, the fresh-faced staff luxuriated
in the complimentary massages, contorted in the weekly yoga class and frolicked at the opulent beer
bashes, but what doomed the company was not so much this excess of perks, but a peculiar wrong-
headedness in technology management.

Our directory consisted of input from more than 500 in-house writers who scanned the Internet in search
of interesting Web sites, entering two-sentence descriptions of these into our database. Management
whipped up a missionary zeal that spread like wildfire through the youthful congregation. Despite—or
maybe because of—meetings about meetings about meetings, morale was sky-high. Employees were
passionate about their work, and genuine team spirit flourished. We would conquer the world—or at
least that part of the world that mattered: the Internet.

Well and good. However, as the saying goes, the devil's in the details; or, in this case, the database. Our
proprietary compilation system was woefully inadequate for both our needs and our volume of
employees: The constant crashes set back production for days at a time. In lingering coffee klatches on
the overstuffed, zebra-print couches scattered through the employee lounge, we sucked down 10-cent
Snapples, whiling away the hours before the system was resurrected—until the next crash.

As the months passed, morale wilted and blasphemers cropped up, fomenting dissent. Meetings
originally reminiscent of high-school pep rallies devolved into soapboxes for the surly. The grumblers
were assured that the imminent "version 2" would solve all problems—only to find that it was far slower
and more bug-prone than its predecessor.

At this, heretics arose en masse. Faced with the threat of an exodus, after months of hemming and
hawing, the desperate PTB made a multi-million-dollar purchase of a competing directory boasting an
enthusiastic all-volunteer staff and its own proprietary system with a "killer interface" that was promised
to accelerate our Web search and data entry process. It also purportedly offered a vast number of listings
that would swell our sagging database and revive our anemic investors.

The long-awaited system arrived, heralded by oversized coffee-cups emblazoned with the combined
logos of both companies. But the lavish welcome didn't diffuse the skepticism of those in the trenches.
Sure enough, before the pesto-and-arugula sandwiches had time to curl, it became painfully evident that
the long-awaited system was even pokier and buggier than anything our own engineers had labored so
long to produce, and the "vast number of entries" that were to save our bacon with the investors proved,
in the main, utterly unusable: inaccurate, irrelevant or—worse—completely void of data.

Along with more than a third of the company, I was abruptly laid off not long afterward—albeit with a
generous severance package.

Like its capricious cappuccino machine that frequently spewed froth and steam onto luckless employees,
the company produced an abundance of fizz based on a shaky machinery, despite grand dreams and
progressive policies. At current writing, it limps on with a skeleton crew, stock barely above sea level,
still awaiting a deus ex machina—hey, how's about a new proprietary system?

                                                                                        —Laurie O'Connell
                                                                                              Copy Editor

CueCatastrophe
Next to the company that tried to wire Web users to bar-code scanners, money-burning dot-coms like
Webvan don't look quite so bad.

Those grim, told-you-so pundits conducting postmortems of the Internet stock bubble have been quick
to lash dot-com entrepreneurs for their foolhardy naïveté. "You idiots," goes the standard line of rear-
view mirror commentary. "You were great at giving away stuff to the public, but you never had a
business model!"

The news of Webvan's demise provides hefty fodder for this conventional wisdom. Here's a company
that clearly provided a service that met a need—lots of busy Americans would love not to waste time
at the grocery store—but never had a clue how to make money. Tsk, tsk, scold the pundits: What were
they thinking?

Well, OK. It's pretty obvious that any business launched without a clear vision of how to sustain
profits isn't destined for longevity. If, in the heady days of 1999, a motley cadre of venture capitalists,
Internet visionaries and technology investors lost sight of that truth, it was, relatively, only a brief
moment of folly.

The Internet industry and all of its "new economy" hype has now taken enough pulverizing criticism
that it's worth re-examining the animus against it. After all, what were many of the highest-profile dot-
coms that soared and then crashed really up to? They gave away previously expensive goods and
services (e-mail, Internet access, even computer hardware) for free. They devised innovative new
services (home or office delivery of convenience-store goods and groceries, online payment schemes,
free discussion and consumer rating sites) that lost money but made people happy.

Of course some of the companies floating in the dot-com dead-pool were just stupid. But in many
cases, what did these companies do that was so deserving of scorn? They put the interests of their
customers first. This may ultimately have been foolish, since in the end they couldn't keep a business
alive that way; but it's nothing to sneer at.

Consider the alternative. Consider the sad saga of the CueCat.

The CueCat, you may recall, was a bar-code scanner that a company out of Dallas called Digital
Convergence was sending out free to millions of users. You were supposed to plug it into your
computer and then point it at bar codes appearing in magazine ads; the bar codes would send your
browser to a specific page within the advertiser's Web site.

Apparently the advertisers of the world faced such an insurmountable problem in guiding customers to
their Web sites that it would be worth everyone's while to deploy this Rube Goldberg contraption. Or
so the thinking went among the captains of industry. Joe Web Surfer just yawned and laughed.

Digital Convergence, in other words, is the opposite of a dot-com: Rather than coming up with a
scheme to please the public while forgetting about how to satisfy big-pocket investors with profits,
these folks whipped up a project that made boardroom occupants drool with excitement—but forgot
about pleasing their own customers.

As anyone who actually uses the Web could have predicted, the CueCat turned out to be a massive
flop, and—except for a few hackers who figured out how to bend the device to their own ends—lots of
CueCats are now fattening landfills everywhere.

What's interesting about the CueCat fiasco is not that it happened, but that large and ostensibly savvy
companies chose to invest in the loony scheme. A recent Wall Street Journal article reported some
details: Digital Convergence got $37.5 million from Belo Corp. (the media company that owns the
Dallas Morning News), $30 million from Radio Shack, $28 million from Young & Rubicam and even
$10 million from Coca-Cola. What were the titans of business acumen who lead these blue-chip
companies thinking?

According to the Journal article, it was the boardroom sales skills of Digital Convergence CEO and
promoter J. Jovan Philyaw that wowed executives and opened their wallets. I've never experienced Mr.
Philyaw's pitch myself, but it doesn't take much imagination to picture the scene.

Philyaw doubtless told his listeners that the problem with their Web sites wasn't that they were poorly
conceived or designed or that there was little reason for most people to want to visit them—it was that
users couldn't find what they wanted because the Web was just so darn confusing. He didn't say, "You
should redesign your Web site to make it easier for people to find what they want"; he said, let's spend
a fortune putting bar-code scanners in readers' hands and then require them to register, because then we
can tell you who they are and where they live.

In other words, Philyaw was able to raise such substantial sums of money because he told his CEO
listeners what they wanted to hear. That doesn't make him particularly special in the annals of
business, which are filled with follies that appealed to the executive mindset, but flopped when they
were rejected by the public. But in this post-dot-com-downturn era, it does serve as a healthy reminder
that a business model is not the only thing you need to build a company. It helps to have customers,
too.

                                                                                                  —Scott Rosenberg

This article originally appeared at http://www.salon.com/, where Scott Rosenberg is managing editor. Reprinted with
permission.




A Special Halloween Treat
The Flying Architect still haunts failed software projects everywhere.
The old programmers say that if you sit quietly in your cubicle on All Hallow's Eve, you can
sometimes see the Flying Architect. Under the light of the moon, he sits in his cubicle, pounding at his
keyboard, his blood-red T-shirt bathed in the glow of his monitor. He is lost in thought, forever
working on that perfect system that, if it is ever deployed, will let his soul finally take its rest.

Many years ago, the Flying Architect was one of our company's greatest and most innovative
programmers: a guy who dreamed of doing things right. He was completely frustrated by our small
system, a legacy built upon a legacy, crafted in C and assembler. Twelve years ago, the company was
founded to sell DOS-based products to a hungry industry. But success can be a bad omen, and our
customer quickly demanded new features. Just as quickly, we hacked them and tacked them on. The
hack and tack continued through Windows 3.1 to Windows 95 and NT; C became C++, and
executables became COM objects. Over time, the system became creaky and sclerotic.

Finally, in a fit of rage, the Flying Architect raised his head toward the heavens—well, the executive
suite, actually—and screamed "Enough! This hack and tack is costing us time and money! Our
competitors can change their system faster than we do! Our customers are angry. No more spaghetti
code! I want requirements, I want process, I want architecture! I want scalability, I want reliability, I
want expandability. No short cuts—it's time to do it right!"

And so the heavens opened, and funding and resources were made available to the Flying Architect for
the new next-generation system. The aging system was put into the twilight of maintenance, and the
next generation started. It was going to be beautiful: all object oriented, all in C++. There would be
clean, elegant frameworks and slick, reusable components. Programmers from the old system quickly
sought positions on the next-generation project. The next generation quickly became our largest and
most costly project.

But then the storms came. Our competitors were announcing new features, and our customers were
demanding new features. The heavens grew impatient. "Where is the next generation?" they
demanded. All the Flying Architect could say was, "I've created a beautiful framework. It's object
oriented, scalable and extensible. When it's all done, it will cost us a tenth of what it costs us now to
add a new feature."

The heavens were not pleased. "We don't care about your framework—we need a product today!" they
thundered. "The next generation is sucking up resources that we could use to create new features that
the customers pay for today." So the heavens demanded that some of the architect's crew be returned to
the old projects.

The Flying Architect soldiered on, and soon had the next generation supporting a few of the legacy's
core features. But the storms increased, and the heavens canceled the next-generation project.
Whereupon the Flying Architect made a career-limiting move and swore an oath to the heavens that he
would complete the next-generation system. Every year at budget time, the heavens let the Flying
Architect try to redeem his soul by giving him some of the resources he needed to finish and deploy
the next-generation project, but every year the storms rose up again, and the resources were
reallocated.

And, to this day, on All Hallow's Eve, if you sit quietly in your cubicle, you just might hear the Flying
Architect scream, "No more spaghetti code! I want requirements, I want process, I want architecture! I
want scalability, I want reliability, I want expandability. No short cuts—it's time to do it right!" But the
heavens remain silent.
   —Steve Adolph
Contributing Editor

								
To top