A few years later — in 1982 — my close friend Wayne Holder hired me into his nascent software company, Oasis Systems, in part to help with his existing and planned word processing utilities (The Word Plus, Punctuation + Style), but mostly to develop computer games. And we did, developing Sundog: Frozen Legacy on the Apple II, a game for which I still get e-mails (and which Wayne is even now working on resurrecting for modern platforms). In January 1984, a few months before Sundog shipped, we were invited by Guy Kawasaki to come up to Apple to see a preview of the Mac and to talk about what software we could port to the Mac. Through my connections with computer stores in San Diego, I was able to get a personal loan of a Mac for a few days at home prior to the official announcement in Cupertino later that month, which Wayne and I attended as well. That was my first time seeing Steve Jobs in person, and it remains a memorable highlight of my professional life.

When the Mac shipped a few days later, I went down to the one computer store in San Diego that I knew would be getting machines from Apple. I took $3000 in cash with me and managed to convince the store owner — a friend — to let me have one of the three Macs he had to sell. Through a connection with Phil Lemmons — editor-in-chief at BYTE — I ended up writing the official BYTE review of the 128K Macintosh (August 1984 issue). By the end of 1984, I was writing full-time for BYTE, including on-going coverage of the Macintosh, particularly once my BYTE column started in mid-1985. After a few years of writing for BYTE, I switched to writing for Macworld magazine. Steve was now long-gone from Apple, and Apple was having some of its own problems going forward.

But in late 1987, I was contacted by Addison-Wesley. They were interested in having me write a book about Steve Jobs’ new project at NeXT. Folks at NeXT had apparently suggested me to Addison-Wesley, probably due to my writing at BYTE and Macworld. I leapt at the opportunity, particularly since in coincided with our family moving from Utah to just outside Santa Cruz (where I would be doing technical writing for Borland on a consulting basis). Once there, I found myself invited to visit NeXT HQ on Deer Creek Road, sit in on meetings, and attend the 0.3 NeXTstep Dev Camp. And, yes, that meant getting actual face time with Steve Jobs as well — not a lot, but this was a man whose creations had been impacting my personal and professional life for over a decade at this point.

The writing of the book dragged out as I waited to get my hands on an actual NeXT cube, which finally happened (if I recall correctly) at the end of 1988 or early 1989. I wrote the first several drafts of the book on that NeXT cube itself. The book came out in the fall of 1989; it remains the single most successful book I’ve ever written, due to the intense interest in NeXT itself, more than any particular writing skills or technical insight on my part.

The following year, I found myself working with a world-class typographer (Mike Parker) and graphic designer (Vic Spindler) to create a design-oriented desktop publishing system. I was doing all the software prototyping on my NeXT cube, and we made the decision to make the NeXT our first target platform. For five years — 1990 to 1995 — I served as chief architect and CTO at Pages Software Inc, where we developed Pages by Pages and then WebPages, while spending nearly two years just trying to raise venture funding. We closed on funding at the start of 1992 and shipped our first version of Pages in early 1994. We quickly sold all that we were going to in the all-too-small NeXTstep market. My frustrations at seeing larger firm try to leverage off of NeXT’s incredible innovations led to an op-ed piece in the November 1994 issue of BYTE, “Whither NextStep?” The day that issue came out was the last time that Steve Jobs and I spoke — he called me from the back of a car somewhere to ask me what the hell I was doing writing that. I said, telling the truth. Pages would close its door the next year, unable to secure additional funding to move its technology to Windows.

When Steve engineered his brilliant reverse takeover of Apple — getting Apple to buy NeXT for $400 million, then slowly moving himself into the CEO seat — I was not optimistic. I still had unconditional praise for the NextStep technology, but I was dubious about Steve’s ability to sell technology to markets and to compete with Microsoft.

Boy, was I wrong. I was not only wrong about his abilities at Apple, I was wrong in my BYTE article about NextStep being on a downward slope. NextStep, of course, was the foundation of Mac OS X, and Steve transformed Apple into the most-admired, most-imitated, and most-valuable company in the world. And I was tickled that, when Apple brought out its own word processor, it was named “Pages”. Steve had always liked that name when we were developing (and shipping) our own product years before; glad he was able to use it.

To quote John Perry Barlow over on FB, “The world is suddenly a less interesting place.” ..bruce w..

[1] The first was an HP-67 card-reading programmable calculator.

[Cross-posted from And Still I Persist]

Over the last forty years, a small set of classic works on risks and pitfalls in software engineering and IT project management have been published and remained in print. The authors are well known, or should be: Gerry Weinberg, Fred Brooks, Ed Yourdon, Capers Jones, Stephen Flowers, Robert Glass, Tom DeMarco, Tim Lister, Steve McConnell, Steve Maguire, and so on. These books all focus largely on projects where actual software development is going on. A new book by Phil Simon, Why New Systems Fail, is likewise a risks-and-pitfalls book, but Simon covers largely uncharted territory for the genre: selection and implementation of enterprise-level, customizable, off-the-shelf (COTS) software packages, such as accounting systems, human resource systems, and enterprise resource planning (ERP) software. As such, Simon’s book is not only useful, it is important.

Go read the whole thing. ..bruce..

Well, now I’ve been hired by Ziff Davis Enterprises to write a weekly column on IT Management for the online version of Baseline. That column is titled “Surviving Complexity” and, again, draws upon work I’m doing for the book. My first column is up: “Lies, Damned Lies, and Metrics (Part I)”; here’s the opening paragraph:

When Capers Jones published Assessment and Control of Software Risks (Yourdon Press, 1994), he identified the most serious software risk in IT projects as “Inaccurate Metrics,” and the second most serious software risk as “Inadequate Measurement”. I remember being startled when I first read that back in 1995—they certainly weren’t what I would have chosen—and other authorities in the field criticized his choices. Yet, in the intervening years, I have moved closer and closer to Jones’ point of view.

I’ll still be writing here, both with materials relevant to Surviving Complexity and with my on-going revisions to The Art of ‘Ware. But please feel free to check out the new column. Thanks. ..bruce..

So, why would IT engineers leave one of the most highly regarded, high-quality, and successful IT organizations on the planet, viz., Google? This collection of ‘farewell’ notes from departing Google employees gives some clues (hat tip to Valleywag):

For the last two years, I have had a fantastic time helping to build Google Webmaster Central. I have loved working with the (ever-expanding!) team, writing about search on the blog and for the help center, and designing features for the webmaster community. (…) Now I have an all-new opportunity to work on the unique challenges of the vertical and local search space at Zillow. (…) Making the move was a very difficult decision, but the challenge of creating something new in a space that’s so young and evolving was too great to pass up.” (Vanessa Fox, Google Webmaster Central Product Manager – June 14, 2007)

“Today’s my last day as an employee of Google. I’ve been on leave since December, so it’s not really a big change this day. But now the decision’s made. It feels a bit strange leaving such a great and productive company. But I’m ready to do something new with a smaller group of people.” (Nelson Minar, he created Google’s first APIs – April 7, 2006)

Valleywag summed it up as “to be in charge”, but the postings also make it clear that in many cases it has to do with the size of the organizations. Setting aside my own firm, I’ve worked for organizations ranging in size from 2 employees to over 150,000 employees (PricewaterhouseCoopers in the 1999-2001 timeframe); I still lean towards the smaller size. I suspect in many cases there is a third reason as well: a shot at more valuable stock options, particularly for those who joined Google relatively late.

On the other hand, The Secret Diary of Steve Jobs has a somewhat harsher (though not necessarily incompatible) take on it about a month ago:

You’ve got these weirdly smart and semi-nasty super-spoiled children who really believe they’re superior beings who shouldn’t have to work too hard and who really don’t take criticism well (because they’ve never received any in their sheltered little lives, and it just totally knocks them on their ass) and on top of all that they are almost entirely incapable of focusing on anything for more than a few minutes at a time. You’ve got an entire corporate culture built on ADHD and entitlement. Nice work, frigtard.

Plus you make a big deal of only hiring these super-high-IQ kiddies and the fact is that most of them truly are smart, but then you put them into this horribly dull and easy drone work on AdWords and AdSense and they’re all bored to tears and totally disappointed because they really really really thought they were going to do something meaningful with their lives and now they’re just worker bees — pampered worker bees, sure, but still — and maybe they should have taken that offer from McKinsey but they really thought Google was going to be so cool and blah blah blah.

So, maybe it’s the Dead Sea Effect after all — just on a much higher level. ..bruce..

[Copyright 2008 by Bruce F. Webster. All rights reserved. Adapted from Surviving Complexity (forthcoming).]

As new technologies become hot markets, the number of skilled developers is small, and they command high salaries. For example, in the software industry this has been true at various times for 8086 assembly, Windows, C++, OLE 2.0, object-oriented development, Java, .NET, Python, and subsequent technologies. Each area fills in with time as sustained demand and high salaries draw more engineers into it. But, curiously enough, the absolute number of excellent developers in a given area of technology remains pretty much the same.

When I was teaching computer science at Brigham Young University in 1985-87, the number of students enrolled as computer science majors had increased dramatically — by a factor of five or so — from when I had been a student there a decade earlier. One of the professors, who had been around since the early 70’s, observed to me that the number of really good students in the department was still pretty much the same; the five-fold growth of enrollment hadn’t brought a five fold, or even a two-fold, increase in excellent CS majors. Why? Because those students with interest, aptitude, and native talent has been signing up all along; the surge in enrollment had come from students who saw computers as a way to get a great paying job, much as my friends during my undergraduate days had signed up for pre-law or pre-med.

When a new, powerful technology emerges, the best and the brightest are the ones who rush in there first. They are the ‘early adopters’ and they quickly master the technology. Other IT engineers follow suit as acceptance of the technology grows — but many of them will not be as talented or capable. The number of truly excellent developers for that technology increases quickly, then increases slowly, then finally levels off, achieving something of a steady state, with some excellent developers moving on to newer technologies as other excellent developers come to that technology for the first time. Think of a pool of water with several streams flowing in and several more streams flowing out, keeping the pool level itself steady.

Because of this, I’d like to propose a minor addition to the vast assortment of laws and rules governing technology and engineering:

• The Expert Pool: the number of excellent developers in a new area of information technology quickly reaches a constant value, which is sustained through the period during which the technology is vital, then slowly declines as the technology becomes less relevant.

This is actually a corollary to the apparent fact that there is more or less a fixed number of really excellent developers in IT.

Note that it isn’t always the same excellent developers who move on each time. There are always new developers (excellent or otherwise) entering IT and old ones leaving (or dying). Many excellent developers remain with a given technology due to job or career demands (or choices); they stay in the pool, so to speak. Some developers become expert in that technology by virtue of the amount of time they spend in the pool.

The upshot, however, is that most organizations seeking outstanding talent in a given technology are going to be competing for the same limited pool of experts. Anyone who had done extensive recruiting for a given technology knows the phenomenon of seeing the same names show up again and again. Often these experts end up as consultants, authors, and/or conference speakers and may thus take themselves out of consideration as a full-time employee.

Two disappointed believers,
Two people playing the game.
Negotiations and love songs
Are often mistaken for one and the same.

– “Train in the Distance”, Paul Simon

I used to have arguments with Carol Teasley, one of my mentors, regarding software development methodologies. She contended that there were no really good or effective methodologies, because if there were, everyone would use them and they would work. I, in turn, contended that there were several effective methodologies, but that they were just badly applied for the most part.

Then while watching the movie “A Beautiful Mind” (about Nobel Laureate John Forbes Nash, a brilliant mathematician who struggled with schizophrenia), I was struck by the sequence that represented (not entirely accurately) some of his insights about game theory and multi-player equilibrium points. It occurred to me that software development within a typical corporate/government organization is really an instance of multi-player game theory, with several general classes of players. The real issue in organizational software development is not the development methodology being used. That methodology, at best, is necessary but not sufficient for a successful project; it may actually be irrelevant, and at worst it may be a hindrance.

The real issue is the game that’s being played.

Organizational software development, I believe, can be thought of as an n-player game, where each set of players has voiced and unvoiced (and possibly even unconscious) goals, many of which are incompatible with those of one or more other players.

At the most abstract level, the fundamental division is among IT developers (Geeks), upper management (Suits), and end-users (Users). Put very roughly, the Geeks work as if they’re playing Halo, the Suits work as if they’re playing poker, and the Users are just trying to balance their checkbooks. The result is that the three groups mostly baffle and frustrate one another; they can’t even agree on what game they’re playing, much less what constitutes winning.

Adding to the problem is that each group has generally negative perceptions of the other two, which in turn shape the games. For example, Geeks tend see Suits as “marketing weasels” who make impossible promises (to Users) or demands (of the Geeks) that the Geeks can’t possibly meet. Geeks look upon Users with a mixture of condescension and dismissal, though that elevates to horror and dismay if the Geeks have to directly provide tech support to the Users.

Suits tend to see Geeks as overgrown, naive, but possibly bright children who never actually deliver anything. They tend to see Users as annoying sheep, except when the Users control the purse-strings, at which point the most far-fetched User demand is seen (and portrayed by the Suit) as eminently possible.

The Users tend to see Geeks as irascible wizards who may or may not deliver the magic necessary to make their own lives easier. They tend to see Suits as corrupt nobles who hold not just power but also the wizards’ collective leashes.

Now, these are of course blatant and gross oversimplifications, but ones with a foundation in reality; were it not so, the Dilbert comic strip would have died a quiet death long since.

My next set of posts will look a bit closer at these abstract classes (Geek, Suit, User) and then will look at some of the real-world patterns (internal development, external development, and so on).

When funds are exhausted, then money is raised under pressure. Control is lost and equity surrendered to supply the needed resources.

One of life’s great ironies is that the worst time to raise money is when you really need it, because that’s when you agree to the most unfavorable terms. The logical conclusion, then, is to start working raising money well before you need it. If you end up not needing it, so be it; but if you do, you will have done the work in advance. That’s also important, because it takes time to raise money.

Try to gain resources from the competition. Each dollar gained from or spent by the competition is worth two dollars raised and spent by yourself.

You can leverage off your competition by learning from their market research, analyzing their plans and products, and buying their technology. Chapter 13 (”Gathering Intelligence”) will have more details and ideas.

Reward employees who recruit from competitors. Merge those recruits with your own and win their loyalty. This is called weakening the competition while increasing your own strength.

If your developers had wanted to work long hours just for lots of money, they would have become lawyers. They do it for bragging rights — for the right to say, “Yeah, I helped create that product” — and for a chance to change the industry and maybe the world. It may be hubris, but then again, the world really has changed because of products created by technology developers over the last fifty years — and the most dramatic changes are yet to come.

==========================

Compare suntzu pingfa (Chapter 2: “Doing Battle”):

Take equipment from home but take provisions from the enemy.

Then the army will be sufficient in both equipment and provisions.

When all strength has been exhausted and resources depleted, all houses in the central plains utterly impoverished, seven-tenths of the citizens’ wealth dissipated, the government’s expenses from damaged chariots, worn-out horses, armor, helmets, arrows and crossbows, halberds and shields, draft oxen, and heavy supply wagons, will be six-tenths of its reserves.

Therefore, a wise general will strive to feed off the enemy.

One bushel of the enemy’s provisions is worth twenty of our own, one picul of fodder is worth twenty of our own.

Killing the enemy is a matter of arousing anger in men; taking the enemy’s wealth is a matter of reward.

This is called defeating the enemy and increasing our strength. (Sonshi translation)

=============================================

[From The Art of ‘Ware (Version 2.0) by Bruce F. Webster (forthcoming), Chapter 2, “Supporting Development”]

In key areas of technology development, talent is scarce and salaries are high, limiting resources for other employees.

As new technologies become hot markets, the number of skilled developers is small, and they command high salaries. For example, in the software industry this has been true at various times for 8086 assembly, Windows, C++, OLE 2.0, object-oriented development, Java, .NET, Python, and subsequent technologies. Each area fills in with time as sustained demand and high salaries draw more engineers into it. But, curiously enough, the absolute number of excellent developers in a given area of technology remains pretty much the same.

When I was teaching computer science at Brigham Young University in 1985-87, the number of students enrolled as computer science majors had increased dramatically — by a factor of five or so — from when I had been a student there a decade earlier. One of the professors, who had been around since the early 70’s, observed to me that the number of really good students in the department was still pretty much the same; the five-fold growth of enrollment hadn’t brought a five fold, or even a two-fold, increase in excellent CS majors. Why? Because those students with interest, aptitude, and native talent has been signing up all along; the surge in enrollment had come from students who saw computers as a way to get a great paying job, much as my friends during my undergraduate days had signed up for pre-law or pre-med.

When a new area of technology opens up, it quickly draws to it those developers with the interest, talents and desire to become really good in it. More excellent developers do come along with time, but as they do, some of the current ones start moving on to new areas, so the absolute number stays more or less constant.

Because of this, I’d like to propose a minor addition to the vast assortment of laws and rules governing technology and engineering:

• Webster’s Constant: the number of excellent developers in a new area of technology quickly reaches a constant value, which is sustained through the period during which the technology is vital.

This may seem a bit silly or fatuous, but it’s actually critical to understand if you need to build a development team that will be working with key technologies. It’s going to be tough finding really good people, and you’ll find yourself running into the same names over and over again. The trick is getting them to come to work for you.

==========================

Compare suntzu pingfa (Chapter 2: “Doing Battle”):

A nation can be impoverished by the army when it has to supply the army at great distances. (Sonshi translation)

When a company is drained by competition, it is because product development and marketing have taken too long. Prolonged development cripples the company.

Developers can typically sustain a high level of energy for 18 to 36 months, depending on how hard they’re being pressed. After that, they start looking around for something new to work on. A project that takes too long getting out the door runs the danger of never shipping, because key developers keep leaving to work on something else, either within the company or outside of it.

There are other significant internal and external problems caused by prolonged development. People within the company begin to lose heart, bicker, and find fault with each other. Customers question the company’s ability to deliver products in a timely fashion. Competitors use your delays against you to win customers and sow doubt about you.

Even allies begin to doubt and may seek to distance themselves from you. During the very long year between our original ship date at Pages Software Inc. and and the date when our product (Pages by Pages) actually went out the door, someone at NeXT swore we’d never ship and said he’d eat a can of worms if we ever did. We did ship, on March 7th, 1994. We never heard if this person carried out his promise; we certainly kept our end of the bargain.

==========================

Compare suntzu pingfa (Chapter 2: “Doing Battle”):

No nation has ever benefited from protracted warfare. (Sonshi translation)