And then…

Before I started Likewise Software, I was in the venture capital business. Although my role was more on the “back end”, performing due diligence once we’d decided to invest in a company, I heard many, many pitches from aspiring entrepreneurs. For the great majority of these pitches (probably 95% of them or so), I recommended against investing in them.

It wasn’t that 95% of the proposed ideas were bad but, in most cases, either the idea or the team was weak. Venture capital folk like to say that they don’t “bet on the horse” they “bet on the jockey.” Occasionally, I’d hear weak ideas from good teams. In these cases, I’d try to guide them towards better alternatives. Most often, though, I’d hear reasonably good ideas from weak teams. It’s much harder trying to fix a weak team than a weak idea. Once in a while, a VC will try to do this. For example, they’ll propose funding on condition that a strong CEO be hired. This doesn’t always work. One of the founders might already fashion him/herself as CEO. Even worse, a founder might agree to take on a different role but then obstruct the new CEO once hired.

VCs like to bet on people because it’s been proven to be the most successful strategy. A good team can sell a weak product much better than a weak team can sell a good product. In practice, too, the good team will fixthe weak product while the weak team will find some way to ruin the good one. Think Betamax.

I’ve been a part of a couple of very strong teams during my career in the software business. From 1988 to 1994, I worked in the Developer Tools group at Microsoft. More recently, from 2004 I’ve been at Likewise (nee Centeris). In both cases we dealt with uncertainty and strong competitors and, through persistence and execution, succeeded. Weaker teams would not have fared as well.

In the early 90’s, the Microsoft “compiler group” was in trouble. Borland was kicking our collective behinds. We’d released Microsoft C version 6 to very negative reactions (we were one of the first products to eliminate print documentation in favor of electronic documents). We were mired in obligations to our operating system group and to IBM (for OS/2 support). Meanwhile, Borland had Turbo C and Turbo Pascal both of which were doing very well. Gates would frequently criticize our lack of killer product ideas. Nathan Myhrvold (effectively, the Microsoft CTO, at the time) wanted us to emphasize high-quality printed code listings. We’d gone from 60% market share to 40% (Watcom C was in there, too). Meanwhile, C7, our first C++ compiler, was mired in schedule delays and lack of focus. It was very easy to despair.

At yet, we didn’t. We gave up the IBM business (Borland took it and, I’m sure, regretted it). We basically told Gates and Myhrvold to stuff it. We released Quick C for Windows and Visual C++ 1.0 for NT — products that were received reasonably well. When we released Visual C++ 2.0 (the precursor of Visual Studio), we completely turned the tide. We got back more than our previous market share and never lost it. Within a year, Borland was firing/losing people and we were hiring/finding them.

Looking back, the interesting thing to me is that, at the time, we weren’t aware of any killer idea that we were counting on to succeed. In retrospect, it was “MFC” the Microsoft Foundation Classes and its coupling to our forms editor that turned out to be the killer idea (an idea on which .NET has built a billion dollar business). At the time, however, we were just doing our jobs and executing very well.

Back in the early 90’s, the Tools group was a very mature group for Microsoft. A lot of people wanted to work on operating systems or on cool applications. The only people who worked in the Tools group were nerdy folk who were into code optimization or writing debuggers and class libraries. Once in the Tools group, these people never left. We had old timers who’d been there for a decade. What this meant is that everyone knew their jobs extremely well.

Visual C++ 2.0 shipped on-time, with its full feature set, and with extremely good quality. To this day, I still consider it the most successful project I’ve ever worked on. In the course of 18 months, the Tools group had gone from being failures to being brilliant.

The road to success is rarely clear. To abuse the metaphor, if it’s an eight lane superhighway, it’s going to be jam-packed with competitors. More likely, the road to success is a poorly marked path through dangerous woods. Likely, you will have to bushwack. There’s no guarantee you won’t end up at a dead end or at a cliff. Your best best is to count on a good team, to be persistent and to not despair. Fate tends to favor the strong.

If you read my About page, you’ll know that I’m a crusty old programmer (COP). I may be 48 years young (as of January 2008), but I’m 144 years old in programmer-years. A year of intense programming ages you at 3x normal. (I suppose that, more accurately, I’m 15+33*3=114, since I didn’t start writing software until I was 15 ).

Needless to say, over the course of this many years I’ve see a lot of stuff happen.

As do other COPs, I like to amaze people with “back in the old day” stories. When a bunch of us COPs get together, this becomes a competition of sorts where winning is achieved by describing the most absolutely arcane, unbelievable, thing that we had to deal with in our youth. I generally do pretty well in these contests.

No, I did not cut gears for Babbage’s Difference Engine nor did I swap tubes on the Eniac. My history only goes back to Univac 1108s and IBM 360s in the mid 70s. I did punch card decks and stream paper tape. I do remember going to libraries and seeing books on both digital and analog computers (whatever happened to these?). I also remember reading about wiring “programming panels” on older computers.

Most of my crusty programmer stories come from the early days of microcomputers (as they used to be called back then). My first micro was an Intel 8008-based system. The machine was called the Scelbi 8H. I would love to buy one of these now, but they all seem to be in museums.

I experienced the arrival of CP/M and the Z-100 based Intel 8080 systems. I used the first Altairs and envied the folks with the cool IMSAI machines (much prettier front panels). I programmed these as well as the first Apple II (using UCSD Pascal).

One a scale of 1-10, programming a computer via its front-panel switches is worth about 7 crusty old programmer points. Whenever I meet a whippersnapper that brags about working on a PDP-8, I counter that they were totally spoiled. Let me explain.

On the PDP-8 (and all computers of which I’m aware of, save one), the front panel had lots of switches:

(borrowed, without permission, from Wikipedia)

To write data to memory, you could set the main bank of switches to an address (only 12-bits) and press the “ADDR LOAD” button. Then you could set the switches to the data you wanted to write and press the “DEP” button. This would write the data in the previously loaded address and would then increment the address by one. You could write successive words of memory by setting the switches to the desired value and pressing “DEP”. The PDP-8 front panel worked by performing a “memory write” bus cycle.

Performing this task was way more complicated on the Scelbi 8H. Consider it’s front panel:

(also from Wikipedia)

It’s only got 8 data switches and three pushbuttons. The three buttons are labeled “Int”, “Run” and “Step.”  The most important of these was Step. Run simply started your program and Int stopped (interrupted it). Step was where all the programming action took place. On the Scelbi 8H, this button “jammed” an instruction (whatever was on the switches) into the CPU. I don’t know whether this was dictated by the CPU design or simply an abomination invented by Nat Wadsworth (the father of the Scelbi). Presumably, implementing the front panel this way was easier than having it perform a full memory write cycle. However, it made panel-based programming torturous. This is what you had to do:

1. Set the data switches for the binary equivalent of the LHI instruction (octal 056). LHI is the “Load H register immediate” instruction. In the 8008, The H and L registers are the “address” to be used for subsequent memory operations. Press Step. Now the CPU is waiting for the second byte of the LHI instruction: the byte to be stored into the H register.
2. Set the switches to the high byte of the memory address to where you want to store a byte. Press Step. Now you’ve got the H register loaded!
3. Set the switches for the binary equivalent of the LLI instruction (066). Press Step.
4. Set the switches to the low byte of the memory address to where you want to store a byte. Press Step. Now you’ve got your HL register pair set!
5. Set the switches for the binary equivalent of the LMI instruction (076). This is the “Load memory immediate instruction”. Press Step. Now the CPU is waiting for your data byte.
6. Set the switches to the byte value that you want to store to memory. Press Step.  You’re done!

If you wanted to store a second byte, things were a little easier. You could simply execute the INL (increment L) instruction and then repeat steps 5 and 6. I don’t remember if INL automatically “carried” to the H register. I suspect you had to know you were crossing a “page” boundary and had to manually increment H, too.

Yes, we were real men back in 1975. Programming was painful and we liked it that way. No pansy-ass compilers for us, no sir. Of course, we were lucky if we could write 128 bytes of machine code a day. Today, heck, an empty program generates 1000 times that much code.

PS: A big “shout out” to Ron Hosek and Jeff Augenstein. These two guys hired me back in 1975, when I was just 15 years old. They let me write software for the Scelbi 8H and, later, for the Altair. They were truly among the first of the computer entrepreneurs and I learned a lot working with them. I’ve lost touch with them over the years, but I hope that they are happy, healthy and smug for having so much foresight.

As a software developer, I get to see aspects of Windows, Linux, UNIX and Mac OS X of which end-users are oblivious. In previous posts, (for example, What Linux Needs to Learn from Windows) I have bemoaned the lack of standards between Linux distributions and the lack of system APIs. I’ve also praised Microsoft for delivering useful functionality in .NET (Programming is Fun [Again]).

Is Linux doomed to fail? Will Microsoft continue its hegemony?

If you read my series The Decline and Fall of Microsoft you know that I think Microsoft is facing some huge structural challenges. Nevertheless, here’s what I think is going to happen over the next 5 years:

1. Microsoft will lose a large percentage of the general-purpose PC business to Apple. It will keep 50% or so, but mostly for dedicated workstations. Apple will take a majority of the laptop business.
2. IT departments will continue to replace proprietary UNIX servers with Linux, especially given the move towards more virtualization.
3. Windows will see an increased share of the server business driven by .NET and Sharepoint applications.
4. Linux on the desktop will see minimal gains.
5. Linux will dominate in the special-purpose, sub-notebook, business (such as with the Eee PC on which I am currently typing). Linux will also see increased use in some specific scenarios that require limited application availability.

All in all, I think there will be growth for Linux but it will actually lose overall composite share. I believe this for several reasons.

Although Linux is growing in the server business, I think that Microsoft will soon surpass its growth rate, if it hasn’t already (I don’t have my IDC numbers handy). Linux server growth is driven by UNIX-to-Linux conversions (i.e. new Oracle servers running Linux instead of Solaris) and by Apache server use. I think the former is a limited business and I think the latter is already limited by overall market growth. To grow share, Linux has to take away Windows server business, especially in the Intranet, and I don’t see this happening. Why? I think that Microsoft is winning the war for the hearts and minds of developers. Microsoft is an API company. Red Hat (except for JBoss) and Novell are not. Innovations in Linux API are mostly made by other companies (MySQL, Eclipse, Sugar CRM, etc.) and are often OS-independent. Microsoft, having totally stumbled on Vista, seems to have not screwed up Windows Server 2008, Sharepoint and SQL Server.

In the general-purpose, desktop/laptop business, Linux is missing Microsoft Office. In spite of the things I dislike about Office 2007, it’s still the Swiss Army knife of productivity software. Open Office is a poor, poor, substitute at any price. Even Office for the Mac is a poor substitute but it’s good enough. Workers who have the freedom to buy what they want (e.g. executives, technoids) will buy Macs. Vista is an embarrasment. I wish Microsoft would just port WPF and the new shell to XP, throw out everything else in Vista and admit its mistakes.

The only segment that I see Linux gaining market share is the specialty-use market. Sub-notebooks, like my Eee PC want to keep costs very low. This means they need an inexpensive OS that doesn’t require a lot of resources to run. Vista won’t cut it. Windows CE is too limited. I’d love to run Mac OS X on my Eee PC but I can’t without riling Apple’s lawyers. Linux is the only choice. Similarly, we’ve run into one or two companies that want to install Linux on a computer to use it only as a Citrix terminal. What’s weird is that they’ll be using Linux to run Windows applications via remote terminal services.

On the whole, this is not a very exciting future for Linux. There is still money to be made in the Linux business and Red Hat, Novell and others may be satisfied with the niches that I’ve described above. Personally, I find my prognoses somewhat depressing. I like Mac OS X but Apple’s walled-garden mentality is very 1980s. Microsoft still has a strong platform for software developers but I think that over time, their size and inability to execute will infect all areas in the company.

I wish that Linux was a better operating system than it is. I’d love there to be a credible alternative to the mess of Microsoft and the tyranny of Apple.

The procrastinators motto is “Don’t put off for tomorrow what you can put off until the day after tomorrow.”

Granted, I can be incredibly productive at times. So much so that I’m generally considered a “high output” person. But when I read The 7 Habits of Highly Effective People, I only got as far as the first one!

What I most remember from the book was the its focus on the Character Ethic and, especially on integrity.

Now, I’m not sure that I’ve found a good dictionary definition of integrity, but I love Alan Simpson’s quote on the subject, “If you have integrity, nothing else matters. If you don’t have integrity, nothing else matters.” Although the business world is frequently full of cutthroat competition and questionable behavior, I have to, in the end, agree that Simpson’s quote applies even to industry.

It is true that the business world can be a mean place. Our competitors are trying to “kill us.” I would love nothing better than to “crush them”. They’re trying to “take away our air supply.” We’re “gonna hit ‘em where it hurts.” It’s easy to see how the urge to succeed results in violent language.

Despite the uncouth exterior, there is a certain nobility in business, too. There are simply some things you don’t do. Some, like bribery and “side letters” you don’t do because they might land you in jail. Others you don’t do because, at the end of they day, they end up hurting you. Consider:

Although companies are frequently guilty of these, I think that most CEOs will tell you that these are, at the end of the day, tactics that end up hurting them. You can go out of your way to sell your product, but if can’t do what it claims, the customer will ultimately figure it out and be very unhappy with you. You want to get as much money as you can from a customer but no more! If a customer feels that they overpaid and if they learn that others inexplicably paid less, it will be very difficult to sell to them again.

Ultimately, it is good business to act with integrity. One of my company’s greatest assets is that we’re “nicer” than our competition. Our competition will try to push unnecessary products or will flat out lie about us to try to win deals. More often than not, this behavior has actually helped us. Nobody wants to buy from someone they don’t respect.

It pays to be be kind.

What can Microsoft do to reverse the trends that I’ve talked about in the last 4 posts? First, let me admit that it’s possible that Microsoft accomplish this by doing what it’s always done: grinding it out. Keep investing in Windows Mobile; keep pouring money into MSN; invest some serious money in the Zune business. Sheer grit and determination can overcome many missteps. If Microsoft can persevere, they can wait for a competitor to make a major mistake and then step in and take up the slack. The Sony PS3’s strategy for online gaming is an excellent example of this. Sony made a bad decision and the XBox business was able to profit from it.

If I sat on the Microsoft board, however, I would be very nervous counting on the “grit” strategy. I would be looking for bolder ways to transform the company while it is still healthy and dominant. As I suggested in the first installment of this series, I think Microsoft has to start by asking itself the ultimate TQC question: what is it doing wrong that is causing it to generate bad processes? “Processes” here can refer to many things. Product design and software development processes are obvious places to consider but I think even more important are strategic planning and basic financial processes.

Here are some of my answers to these questions based on 10-year old knowledge and interpolation with what I hear from friends who are still at the company:

1. Project planning is resulting in poor products because the company has too many people involved in the design process. Microsoft Vista had dozens of program managers working on it. Microsoft Excel 1.0 had 1 program manager on it. Is the difference between Windows XP and Vista 50 times more complex to manage than Excel 1.0? If so, that’s probably a sign that you’re doing something wrong.

Update 6/19/2008 - I’m told by Microsoft folk that my numbers are way off here, that it was more like 10,000 developers and 1,000 program managers. I just can’t fathom these numbers so I’m going to pretend that there were 1,000 devs and no more than 100 PMs that mattered.

2. Complex products require huge development teams. There’s simply no efficient way to integrate the work of 1,000 developers. If you can’t do daily builds and if developers have to wait weeks for their checkins to appear in public builds, you’re doing something wrong.

3. Thousands of developers and testers coupled with dozens of program managers require large product units and even larger business units. If your business units are large, few people in the unit will truly feel “P&L responsibility”. If a unit fails to meet its goals, the BUM may feel the pain but the 2,000 people who work for him/her are not going to get fired and probably won’t even see smaller bonus checks. On the other hand, if you have too many business units, you’ll inevitably end up with overlap and turf wars between them.

4. When a company is as large as Microsoft, central planning is impossible. You can set broad goals but there’s no way that the Chairman and CEO can know enough about all their businesses to be able to contribute much to their strategies.

There’s a common thread that runs through all of my observations: Microsoft is simply too big. Its size results in poor planning, bad financial management and excessively complex products/projects that are impossible to manage.

Just like the Roman Empire, I think it’s time for Microsoft to split itself up - even more so than Rome/Constantinople. Windows, Windows Mobile, XBox, MSN, Windows Live, Applications, Hardware: each of these should become a completely separate entity. Each of them should have its own CEO and its own stock. More importantly, each of these should be its own financial entity. They can start out with a good “stake” from the parent company, but each would have to demonstrate its own profitability or go out of business. Can you imagine the MSN Company trying to fund a leveraged buyout of Yahoo for $40B+ if it only had $4B in the bank? A smaller company would never contemplate such a boneheaded move.

Ideally, each Baby Bill would start out with 1,500-2,000 people.  I suspect that over time, several of them would shrink in order to maintain their profitability. The “parent” company could, perhaps, keep the Windows business and Microsoft Research and could provide services to the others in order to avoid needless duplicating infrastructure.

The companies would still have the problems I’ve been describing. The Microsoft brand would still be less cool than Apple’s; Microsoft would still need to improve its management culture; Microsoft would still need to learn how to succeed in areas other than technical prowess. The Baby Bills, however, would allow managers more freedom to experiment and would provide more incentives for success and more penalties for failure. Removing the $20B+ safety net would make Microsoft a more dangerous place to work and, I think, Microsoft would benefit greatly from it.