Sunday Feb 04, 2007

Leaked memo from Michael Dell

This leaked memo from Michael Dell is fascinating. He details his new initiatives to turn the company around. I particularly like his emphasis on service revenue, since I am part of the group that is working to grow service revenue at Sun. Great idea, Mike!

Kudos to the Austin American-Statesman for obtaining the memo. 

Friday Nov 10, 2006

Moving to Marketing

 Remember the classic Dilbert cartoon where Dilbert is moved from Engineering to the Marketing Department? He's never been there before and doesn't know what to expect. As he approaches the door, he sees that it looks like the portico of a Las Vegas hotel. Over the columns there's a sign that says "Welcome to Marketing -- two drink minimum."  This has now happened to us. The Product Management department, which under the old SeeBeyond was part of Engineering, will now be part of  Marketing, as in the rest of Sun. Hot damn! Make mine a gimlet, with a twist.

Sunday Sep 24, 2006

Serving the audience -- segment by segment

Product management is closely related to marketing. Product managers are the bridge between the users and the developers. As such, we have the job of  making information about our products easily available to the users who need it, just as marketers do. The main difference between us and the marketing people, other than the fact that they dress better, is that we go into more depth with the information we provide to the users.

Since we provide information in great depth, we have to make it simple to get to, so that the users don't have to wade through a lot of stuff that they don't need. One way to do this is to segment the user audience. Segmentation often carries a negative connotation, as though it consisted of classifying people like widgets. But done right, it can be very useful to the audience, by giving them the information they are most likely to need.

I was recently asked to take over responsibility for another Sun web site, I was already running the Java CAPS site on,  so the first thing I had to do was to figure out what the different audiences were for the two sites. In other words, I had to segment them. I was fortunate to have some guidance on this from my bosses, and from others at Sun.

In a nutshell, we divide the broad developer audience into three segments: current users of  Java CAPS, Java developers who would like to learn more about the integration tools embedded in the Java SDK, and developers who would like to download or contribute code to the open source integration tools that are being developed with community participation. The Java CAPS user community will be best served by the Java CAPS site on, while the community around the integration capabilities of  the Java SDK will find more useful information at The open source integration community will find what it needs at various sites on Currently, some of this open source material, such as information about Open ESB, is still residing at Over time, we will migrate this to Of course, we will have lots of links between the sites, because our users often move from one community to another.


Friday Jun 02, 2006

Thinking about the elephant in the room

So, 5000 layoffs. Negative press. What are we to make of this?

I guess the main problem, when you strip away all the commentary from Wall Street analysts (whores with MBAs), is that we are in a commodity business. Sun derived about half of its 2005 net revenue from server sales, and servers are now regarded as a commodity.

I have an MBA myself, and the textbook strategy when you are in a commodity business is twofold:

1) Cut costs in an attempt to become the lowest cost provider;

2) Differentiate your product so that it is no longer regarded as a commodity.

The Wall Street guys have a disturbing tendency to concentrate on the first solution. This is natural, since it yields the quickest results, much like wearing a short skirt on Sunset Boulevard, the sort of strategy they can understand.

The second solution is more difficult, but pays much bigger dividends in the long run. Actually, we have been pursuing it for some time. Power-saving servers, multi-threaded chips, these are key components of the strategy of differentiating our servers. But as a software guy, I have to argue that our software is the biggest differentiator. Solaris is the best operating system on the planet, and all the other components that we are now bundling with it are further differentiators.

This is a big thing that Wall Street doesn't get. They say we are "giving away" Solaris and the rest of the stack. Huh? Come again? We are not "giving it away." We are just collecting for it in increased server sales, and by -- in effect --  leasing it out over time. You've been able to get a free trial copy of Oracle for years, and I don't see the Street complaining about that.

Yeah, 5000 layoffs is tough. But it has a valid reason. It's doing a little bit of the lower-cost strategy in order to buy more time for the product differentiation strategy to work. You can only raise the skirt so far. They know that on Sunset Boulevard -- why don't they know it on Wall Street?

Tuesday May 30, 2006

Culture clash at JavaOne

As Sun becomes more and more a software company, maybe it's time for us to think about who our audience is. This year, for the first time, former SeeBeyond customers got to go to the JavaOne keynote as part of their attendance at the separate Horizons conference for Java CAPS users. Here is what one long-time SeeBeyond user wrote on the SeeBeyond independent mailing list:

"The JavaOne Keynote session on Tuesday was a waste of time for us. There were little to no discussions on integration. It was definitely geared towards the Java eggheads ...."

Enterprise software is a different animal. It's more about stringing together off-the-shelf applications than slinging code. In a sense, JavaOne is a throwback to the glory days when software developers worked with nothing more than a box, an OS and a compiler. I should know -- I used to write COBOL for a living. That's why the Java-enabled cellphones they were selling there flew off the shelves. The cellphone is a bare-metal machine where you can still do scratch development. There is still a huge need for scratch development, but it takes place more and more at software vendors, and less and less in the end-user enterprise.

The enterprise CIO doesn't care about how easy it is to write code using NetBeans: to him writing code at all is a nuisance. He wants applications that work out of the box. Sun sells those applications now, and sells the systems that other vendors' applications run on. Maybe we should think about adding JavaTwo, just for CIOs.


Saturday May 13, 2006

Undocumented ATM API

I've always been intrigued by the idea of an undocumented API, one that perhaps could open up new areas of software functionality to you, if you only knew about it. There's a certain romance in the sheer danger of using something that only the pros know how to use, because they were the ones that wrote it. My customers often bug me for help on using APIs that we don't document. They seem to have mysterious ways of finding out about them, either through our personnel spilling the beans, or through decompilation and reverse engineering. As more and more software goes open source, there are going to be more and more demands from customers for documentation of the APIs that they discover, a subject that I have blogged about before.

Given this interest in undocumented APIs, I was quite amused today when my fat fingers uncovered an undocumented API in my bank's automatic teller machine (ATM). Since I've been banking with the same institution for umpteen years, and actually used to work there, this was something of a surprise. Here's how it works, in case you want to try it at your own bank:

The ATM has two columns of steel buttons located on either side of the screen. For any given choice of operations, little text boxes appear adjacent to the buttons, and you press the button corresponding to your choice. There is also a numeric keypad below the screen, which for the last decade or two I thought was used only for entering one's PIN number or the amount one wished to withdraw. Of course, you can also indicate the withdrawal amount by choosing one of the text box/button combinations that appear on one screen page: $20, 40, 60, 100, other, etc. You only need to use the numeric keypad if you want to withdraw an amount that isn't among the choices. You do this by pressing "other," then entering the amount on the next screen.

Perhaps due to early-onset Alzheimer's, I somehow started to key in the amount I wanted while I was on the wrong screen. It was at this point that something weird happened: the machine spat out money in spite of the error. It took me a while to figure out that there is an undocumented API: The two columns of buttons have an implicit numbering order:  1-2-3-4 down the left column, and 5-6-7-8 down the right column. Instead of pressing the button adjacent to your choice of operation, you can press the corresponding number on the keypad. However, if the choices are limted to yes/no, which appear (I think) next to the 6 and 7 buttons, you can use keypad 1 for yes and keypad 2 for no.

Maybe I'm getting a little too geeky here, but I find this to be pretty cool. I wonder if this feature is actually documented somewhere? Maybe it's for handicapped  accessibility, since (I think) the keypad numbers are also in Braille, and there are jacks for headphones. I wonder if the headphones give instructions based on numeric choices? I learned long ago that it is considered cool in the software world to use keyboard shortcuts instead of the mouse, so from now on I will try to do all my ATM transactions without lifting my fingers from the keypad. I will call this new system "ATM vi."   ;-)

Sunday Apr 16, 2006

The dangerous myth of "computer science"

"Computer science" is not a science, not in the purest sense, which is a system of inquiry for the determination of general laws. Instead, as Paul Graham has written, "Computer science is a grab bag of tenuously related areas thrown together by an accident of history." Now, myths can be benign, even comforting, like the myth that Texans are cowboys, or that New Yorkers are sophisticates. But myths can also be dangerous.

"Computer science" is a dangerous myth when it leads us to mistake effort for progress. We tend to think that a piece of software that was written five years ago, in an "old fashioned" language, is somehow less valid than one written today, in a newer language, because the one written today is somehow the beneficiary of a more advanced "science." This is absurd, because down at the level where computer technology has some claim to be a science, both programs will draw from the same set of machine instructions.

I once worked for an outfit that wrote the same piece of enterprise software three times, each time in a more "modern" fashion, using different languages, and each time the gain in functionality was minimal. If they had spent those hundreds of man-years on making improvements that customers actually cared about, instead of following the latest fashions in "computer science," they would have been wildly successful. Instead, they alienated what had been a very loyal customer base, and never made much money.

I think we would all be better off if we began to regard our profession as more of an art than a science. Artists don't throw away the past -- they build on it.

Tuesday Mar 28, 2006

Interesting takes on Windows Vista

There's a great article in the New York Times of 27 March 2006 about the delay in shipping Windows Vista, filled with inside information. The authors lay the blame largely on Microsoft's efforts to provide backwards compatibility, but also touch on its sheer complexity. I was led to the article by an opposing view published by Eric Raymond on his blog. Eric takes the view that closed source is to blame.

I've long been fascinated by the problems inherent in developing very large, complex projects, whether software, aircraft or skyscrapers. From my time in the software industry, I've come to believe, though I can't prove it, that the success or failure of large, complex projects is dependent on the number of interdependencies between the components, and that reducing the number of these interdependencies through architectural discipline can greatly improve the chances of success. This is certainly not a novel idea, but it is astonishing how seldom it is taken into account in designing a project. The reason for this may be that even the best modular architecture is worthless without management discipline to keep the builders from introducing unauthorized dependencies. One reason that airplanes and skyscrapers are more successful than large software projects is that the need to have an airframe structure or a building skeleton imposes a coherence on the design that is not present in software unless the architects and managers impose it themselves.

Sunday Mar 19, 2006

Sun was NBC. Now it's HBO.

An old style commercial television network, like NBC, is constantly in search of the next hit show, since commercial time on a  hit show can be sold for very high fees. A traditional software company works the same way, always searching for the next hit product that can be sold at a premium. At the same time, there is a terror of spending a fortune on developing a new product that doesn't sell. New product ideas get scrutinized to the Nth degree, and product managers write volumes of analysis to predict how much new revenue can be expected from the sale of a new product. Since there is no way to accurately predict the success of a new product, these analyses are a waste of time, but they provided me with a nice living over the years, until I came to Sun, which operates more like HBO.

Subscription based networks, like HBO, operate on a different model. Since their shows carry no advertising, producing hits is not important. All that counts for HBO is that the customers keep paying $9.99 a month. Thus, what counts is not a hit, but an overall reputation for quality. If you think that by subscribing to HBO you'll always have something interesting to watch, you keep paying $9.99. So too with subscription-based software pricing. When you start paying $100 per employee per year, you begin to think more in terms of the overall reliability, innovation and level of service of the vendor, and less in terms of particular products and features. Offering new features is still important, but the importance is in producing that critical reputation for quality and innovation, not in the monetary value of any particular feature. So product managers like me will still have a job to do in figuring out what features to provide, but (I hope) we won't have write those revenue-estimate fairy tales any more.

Wednesday Mar 15, 2006

Product management is a two-way street

We've been going through a time-honored SeeBeyond ritual this week: Apostles Training. We bring in fifty or so of our top field engineers, and train them on a beta version of our next release. This all takes place at the local Embassy Suites, and it's sort of like a fun boot camp. We combine formal presentations from product managers, like me, with hands-on exercises.

But the benefit isn't just for the field guys. They are a vociferous bunch. A couple of them (no names, but they know who they are) give rather pointed comments about every 60 seconds, on average, and the rest at somewhat longer intervals. For us, the product managers, this feedback is invaluable. We get good feedback from customers, but it's always colored by their particular business problems. With field engineers, you get people who really put the product through its paces, and who aren't shy about saying what they like and don't like. I have been astonished, on occasion, when a really smart engineer makes an obvious (to me) mistake on one of my own products. The fault isn't his: it's mine. When you live with a product, you get in the habit of pushing the right buttons in the right order. When something that's obvious to me isn't obvious to an intelligent new user, the reason is usually a design flaw.

Saturday Mar 11, 2006

The value of apprenticeship

There are many eternal debates in software development, arguments that are never really settled, but that are always good for a philosophical discussion, or a yelling match: vi vs emacs, formal specifications vs extreme programming, low-level languages vs high-level languages. Some of them are rather silly, but some of them have very serious management implications. The one that really gets my blood boiling is whether new development should be separated from software maintenance. In other words, whether a product team should be split into a creative crew and a bug fix crew, usually with the bug fix crew safely isolated in another part of the building. 

The main argument for separating them is that the product team won't be able to ship new releases on time if they are constantly bogged down with fixing bugs in old versions. Piffle, I say. Nonsense! Software development is a craft. The way you learn a craft is by being apprenticed to a master, starting by doing the lowest tasks in the shop. You watch the master in action, ask him for advice, and, truth be told, learn from his mistakes without having to make them yourself.

This is not to take anything away from bug fixers. Bug fixing is an honorable activity. I have known bug fix crews headed by master developers who were very competent indeed. But I'd be willing to bet that those masters would have been a lot happier doing new development, and the organization would have been better off with their talents being put to use doing it.

Separating the teams has a bad effect on the new development crew, too. If you aren't confronted with the consequences of your mistakes, how are you going to learn to not repeat them?  Who among us isn't tempted to throw his doubtful efforts over the fence for the next guy to fix, if we can get away with it?

Yes, having the apprentices pester the masters for help in fixing bugs will take energy away from new development, and may cause the schedule to slip. But not as much as one might think, because the new development guys are going to have to port the fixes to the new version anyway. Why not give the apprentices the chance to work on the new version by doing those ports at the same time that they fix the old version? For an apprentice, there is nothing like the thrill of getting the chance to put her hands on the new release, whether it's a piece of software or the facade of a cathedral.

Finally, there is a real benefit, even for the master, in having the old version constantly in front of him as a model. I have seen losses of functionality from the old version to the new version more times than I care to remember. If you are constantly reinventing the wheel, you're going to get some lousy wheels.

So keep the crew together. If you care about quality, if you care about developing your people, both masters and apprentices, it's the only way.

Thursday Feb 23, 2006

Software sunset lunacy

Lee Gomes, the tech writer for the Wall Street Journal, published a terrific article in the Journal yesterday, 22 February, lambasting software companies for periodically sunsetting products, forcing the customers to upgrade or lose support.

He was talking about Quicken, a consumer product, but the same goes double for the enterprise space, where I work. Why should you \*ever\* sunset a product? Suppose you bought an annuity. Every year the annuity company sends you a check, for which you have to do little work other than opening the envelope. Yet after four years, you tire of the annuity, and tell the annuity company not to send the checks any more, because it's too much trouble to open the envelope. What???!!!

Yet this is what most software vendors do. You have customers regularly paying support fees. They are happy with the product. After three or four years, most of the bugs have been discovered, and it costs you very little to keep maintaining it. Yet you tell the customer to either upgrade, at huge expense and risk to them, or you'll stop supporting them. The usual excuse is that it is "too much trouble" to keep supporting an old version. Too much trouble for whom, the mailman?

This is lunacy. Software vendors everywhere are recognizing that one of their biggest assets is the support revenue stream, yet they do everything they can to disrupt that stream by sunsetting products. Mercedes-Benz still stocks parts for forty-year-old cars. They'll still happily service them. Maybe they know something that our industry doesn't.

Monday Jan 30, 2006

Product managers vs developers

There was a classic Dilbert strip on Sunday about clueless product managers vs developers. Even though I am a PM, I couldn't stop laughing. I've posted it by my desk so that the developers who pass by can snicker and nod in agreement.

Thursday Jan 26, 2006

Undocumented APIs

I wonder what will happen if/when my product, eView Studio, is eventually open-sourced? I know that there is at least one of my more sophisticated customers who regularly decompiles our code, makes use of the classes they find there to call undocumented APIs, then calls us up to demand documentation for these classes when they don't work quite the way they wanted them to. One the one hand, exposing all the APIs will make it easy for these demands to arise; on the other hand, open code \*should\* make it easy for them to figure out the APIs' behavior themselves. We often leave classes undocumented to prevent customers from "shooting themselves in the foot." I guess Open Source has a certain libertarian bent, in which people are expected to be grown-up enough to take their own precautions. I would be interested to hear from managers of open-sourced products if this has been a problem for them.

Monday Jan 23, 2006

Apple does the right thing

I hadn't seen this editorial in the LA Times until BW pointed it out to me. The gist is that Apple was secretly recording clicks from choices made in using iTunes in conjunction with its new MiniStore extension. After a predictable outcry when the recording was discovered, Apple quickly reversed its policy. This is a great example of savvy product management: listen to your users, and when they have a complaint, do something about it, and fast.




« July 2016