The hardest part of writing successful software

The hardest part of writing successful software is legacy. Once your software succeeds, you now have precedents that you must consider. A semi-recent slashdot article points to a blogger who talks about the new OOXML formats. I don't care to get into the merits of his argument. The point is that legacy is hard. Past success is no garuntee of future success. Microsoft has some very successful products and some very unsuccessful products, and there are good people who worked on both kinds of products. In order to be successful, you need to do some things right. In order to continue to be successful, you need to continue to do things right. Is OOXML wrong or right? Time will tell.

For example, you may not have heard of Visact 2000 or Liquid Motion. Both of these products came out of the team I was originally hired into (trivia point: my business cards still say Office Activation although the current name of the team after our most recent re-org is Office Graphics). Fortunately, the technologies/people who built these products made their way into products/teams such as PowerPoint and products/teams with future potential like Expression. Will these products be successful and continue be successful? Only time will tell.

There are some people who criticize the new Office Open XML formats. As I already said, I don't want to debate them. Whether you love them, hate them, or simply don't care about them they are now part of the Office Legacy. The millions of customers already using them is evidence enough of this. I do want to make a quick point that passion about a product is a sign of success. Although you want people to love what you've done, it's hard to make something so universally good that everyone loves it. The fact that some people hate PowerPoint means that in some ways we have succeeded. Maybe in some ways we have failed - some people hate PowerPoint because they hate Microsoft for whatever reasons, and others hate something specific about PowerPoint (myself included - there are some features I just hate for my own reasons).

When new versions of the file formats come out, customers need to work with them. Unlike binary formats where the data structures and extensibility measures are locked down, XML formats can be harder to maintain. Indeed, with 6000+ pages of specs for Office Open XML there are a lot of areas to maintain. If customers can add their own extensibility tags willy nilly then there's nothing to prevent them from picking a tag name which conflicts with a tag name that we will use in the future for something else. If the conversion between binary and XML isn't perfect then loading and saving through the converters can change document content (and it happens to some extent). Also, in the future, there will undoubtedly be new features that need to be added. How well the XML changes to meet these new features without breaking and requiring rewrites will be lessons learned from the designers that came before. And that's not even mentioning bugs. I don't think we're perfect - there are bugs in those millions of lines of code that will result in someone either loving or hating the product in one version or the next. Sometimes we fix some feature in one version and break other features. I'm guilty of doing that to other people's features just as much as some other people are guilty of doing that to my features.

Another aspect to legacy is that not all of your users are modern in all ways. If your organization uses older applications and older documents written in older applications you would require new software you purchase to work with your old/existing formats. Office applications have a long history of file formats and converters. It's pretty cool how many formats Office can consume that are for products which no longer have active development but that you know someone out there depends on. People have good reason to support only the formats that they do and there is a cost-benefits analysis anyone writing converters understands (Office supports a lot of really old formats). A common theme in my recent messages is that you should do what is most valuable in your time on this earth because the opportunity cost of doing something else is not getting to do what is most valuable to you. For me that means that I have recently been spending a lot of time with my family and in particular, my 11 month old son.

The trick to deal with legacy in software is to give it respect and strive to serve as a better example in the future, because what you do leaves a legacy. Sometimes legacy is an ugly and hard problem, but without the past there can be no future. Some hacks will live on in infamy, but we learn valuable lessons from the past, and we leave valuable lessons for those who come to continue in our footsteps. My new years resolution for 2007 is to learn from past mistakes and strive to catch myself before I repeat them.

This posting is provided "AS IS" with no warranties, and confers no rights.