The Valley is a Harsh Mistress

Successfully achieving each milestone in building your high-tech company won't ensure your survival if you don't learn from the mistakes of others.

Michael. D. Crawford, President
GoingWare Inc.
October 27, 2000

Copyright © 2000 Michael D. Crawford. All Rights Reserved.

The following is a letter I just wrote, originally intending to send to someone I know who is close to bringing a product to market after many difficult and expensive months of product development. My wife and I discussed how I should have made more of an effort to let these people know know what they were undertaking from the beginning, and I agree that I should have recognized their inexperience and worked to prepare them for the hard months of development.

But that is past - I'm worried they think once the product ships their worries are over. I want them to succeed, so I want them to understand what the software business is really like - there are many hard lessons others have learned at the cost of much misery and the loss of fortunes; I'd like them to learn those lessons the easy way, by observing the mistakes of others and not repeating them, and by learning what one can do to run a software business well.

After writing it and asking my wife to read it over, she felt that it would be better if I wrote it up as a web page instead and posted it in the business section of GoingWare's Bag of Programming Tricks so I could help more people understand what they're getting into when they try to start a business, and to refer potential clients to when they come to me with a product they want me to write for them.

Some Thoughts on the Future

I knew both of you were not that familiar with the process of software development. For the most part I am able to do OK in the business of software development, but while I'm a battle-scarred veteran of the industry, I know to expect difficulty and suprise at every turn. I think I would have done well to have helped you to understand what you were getting into.

It's not just that writing a C++ program is hard. The whole software business is hard - it's turbulent and chaotic. Yes, there are fortunes to be made but there are also life-savings to be lost. There is success and joy but there is slow creeping miserable heartbreak too.

My friend Dave Johnson's experience with Working Software is a case in point - Dave struggled for years to make a success of the business, and it always looked like there was light at the end of the tunnel, but his break never really came.

One of the lights that appeared at the end of that tunnel was the exciting new BeOS, and my effort to port Working Software's Spellswell to BeOS from the Mac OS (with a BeOS implemention of the Word Services Suite), an effort which earned me an Honorable Mention in BeOS Master's Awards at the May '97 Be Developer's Conference - but Spellswell has sold only a few dozen copies the whole time it's been shipping and Be ultimately withdrew its support for its desktop operating system.

There is only the slightest whisper of a ghost of Working Software left; there's a website and you can order their products online from Digital River, but there is no office anymore, just a P.O. box that gets checked once a week or so.

Update March 2005: Dave Johnson dissolved Working Software's corporation. You can't order their products from anywhere anymore. For a while there was a note at their homepage thanking their users for their support during the many years we were in business, but a few weeks ago the last trace of Working Software disappeared, when their domain name was sold to a jobs board.

I still get email from loyal users who have tracked me down after finding my name in the credits of the products I wrote for Working Software. They hope that someday, somehow, I might write new versions that work on Mac OS X. I'll see what I can do, but don't hold your breath.

Things were looking good for Be for a while but I'm pretty convinced that it's not going to fare any better than Working Software.

It doesn't have to be that way.

I feel I should have told you earlier on just how hard the software business can be. It's fun for me because I get to write code; I'm into it for the intellectual stimulation and because I was raised to be a scientist that reward is tremendous to me.

Great rewards can come, often do come, but you have to watch out.

I know that you will be tremendously relieved when your product finally reaches the market. Certainly some pressure will be off you, you can rest a bit and you will start generating revenue and likely you can get substantial investment. But please don't let that catch you off guard; bad stuff can still happen.

I'd like to recommend you read a couple of books. I'm sorry to say I haven't read them myself, but I know what's in them - I've lived them, over and over again in my career.

Startup: A Silicon Valley Adventure

by Jerry Kaplan

[ Buy at Amazon]
[ Buy at Powell's]

The first is Startup, A Silicon Valley Adventure by Jerry Kaplan.

(I used to link to FatBrain.com, the online version of Silicon Valley's Computer Literacy Bookstore, but it got swallowed up back during the gold rush.)

Kaplan was the president of the Go Corporation. They made an early handheld computer that you could write on with a stylus via handwriting recognition. They were way ahead of their time - the Palm Pilot wasn't even dreamed of when Go was founded.

Everyone was excited about Go, they had a great technology, a great staff, great technical talent and vast sums of venture capital - all of which they burned through. Go Corporation no longer exists.

When I worked at startup corporation Knowmed Systems in Berkeley (now iKnowMed) several copies of Startup were kept in the office from the very beginning and were were all heavily encouraged by management to read and study it carefully.

Update March 2005: iKnowMed is still in business after nine years, has grown to over ten times the size it was when I worked there, and is very profitable.

There isn't a book about it but I think it's important to understand that Live Picture had tens of millions of dollars in venture capital, with the backing and guidance of former Apple President John Sculley. But while the overall concept of their product was very advanced, it was implemented very poorly - it was just plain buggy and was buggy for good reason, the people who wrote it didn't really know how to program very well, as far as writing concrete working code - what they knew was how to conceive of advanced concepts in graphics, not how to reduce it to a working product.

My experience when I was working there, and from everything I heard about it after I left, was that nothing the management did made a whole lot of sense. In some cases the managers were either clearly incompetent or shortsighted, and in other cases it was clear that while management may have wanted to do the right thing, they weren't allowed to because the venture capitalists had some screwball idea of how the company ought to run that had little bearing on reality.

You can read about the management decision that led to my resignation at The Santa Cruz County Computer Industry Index. It happens that I just found my resignation letter on an old backup; you can find it posted on the programming tips section of my website under Resign with Dignity.

It happens that Live Picture is the one company whose stock options have ever vested for me. Live Picture is now bankrupt. Being a stockholder I receive regular letters from the bankrupcy attorney regarding the dates of court hearings about such things of transfer of the rights to assets like the old source code or payment of the bankrupcy attorney fees. When I left I made the mistake of leaving my 401K in Live Picture's hands and it was frozen by the IRS until the bankrupcy was cleared - the money was held by an investment house so I didn't lose it, but it took me nearly a year to get the money back out of them.

So, if you think having a shipping product is the end of your challenges, I'm sorry it's not - nor is having venture capital. I'm pretty convinced that venture capital is often a bad choice for a way to start a business, and actively plan to avoid it in growing my own business.

A friend of mine who scored $1.5 million when he sold his internet company started a new company afterwards but was reduced to stringing cables in the office and managing the fileserver after he brought in venture capitalists and professional management - even though his official title is Chief Operating Officer, when I was consulting for them it was pretty clear that my friend had got himself put into the position of being an errand boy.

The other book is about managing software projects - or trying to, the difficulty of it. It is an old book, and I think the projects they discuss in it are things like operating systems IBM mainframes. But the essential experience and principles discussed in it are the same.

I would do really well to buy a case of this book and hand a copy to each new client.

The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition

by Frederick P. Brooks

[ Buy at Amazon]
[ Buy at Powell's]

The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks

One of Brooks' points is that large software products are fundamentally different than small ones because of the division of labor - the people involved in the engineering have to communicate with each other, and the changes they make to their own code effects the work of other engineers, sometimes in bad ways.

He says it's really difficult to deal with this but possible. This is part of why your programmer expended so much effort in architecting your product in a quality way; it's not just that he's concerned a future programmer may have to understand his work, but that he has to manage the complexity of the whole thing inside his own head, and architecting it well helps that.

An advantage in the way you've had your product developed is that it was written by just one person. It's been a lot of work for your programmer, but had he got any significant help from another programmer, it would have been a lot more work, not less.

This is one area where managers and venture capitalists who don't understand software engineering make a critical mistake; sometimes if a product is late they hire lots of extra engineers, maybe bring in contract programmers to add some hands to the task. But the end result is that the program gets done slower than it would have had they left it alone in the first place, because now you have all those engineers trying to coordinate their efforts, some some engineers making changes to code that others depend on remaining the same.

If you plan to do any significant additional engineering on your product, it will be really important to understand this. You'll be in a different position than a couple of investors hiring a consultant to write a product from start to finish - you'll be a software company, and there will be engineering and management and architectural issues to be concerned with.

It may seem easier at first to take the simple path, to cut corners, to hurry, to avoid. And in fact it is easier to dig your own hole. You have to keep up standards, you have to carefully choose people to work for you who will be themselves committed to both personal responsibility and to high standards, and while you may not always make the right decisions you must strive to be well informed and to do the very best you can.

I think it is pretty significant that even though Live Picture is a vastly more sophisticated program than Photoshop, Live Picture is out of business while Adobe is a corporate giant.

Photoshop is a nice tool, and it does the job well, but it pales in comparison to what a skilled graphic artist could do with Live Picture. And Live Picture could easily and responsively work with a 200 Megabyte graphic image - even several of them, working with them as a composite, on a Mac 7500/120 with 32 megabytes of memory.

With Photoshop you need at least twice as much physical ram as the total sizes of all the images you have open, plus at least that much more in disk space for the scratch disk. And if you work with high-resolution images, it's really slow. Try opening an 18 megabyte PhotoCD file in photoshop sometime and rotate it by 2 degrees. You can go have a coffee while it works on it. With Live Picture - zip! it's done and you can move on. The only time consuming part comes when you finally save your graphic to a TIFF for use in printing, which comes at the end of the day and you can leave overnight to run as a batch job.

But the reason Live Picture failed where Photoshop succeeded?

Lack of Engineering Quality

While Live Picture was sophisticated, it was poorly done. It would crash a lot, sometimes corrupt your image or do the wrong thing. The code was extraordinarily difficult to work on, in part because of the sophistication - it had to be a complex product to achieve what it did using the limited resources it required - but more so because it was just badly written. Because the first couple of fellows who wrote it just weren't very good programmers, several dozen programmers for years afterward had to spend many more months getting out each release than should have been the case.

Poor Management Decisions

Lack of Commitment to Engineering Quality

Management really didn't care if the code wasn't written right; ideas like the correct way to do something in C++ was regarded as the province of eggheads and not pertinent to business.

There were extremely capable programmers and architects there, but because management did not have a commitment to quality, efforts to actually do work in a quality way were usually overruled. People who couldn't write code that worked were allowed to do so unimpeded. No effort was made to train anyone to be a better programmer; the only excuse for training at the company was a small shelf of programming books, and a kindly senior engineer named Haim Zamir who took it upon himself to give me good advice when he could take the time to.

Poor Allocation of Resources

Lots of money was spent on projects that were thought to appeal to Wall Street and not on projects that could result in a sound basis in revenue from actual sales of software.

Also personnel were often poorly allocated to projects, so that some projects were overstaffed while other projects that were considered critical by management - whether or not management was right in thinking so - were desperately understaffed so that the engineers had the same time had tremendous pressure placed on them but were not allowed to ask for help.

Poor Employee Relations

They treated me all right but some of my friends there were treated like dirt; one foreign friend there on an H1B visa was cruelly abused because management knew he'd be deported immediately if he should no longer be employed there (this is a widespread problem in the industry; management thinks their employees are loyal because they're indentured but they get the quality of effort you'd expect from someone straining at his chains).

An Utter Lack of Common Sense

For example, the appalling decision to leave Santa Cruz County and move to Silicon Valley, and from an inexpensive, fairly plain office in a small town (Scotts Valley) into an extremely expensive high-rise (which happened to be the former Apple Computer customer service building in Campbell).

The ostensible reason for this was that they'd be able to attract more capable engineering and management talent; the most immediate result of it was that it took about three hours from the announcement of the move for me to submit my resignation via email up the whole chain of command through the company starting with my project manager and ending with President Kate Mitchell, who'd made the decision to move.

(Kate Mitchell "resigned" about the same time they canceled their IPO; she'd been brought in by John Scully to prep the company for going public. Instead she burned more money than any of us could ever hope to possess and drove the company smack into the ground.)

Inappropriate Responsiveness to the Shortsighted Whims of Venture Capitalists.

This is where you really have to be on your guard when you go seeking investment in your company.

A good venture capitalist could be your best friend. Besides giving you valuable funds to make your business grow, they can also give expert management advice and guidance to the company. You can go to them with difficult decisions. Because they are often powerful, respected and well-known in the business world, they can open doors for you.

A bad venture capitalist, though, just will have some crackpot idea of how they can grow the apparent - not the real - value of your company the quickest and either sell it off or make a bundle after the Wall Street IPO. This kind of VC is not your friends. You would do better to develop an addiction to crack; at least you'd derive a little temporary pleasure from it.

The bad VC comes up with ideas about what might appeal to Wall Street or to a possible corporate purchaser and orders you to drop what you're doing and pursue his misguided goal.

A specific example of this was when John Scully directed Live Picture, the company, to abandon development of Live Picture 3.0, the program, and instead pursue development of internet technologies involving the very complex and proprietary Flashpix file format.

You could do really cool things with FlashPix, admittedly, but it's not really what users wanted. Very few people use Flashpix these days, even though Kodak, Microsoft and Live Picture went to no end of trouble to develop and promote it. Instead, people who browse the web still get JPEGs, plain and simple.

But the specific reason John Sculley felt it was important to develop and promote Flashpix - he said as much in a company meeting - was because we were preparing for an IPO, and "Wall Street is not interested in tools companies. It is interested in Internet companies".

The same kind of thing happened at Jean-Louis Gassee's Be, Inc. Be abandoned the desktop operating system market to go into Internet Appliances - that is, hooking your refrigerator or stereo up to the Internet, handheld web browsers and the like.

It's not so much that it's such a bad idea to pursue Internet Appliances as the reason why Be chose to do this and the way it did it. It wasn't that anyone was really ready to actually purchase these things, it was that Be was out of money and needed further investment to continue operations, and Wall Street had made it clear to Be that it wasn't interested in having it do the desktop but it did think Internet Appliances would be pretty neat.

The other problem was that Be just plain shafted its developers - me being one of them, as well as my former employer and long-time client Working Software. We were just bluntly told that we weren't welcome anymore after we had labored for years to bring applications to market to run on the BeOS.

When I brought up on Be's third party developer mailing list that I felt Be wasn't treating it's developers fairly or even making much sense, I was told it was inappropriate to discuss business issues on a technical list and forcibly unsubscribed from it by the list moderator.

I was one of the first developers to bring an actual shipping commercial product to market on the Be desktop; now most of my efforts on the BeOS are devoted to getting the message out that Be doesn't keep its word and is best avoided, both as an investment and as a business partner.

(This wasn't in my original letter... If you're considering using the BeIA as an operating system for your Internet Appliance, I'd like you to reconsider your decision.

I have no doubts that there are technical merits to using this BeOS-derived operating system, but you must also consider whether a company that would so-cruelly abandon its desktop developers after so many years of high-flying promises the way Be did when it "changed its focus" would have the moral fiber to continue to support your company when the chips are down - and, because of the nature of this business, you can be sure that someday you will find out whether you can count on your vendor to save you.

Other internat appliance operating systems that have comparable technical merits and may suit your needs include QNX, eCos, LynxOS and the embedded versions of Linux such as RTLinux, Blue Cat Linux or Embedix Linux. Some of these are open source, a fact which may save your neck in the event the vendor withdraws support.)

Unlike Live Picture, Be, Inc. has unquestionable engineering quality - you saw the demo I gave you on my laptop, and for years I would show off the BeOS to anyone I could get to sit still long enough to watch.

So this is an important message: even a commitment to engineering quality doesn't keep a company afloat. It has to make good management decisions, it has to market well (Be's marketing strategy is incomprehensible, they seem to hire people to drive away potential purchasers), it has to foster and maintain quality relationships with business partners - developers in Be's case, they made themselves a lot of enemies with their decision

Update March 2005: Be is gone to, and also no longer has a domain name anymore. But the architecture of the BeOS lives on, reborn in the form of the Open Source operating system Haiku.

I guess for you it will be the firms you partner with, the ad agencies you work with, the press, web sites you partner with, and of course your users.

This is all very complicated and difficult.

You came up with a brilliant idea when you conceived of the way your product would work. Soon your concept will be a reality. So you're in a better position than it may feel for you during these long days of waiting for the product to ship - when you do ship, the program's going to be a hit, people are going to love using it.

I just want you to be careful. All these companies - Live Picture, Be, Working Software, Apple (I have no end of horror stories from Apple) - had or still have brilliant, talented and hardworking people employed by them. But still they manage not to succeed despite their best efforts. Maybe their problem is that they try hard to do the wrong thing, or sometimes they don't try at all to do the right thing.

I want you to succeed. But I feel that the two of you are not that experienced in the minefield of software development. This is why I expended so much effort just now writing this, and why I wish I had made this effort when I met you to help you understand just how difficult and risky software development is.

Please take care of yourselves. Get informed, get expert advice, listen to your feelings and always take the high road.

Yours,

Mike

Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
www.goingware.com
crawford@goingware.com

  Tilting at Windmills for a Better Tomorrow.

Reciprocal Links

See my Reciprocal Links page for more information on how you can get linked from GoingWare's website.

Paguito.com

Online computer sales Compaq, Hewlett Packard and SONY.

Voting for GoingWare at The Programming Pages will encourage more people to read these articles.

Call GoingWare: +1 (831) 401-3790, info@goingware.com

Web Design by Bonita