I read this story yesterday about a failed startup acquisition. It’s one of the big nightmares of an entrepreneur: Big Company shows interest in Startup. Acquisition talks go well. Handshakes and gentlemen’s agreements happen. Startup day-to-day is disrupted during the lengthy acquisition process. For whatever reason, acquisition falls through. Startup is now much worse off than before: less money, low morale. This paragraph stuck with me:

If you go to college in the US, after graduation you’ll start receiving requests to give money to your university. Given that universities in the US are businesses (usually run very efficiently), I always wondered what would motivate alumni to donate. There are many worthwhile causes in the world (e.g. hunger, malaria, preventable diseases). Why choose a school that may use your money to build a world-class swimming pool or running track?

Those of us who work in software live in a world of lean practices. We are encouraged to prototype, fail fast and iterate. We have seen software-based companies go from an idea in a kid’s brain to a billion dollar business in the time it would have taken him to get a college degree. Of course, those are the outliers on the positive side. For every extremely successful software project there are a large number of failed ones that we’ll never hear about.

There are also projects that managed to survive only because they had the backing of an already successful company, flush with cash. Microsoft Word for Windows could be a good example. Not many people know the story of what would become one of the most widely used software products ever. I learned about it from a case study for my Software Project Management class in 1997, what follows is my summary (original here, or Google it).

In September of 1984 Bill Gates wanted a word processor that would run on Windows (being developed at the time). He gave the project to John Hunt, Andrew Hermann and Lee Arthurs. Greg Slyngstad (who would later become the program manager for the project) said:

Gates put three real hotshots on the project. Hunt, who had single-handedly written the first version of PC Word, became the project manager. Arthurs, who had a Ph.D. in psychology, was responsible for user interface and documentation. Hermann had been at Wang and was supposed to know the word proces­sor business inside and out.

The project was codenamed Cashmere, and it was scheduled to take a year or less. At this point you can probably guess that this did not happen. The scope for the project turned out to be too ambitious. At the end of the first year, all the team had to show for their efforts were some design papers. The design included features such as email, spreadsheet capabilities, document protection, and much more. Hunt left the project in the summer of ’86. Slyngstad came on board, along with Doug Kurtz (lead developer for the DOS version of Word), and other MS stars. The new team decided to throw away all the work done to date, and start from the Word for Macintosh codebase. The project was renamed to Opus, and was staffed mostly with new hires.

The next year went by as the team wrote a new spec for the product. Soon it was 1988, and the team was under extreme pressure to deliver. One development manager put it this way:

Opus got into a mode that I call “Infinite Defects,” When you put a lot of schedule pressure on developers, they tend to do the minimum amount of work necessary on a feature. When it works well enough to demonstrate, they consider it done and the feature is checked off on the schedule. The inevitable bugs months later are seen as unrelated. Even worse, by the time the bugs are discovered, the developers can’t remember their code so it takes them a lot longer to fix. Furthermore, the schedule is thrown off because that feature was supposed to be finished.

To make a long story short, the project was deemed “code complete” in late ’88, but it was full of bugs. It took one full year to stabilize it enough for release. The release date was November 30, 1989. This is more than five years after the start date, and four years behind schedule. Needless to say, this project taught Microsoft a number of valuable lessons. Their software development process improved tremendously over the next decade. A blue screen of death here and there is nothing compared to the above 🙂

You’d think the software industry as a whole has improved enough that schedules no longer stretch by 5x. If you work in software, you know it still happens. Why? Hint: not because of the explanation given in what was the Quora Answer of the Day a few weeks ago. If only it were that simple. A much better argument was made (in 1986!) by Fred Brooks: No Silver Bullet – Essence and Accidents of Software Engineering.”

Today is InDay at LinkedIn. We are encouraged to spend one day each month learning, inspiring others, and sharing knowledge with the community. I’ve been at LinkedIn for four months now, and this day gives me the perfect excuse to write a post about two things I love about this place: open source code and big data.

In Silicon Valley we have this notion of the entrepreneur as the lone hero. A risk taker who shoots for the moon and aims to knock the ball out of the park. A visionary, a dreamer, a jack-of-all-trades. In another time he would have been a discoverer of new continents, a warrior, an inventor, a heretic. I could keep the clichés going but I’ll save some for another post.