Archive for May, 2008

Programming is Fun (Again)

Saturday, May 31st, 2008

I’ve been programming since 1975 and, boy, are my arms tired 🙂

Throughout these times, I’ve seen numerous developments that have made programming easier or harder. Consider this:

I first started programming when I was 15 years old. This was on a Univac 1108 running an interactive BASIC interpreter. As this was my first development environment, I thought it was great. I wrote a cool football game. Call the score +1.

The following year, I took a Fortran class where we had to punch card decks and wait several days for our output to be returned. Life without a “backspace” key is very painful. Running score: -5.

My first “microcomputer” was a Scelbi 8H (Intel 8008) computer. I had to enter machine language programs (hand assembled) using front panel switches in a very, very, primitive way (even more so than on the Altair or PDP 8 or other front panel computers). Running score: -20.

The arrival of the Altair 8800 greatly improved things. I used Microsoft BASIC and was able to store programs on big 8″ floppy disks instead of unreliable cassette tape. Running score: +10.

In college, it was back to punched cards on an IBM 360. At least we got to prepare our “virtual card decks” on a 370 running VM/CMS and we got back our results in an hour or two. Life is much better with a backspace key. Running score: +5. 

Worked on an Apple II running UCSD Pascal. Color graphics, a cool IDE and the first incarnation of “DLLs” (Pascal packages). Running score: +20.

Went to work at HP. First used HP3000 to cross-compile Pascal to x86, but then started using IBM PCs and Lattice C compiler. Used Microsoft “debug” program at first and then Microsoft CodeView. Great stuff. Running score: +50.

Got a job at Microsoft. Started writing C++ code using cfront based compiler. Lots of multiple inheritance, virtual inheritance, templated classes. A one-line C++ constructor call turns into a 75 line C statement with about 120 comma operators. Program takes 7 hours to build. Writing Windows applications requires message loops and wndprocs not to mention dealing with near, medium and far pointers. Running score: +25.

We (I was in the Developer Tools group) deliver QuickC for Windows and Visual C++ 2.0 for Windows NT. We say goodbye to 16-bit applications. We deliver MFC and we facilitate “visual programming” in order to make Windows programming easier. Running score: +40.

Everything goes OLE/COM. The ATL library is released to help with COM. Running score: +25.

I leave Microsoft. Microsoft releases C# and .NET. Writing Windows applications is really, really, easy now. The .NET interop stuff makes COM a little easier, too. Not having to worry about memory overwrites and leaks: priceless. Running score: +40.

I start Likewise Software (Centeris, back then). Microsoft releases .NET 2.0 and MMC 3.0. It becomes ridiculously easy to write complicated applications that combine Winforms applications, web services, database access, LDAP access and just about anything else that you can think of. Running score: +100.

At the risk of sounding like a crusty old programmer, today’s programmers don’t know how good they have it. It’s rare for me to find a developer who can code an insert-into-a-sorted-singly-linked-list function without screwing up a corner condition or two. This isn’t surprising – who cares about data structures and standard algorithms anymore when you can declare a List<string> and then call the List.Sort() function? Who cares whether the sort is amortized on the insert or performed repeatedly every time you call Sort()! CPU cycles are cheap and plentiful.

There has been no better time to be a software developer. It is possible to develop insanely complicated applications by building on top of existing components. Todays compilers, editors, debuggers and run-time libraries are a joy to use compared to their predecessors.

By the way, unless you worked at Borland or in the Developer Tools group of Microsoft you probably don’t know that a lot of praise is due to one particular person who’s made a lot of this goodness happen. In the 1980s, Anders Hejlsberg developed Turbo Pascal. Turbo Pascal took everything that UCSD Pascal had done earlier and did it much better. It provided an IDE that integrated an editor and an extremely fast compiler. Beyond this, however, Turbo Pascal provided a run-time library that was the work of genius. Instead of having to call into the operating system or manipulate the hardware directly, 9 times out of 10, the library had exactly the functionality you were looking for.

At the time, I was working in the Developer Tools group at Microsoft and Borland was our arch enemy. Borland released Turbo C – a great product on its own – but we were lucky that Anders never turned his attentions to C. While Microsoft eventually won the C++ battle (mostly, through the introduction of Visual C++ and MFC), Anders turned his attentions to Delphi. Delphi did some extremely clever things to make forms-oriented Windows programming easier.

Microsoft ultimately hired just about everyone from Borland: Brad Silverberg, Paul Gross and Sin Lew, for example. A couple of years later, at considerable cost, Microsoft finally hired Anders. Anders became the architect of C# and a key contributor to the .NET initiative. If the ACM would bother to look beyond academia, Anders would be a prime candidate for a Turing.

What Linux Needs To Learn From Windows

Friday, May 30th, 2008

My company (Likewise Software) develops software for UNIX, Linux and Mac OS X. Our code is system-level, infrastructure, software. It interacts with the authentication components in the OS in order to allow users to login to these non-Windows systems using their Microsoft Active Directory credentials. By supporting single username/password and single sign-on and by supporting Windows-style “group policy” on non-Windows systems we can greatly facilitate account management, greatly improve security and greatly improve the odds that companies who use our product will comply with SOX, PCI and other regulations and standards. 

Writing this software in order to support 110+ software platforms is a bitch and the bitch’s name is “Linux”. Her sisters “UNIX” and “Mac OS X” aren’t gals you’d take home to meet mother, either. Here’s why.

(Note: my apologies for the misogynistic literary device. No offense intended.)

All flavors of Linux start with a common base: Linus’ kernel, currently version 2.6.XXXX.  Of course, there’s still plenty of Linux in use that is based on an older kernel, 2.4.XXXX. The kernels are a little different. The run-time libraries associated with them might differ; the threading might be a little different but if that was all I was complaining about, you’d be right to accuse me of whining.

Although Linux distributors start with this common base, they all go on to add their own special sauce to distinguish their product from others’. In the US, we have Red Hat, Novell (SuSE) and Ubuntu (a Debian variant). We also have Oracle Enterprise Linux and Centos (Red Hat variants) and VMWare ESX (Red Hat 3 variant) to consider. In Europe, you add Madriva to the mix while in Asia, you have to take Asianux and its derivatives (Red Wall, etc.) into account.

Each distributor typically writes their own installer and, rightfully so, competes on the basis of how easy they can make the installation process. Alas, installation involves choosing (directly or indirectly) which additional packages need to be installed. At this point, things begin to get messy because some systems use rpm packaging and others use deb packaging. Although all distributors include a similar set of packages in their pools (including things like Apache, Samba, MySQL, etc.) they sometimes choose to include different versions of these packages with their distributions. Sometimes, out of pure spite, some packages (e.g. Mono) are excluded by one vendor because they were developed by another whom they don’t want to support.

Even at this point, the situation is not too bad. You’d still date the gal – she’s good looking and she has a nice personality, even if she tends to dress in stripes and polka dots.

Where things begin to get complicated is when you’re writing software that’s anything but trivial. You say you want to write a graphical application? Are you going to write it for KDE or Gnome (the two most common desktop managers in use in Linux)? Maybe you should write it using GTK+? Maybe you should use Mono so that you can use Visual Studio for both Windows and Linux development.

You say you want to write some system software (like we do)? Be prepared for differences in:

  • System initialization sequence 
  • Daemon scripts (/etc/init.d)
  • Networking mechanisms
  • “Hardened Linux” mechanisms (SELinux, App Armor)
  • Network firewall management
  • System management infrastructure

Inside every Linux application lives a big, complicated, “if” statement that has to deal with special cases for each distribution and release of Linux. I’ve written the same statement for Windows 95/Windows NT/Vista – trust me, it’s not as complicated.

Now that you’ve noticed that Ms. Linux has a bad case of acne, you might as well consider her sisters. Forget UNIX. The differences between Linuxes is nothing compared to the differences between HPUX, AIX and Solaris. Consider Mac OS X. She’s clearly adopted.

Mac OS X is based on FreeBSD, not Linux. Everything listed above is different on the Mac, too. We do a lot of work with PAM and NSSWITCH. At least, all the UNIXes and Linuxes have PAM and NSSWITCH (okay, AIX 4.x has LAM, but close enough). The Mac doesn’t have these components – it’s replaced with the the Mac Open Directory API. A pretty cool API, but nothing like its siblings.

It’s tempting to position Linux and Mac OS X as Microsoft killers. Microsoft has its shares of problems which Vista has done nothing but accentuate.  We’ve seen increased numbers of Linux desktop projects and Mac OS X machines showing up in “the enterprise.” This is just one of the factors that is driving an incredible amount of business in our direction. Nevertheless, I think that the operating system business is still Microsoft’s to lose. The competition is, at best, a hodgepodge of uncoordinated attempts to define an alternative to Windows.

Is there any hope that a single other OS will displace Windows? If this is to happen, I think it must be preceded by several things:

  1. IBM and HP need to continue to promote Linux and phase out AIX and HPUX.
  2. Sun needs to give up on Solaris/Open Solaris and get behind Linux.
  3. The Linux foundation or some other more effective organization needs to drive more forcefully towards a widely accepted standard Linux. The “standard” needs to go beyond the kernel. We need blessed “stacks” of components and we need agreement on all the areas of difference that I mentioned earlier. Most significantly, we need a standard GUI stack, window manager, desktop, and system management API (By the way,  Linux and UNIX, for the most part, don’t even have a system management API. There are things like Yast, WBEM, ZenWorks and WS-Management floating around but none of them has any wide acceptance. For the most part, management applications just muck directly with system configuration files.)

This, at least, would result in making Linux a more credible alternative to Windows. Mac OS X, would still remain an outlier. There’s very little likelihood of Apple releasing Carbon into the public domain. This is a tragedy as Mac OS X is much, much, better positioned to challenge Windows on the desktop.  Although Mac OS X Server is a fine operating system, it doesn’t help sell any IBM, HP or Sun hardware. Apple’s iPod/iPhone cachet does not buy it anything in the server business.

The answer to my question then is “no, there is no hope that a single other OS will displace Windows.” At least, not unless Apple decides to go totally open source and to port Mac OS X to Linux and make all of its API available under GPL or similar license.

The Decline and Fall of Microsoft? Conclusion.

Thursday, May 29th, 2008

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.