Passion and the Developer
Originally in Embedded Systems Programming, May, 1999.
By Jack Ganssle
I must be insane.
After writing a couple of books and some 200 articles, and responding to tens of thousands of emails from readers, there's one thing I've learned about crafting words for publication.
Every sentence that includes the word "Microsoft" absolutely must include some sort of disparaging adjective. Forget that, and my email server groans under the weight of angry letters from readers who accuse me of being a Microsoft stooge or shill.
So here it is, the insane declaration that is sure to doom me to months of email arguments and apologies: Microsoft is not Satan.
And (oh, dare I write this?) Microsoft has indeed been a force for good in the computer industry. Sure, the company has created at least their share of chaos and disruption, but, in my opinion, the dominance of an industry leader has often been good for users.
Consider the 60s, when IBM owned mainframe computing. IBM's might created de facto standards that greatly reduced the cost of running code. Sure, their prices for hardware and software were outrageous. But the prevalence of the 360/370 architecture that armies of programmers, operators and users knew those machines and associated OSes intimately. The user base always far outstrips the size of the oligopoly de jour, so the health of the industry comes much more from creating standards than from building elegant systems. Time has proven that successful designs are the ones so widely accepted that they promote vast levels of support, from third party companies, legions of trained programmers, and a wide array of tools.
And I believe that we have to recognize that, in a capitalist economy, successful is the operative word. Couple your star to a dead-end concept, no matter how beautiful, and you're gonna go out of business. At least most of the time. Capitalism is a harsh mistress that rewards no failures.
Microsoft's astonishing success with Windows mirrors the IBM of the 60s. Nothing is more important in a desktop OS than standardization. Performance, elegance, price or even reliability issues pale in comparison.
Was/is the Macintosh a better computer? Maybe, but give me an OS that lets me exchange files with most people, one whose tools are so universal that I can use a hotel's computer in Istanbul without reading manuals or trying to convert media formats.
Is Windows a "flawed" environment? Well, sure, it's buggy as hell. But the desktop is not mission critical. Treat it right - I prophylactically reboot three or four times a day just to keep things running well - and it's good enough to let us do amazing things.
When the personal PC revolution came along most of us predicted that computers would evolve to accommodate human styles and needs. None of us believed that we'd have to adjust our style of work to match the computer's methods. We were clearly wrong; spreadsheets and other undreamed of tools changed the way we work. The glitches, problems, and aggravations inherent with very complex technology means that we're forced bend to the machines' needs to deal with the unpleasant realities of computing.
As someone who dealt with punched cards and 48 hour turnarounds a long time ago, I'm thrilled to have what amounts to practically infinite compute capacity on my desk. OK - I spend 5-10 minutes a day dealing with Microsoft eccentricities; the rest of the time this machine keeps me astonishingly productive. I made the decision years ago that those 10 minutes of frustration will not wreck my whole day. Commuting, computing, children's woes, burnt dinners and too many other annoyances all can turn our lives into purgatory, if that is the life we chose.
Of course I wish Microsoft built more reliable software. Yet, I'll be a lot of us have copies of Rapid Development, Code Complete, and other books on software development authored by Microserfs, published by Microsoft Press. If we really hate their code so much, why do people flock like lemmings to Computer Literacy to get their latest advice?
Developers complain bitterly about Redmond's code bloat. Who would have imagined that an Office suite might fill a CD? Yet even $1000 PCs now come with 8 Gb drives and 64 Meg of RAM. Is bloat an issue anymore!. or are we really complaining about the lack of elegance of such code?
Elegance is simply no longer an option in the bizarre and frantic desktop world. We consumers seem to demand new goodies; we feed the competitive frenzy that drives the market. No company can meet insane time to market goals while also crafting code that's an art form. If elegance is what we want, it's up to us to stop buying new apps every year or two. I dare ya.
Another complaint against Microsoft revolves around their predatory business practices. Just as I thought O.J Simpson and Bill Clinton should not have been tried in the press, I'll leave this to the Justice department. But it's like Deja Vu all over again. Justice attempted to break up IBM, costing the company 14 years of litigation, billions of dollars, and a lost focus that inflicted deep wounds. The government's successful attacks on AT&T greatly changed the phone industry! but the bottom line is that we still have good phone service, AT&T continues to thrive, and the Baby Bells now themselves have grown to gargantuan proportions.
Whether Justice breaks the company up or not matters little to me. The market will adjust to the new ground rules; software will still appear faster than we can absorb, bugs will continue to be de rigor, yet consumers will still get more computer power and more application flexibility than ever. Over time companies expand and contract, succeed and fail, but in the end we consumers are the winners. If Microsoft were shut down completely tomorrow, other organizations would rise to fill the void, and I expect we consumers would see very little change.
So I urge developers to abandon their rapid anti-Microsoft passion. Save it for something important, like global warming or the population explosion, where our lack of national passion is leading to a profoundly bleak future. Save it for something where you can make a difference, where you can harness the passion into effective action. Or if you just feel the need to complain, pick something that really effects your life - like taxes.
I have no interest in defending or damning Microsoft; passion about things that just don't matter in a profound way.
Embedded Microsoft
Till recently, we embedded folks have been relatively immune from the impact of Microsoft on the market. Sure, since the early 90s the swing to Windows has moved most of us from UNIX platforms to x86 boxes, but somehow we've remained below Redmond's radar screen. No longer. If we're to believe the hype, Windows CE is the RTOS of the future, and Microsoft will be the source of all things embedded.
I remain firmly convinced that some sort of GUI is inevitable for a large set of embedded systems. As I've written before (see June, 1998), the ever-decreasing cost of silicon coupled with pressures from the market and vendors will reshape our industry. As soon as your competitor adds a GUI to your TV remote control, some marketing weenie will demand a similar feature for your product. Count on it.
Will that GUI be CE? There are a lot of commercial GUIs available today, from reputable RTOS vendors which have a reasonable footprint, and are highly suited to traditional embedded applications.
But Microsoft is a force no wise developer can neglect. Though might does not make right, might can move mountains and reshape industries. And there are some very good reasons why a Windows-like API might help some embedded applications.
USENET CE discussions are depressing. Hysteria reigns; fear dominates; careful, rational thought is usually entirely absent. The CE discussion fascinates me partly because it brings even more fog to an area where people are just not thinking clearly. A lot of people tell me they can't use a commercial RTOS because of royalty costs! yet probably half of the products are royalty-free. Others complain about excessive memory footprints! yet I know of at least one that fits in the PIC's minimal memory model. Some say context switch times are too high, but can't tell me how much time would be acceptable.
We should make any OS decision using tons of reason, without passion. There are a lot of mighty fine commercial RTOSes available. CE is just one more option, with its own benefits and problems.
One valid concern expressed ad nauseum is people's worries about CE's reliability. If based on Windows code, developers are rightly worried that a CE-based product might behave just a bit too much like Win95.
Reliability is a valid business reason to select or reject an OS. I'd be awfully reluctant to put CE in any mission-critical application unless I knew a lot more about its heritage. But I sure would like to see some USENET discussions from people with real CE experience, who share their observations, the problems encountered, and their successes. These sorts of posts are notably absent, replaced by the rantings of the forever-anti-Microsoft crowd.
Though I think an embedded GUI I inevitable, and I think some sort of standardized API is necessary to its real success, to me it matters little if Microsoft or some other vendor wins the embedded user interface battle.
The most interesting effect of CE could be a third party's product with the CE API, reasonable performance, and a provably reliable set of code. That sort of product could be the best of all things for us developers. So, to the passionate anti-Microsoft crowd, here's a challenge that could let you do an OS right, and get rich in the process. It's a chance to convert your passion to action.
Intel
Having opened Pandora's box by not blaming all of the evils of the world on Microsoft, why not go for broke and address Intel as well?
Intel's own Andy Grove gave the keynote speech at the very first embedded systems conference, held at the wonderful Sir Francis Drake hotel in San Francisco a decade ago. His talk was entertaining and insightful. At question time a developer rose and asked "why did you guys create that lousy segmented x86 architecture"? Applause and hoots erupted from the room.
I blanched. What a stupid, irrational question! Grove probably didn't know enough about segmentation to make any sort of reasonable technical response, so the question was merely rude and provocative. But it also showed the questioner's misplaced passion. By the late 80s segmentation was without a doubt part of the fabric of Intel computing, and Intel clearly dominated desktop computing.
At the time I too was frustrated with the hassles of working within 64k address chunks, but had learned that compilers and other tools did a reasonable job of insulating me from most segmentation hassles. Sure, the 68k's wonderful flat memory space and symmetric instruction set was technically sweet, but in the desktop world, at least, the 68k had all but failed. The fact was that we had to deal with segmentation; like it or not, our passionate hatred of the Intel architecture effected no change and served only to annoy ourselves while Intel rolled in the profits.
Yes, the 8086 was technically flawed! but wildly successful. When I select a chip, I'd like elegant technology, but am more concerned with viability (will the part be available in 5 years?), development support (tools, and a cadre of available people who know the architecture), and other business issues. I balance my passion for cool with an understanding that the goal is to build a product that makes a profit.
That's why I like Microchip's PIC series. The PIC is a truly awful (in my opinion) architecture: many variants have virtually no memory and an awkward instruction set. Yet the wide range of parts available, the on-board program store, and low cost makes these chips ideal for very low end embedded needs, despite their technical flaws. Yukky parts, but wonderfully appropriate.
With time I've come to admire Intel's design. Their protected mode converted segmentation from a flaw to an admittedly complex significant benefit. Though most developers (pursuing their passion for a sweet flat address space) use protected mode to give them a single huge 68K-like segment, in fact by cleverly partitioning tasks into their own custom-sized segments one can build a wonderfully robust bit of code. Individual tasks can crash without taking down the rest of the firmware; smart task management can then take corrective action.
And, yes, I know Windows does partition programs into individual segments yet whole-computer crashes are common. The hardware protected mode resource is there for us to use well or use poorly. Lousy code marginalizes any protection scheme; good code (see QNX's OS for an x86 example) uses the resources correctly, and reliably.
Conclusion
They say politics is the art of the possible. So is engineering. We have to build something that works, that addresses a market need, and that satisfies enough business issues to generate a stream of products. Though idealism is wonderful, tilting a windmills is ultimately a waste of our lives and energy. In politics and in life there's a lot to be said for reserving passions for those things that cool normal">can happen, rather than those that cool normal">should.
The same goes for embedded systems. Reserve you passions for things that can make a difference. Focus on being a better developer, on learning new project management skills, not on hatred of Microsoft, Intel, or in that idiot in the next cubicle. The corporate behemoths care little, and hatred of any sort is ultimately self-destructive.
Make engineering decisions based on facts and solid reasoning, not emotional responses.
I just wish that I bought Microsoft when their stock was at $30! don't you?