Archive for the ‘Software business’ Category

Bloomberg by Bloomberg

October 14, 2008

A while ago I finished reading Bloomberg by Bloomberg. It’s a book about the history of Bloomberg narrated by Michael Bloomberg himself.
It’s a frustrating book, sometime I felt I don’t want to read it anymore. The main problem is Mike’s style that seems a hard sell of his company and himself ultimately. It’s also full of pride reflected in the style, well deserved pride, but still, frustrating when reading it in a book. People want real content not marketing blah blah.
Anyway, he’s making some good points about software development in the financial services. And one thing he mentions is the “agile” methodology that they used at Bloomberg, emphasizing shipping products on time, even if they’re not perfect, even if they have to cut down features, and from there on, working in quick iterations.
It’s how the banking industry in general works. First because the business wants tangible results. Second because bonuses are paid annually.

It’s the model to be followed by all entrepreneurs I think. It was the same model followed by Microsoft.


Activity based planning

August 14, 2008

I’m reading Microsoft Secrets, an old book about Microsoft before 1995. It’s still a very interesting book as it looks back at some of the Microsoft practices for product development. One problem Microsoft had back then was how to select the features that should go into a product. Developers wanted some features that they liked and generally, whoever shouted the loudest got their features in. It was pretty much developer driven and a lot of it was copied from other products (yeap, Microsoft weren’t much of innovators).

The system wasn’t very good, so they finally discovered a better one, called activity based planning. This method started with the user in mind and asked questions like: how is the user using the software, what is the problem that the user is trying to solve. For instance … creating a budgeting system in Excel. This would be a big activity, which then can be broken down into smaller activities.

Once an activity is identified, it is mapped to technical features. These technical features can support multiple activities. For instance, loading images from the disk, or sharing components via OLE. These are technical features that ultimately can support multiple activities.
Activity to feature mapping is therefore a many-to-many mapping.
In the end, the features that supported more activities made it into the product whereas the ones that couldn’t be mapped to an activity were generally scrapped. It was a good principle to use when rejecting features as they usually had more features than they could implement.

This change in perspective helped in many ways. First the product became more aligned to what the customers really wanted, which is always the killer feature of a product. Second, the product management became a more important contributor to product development by giving a sense of direction to the product and saying … this activity is really important focus on that, or this activity is not that important. Product management could now simply interview the people and get feedback specifically targeted at the activities that users were conducting with the software.
But there were improvements that came “for free”. And one was that people wrote more generic code. The rationale was … I can change this feature I’m doing to support an additional activity with only minimal changes to the code. Supporting more activities was in fact a ticket into the product.

These are lessons that every company should learn from history and from Microsoft.