A little while back Charles Nutter posted about his progress at getting the JRuby bug list under control:

Roughly around September, we crossed an important threshold: 500 open bugs. They dated as far back as 2006 (we moved to Codehaus in 2006), and across the entire release sequence of JRuby; there were even some bug reports against pre-1.0 versions. From September until about mid-January, we worked to keep the number of open bugs below 500. Sometimes it would peek above, but we were generally successful.

About mid-January, I figured it was time to really bite the bullet, and I started walking from the oldest bug forward. It has been a long slog, but I'm making great progress.

Finding the right balance between new features and bug fixes is always really hard. The more experience I get the more I think it’s important to keep the known bug count low. There’s a surprisingly large cost to having bugs sit around unfixed in a bug reporter tool. Even if no one else finds the bug and calls support, each time you try and sort through the bug list to find something, to prioritize bugs or work on stuff you also have to trawl past that bug. As the number of bugs increases it gets more and more likely that they’ll get in the way and the more time you waste because of it.

It gets worse though. Having a lot of known bugs leads to a culture of not fixing bugs because it’s just one more bug so add it to the list.  Getting the count down is always too big a job so it keeps getting put off and the probably just keeps getting worse. If your competitive advantage is based on making users more productive or being easy to use, that’s a pretty disastrous situation because even small bugs dramatically affect the usability and productivity of software.

The right balance between features and bugs is going to be different for each time and each product. I think the key to finding the right balance lies in keeping the number of known issues relatively constant. If the bug count is increasing on average you’re eventually going to get too many bugs to handle and have to go on a fixing spree. A decreasing bug count certainly isn’t a bad sign, but if features aren’t being added fast enough to meet client demands you do still have a problem.

There’s not really a lot of flexibility in trying to keep the bug count stable though. If you’re under pressure to add features faster – how do you manage that without ignoring bugs? Short term there isn’t much you can do. Longer term the key is to reduce the number of bugs you’re adding. After all, if you add fewer bugs you don’t have to spend as much time fixing them and you can focus on features.

What I’m finding useful is the charts plugin for JIRA. I’ve added a couple of simple graphs to my dashboard. One shows the total number of open bugs over time and the other shows the number of bugs opens vs the number closed each month. Together they give a pretty clear indication of the quality trends for the product. It’s not perfect because the levels of testing and deployment isn’t constant throughout the life of a product so the influx of bugs and the amount of time spent on fixing obviously varies but looking at the month long view gives a surprisingly consistent view.

Believe it or not, it’s been almost exactly 2 years since I kicked off LiveWorks! as essentially a skunk-works project to get some of our internal experiments out into the open so they proved useful. As it turns out the bigger success has been the weekly hints and tips that we started adding a few months later. Unless one of the migrations has messed up the dates, the first tip was a simple overview of how to integrate EditLive! that Rob wrote. I still regularly refer people to that article.  Since then we’ve posted a new article every single week without fail.

The net result is that we have a huge collection of knowledge that’s built up, from common tasks to quite specific ways to customize and extend EditLive! It’s actually quite rare for me to resolve a support case without linking to a LiveWorks! article at least once. With the recent addition of a few video demos as well I’m finding it more and more common to put together a customized package of LiveWorks! links for new prospects as well.

What’s particularly amazing about this is that I refer people to the LiveWorks! articles far more often than I point them at our official documentation. We’ve been talking about reworking our official documentation for at least as long as LiveWorks! has been around but it always seems like such a huge project so we never do it.  This leads me to the secret of improving documentation: set up a regular schedule for making improvements and stick to it.  Whether you write a new article a week, review an existing article a week or add 3 good “See also” links each week you’ll wind up improving your documentation faster than if you constantly try to find time to fix it all at once.

The draw back is that it’s very hard to improve the discoverability of information gradually like this. LiveWorks! really needs a knowledge management expert to come in and make it easier to find what you want – I happen to have a pretty good memory for what’s there and know what to look for, but most people would find it far less useful.

Antonio Cangiano:

In theory I could have been disappointed. After all, my visit didn’t fix the problem at hand, my expensive laptop seemed to be good as a door stopper, and repairing this thing could potentially be less advantageous than just buying a newer unit. Yet, as I arrived home, I told my wife that my next laptop would definitely be an Apple.

The reason for this is that I saw a genuine effort to help me out, an unheard level of care for the customer and an willingness to do what’s right, even if it costs the company some money. The whole experience was very positive and I felt that the premium cost of Apple’s products is easily justified by this kind of support.

The way you support your clients is a key part of any products and services your company provides. No matter how much you focus on quality, things will go wrong sometimes and your clients will have problems. Ironically, that’s your biggest chance to make them a fan for live because while people expect products to work all the time, they don’t expect support experiences to be much good. If you provide a great support experience, it surprises them and makes them notice.

Two examples I’ve had recently really confirm that.  The first was with one of Ephox’s clients who were experiencing a lot of crashes. It had reached the point where the authors were unable to do any work and the content migration had pretty much completely stopped – their project timeline was dead in the water. Thankfully, they were extremely patient and friendly people so even in such a stressful time were really good to work with and I made sure I dropped everything and worked whatever hours were required to solve their problems. Most importantly though, I gave them copious status updates to make sure they knew exactly what was going on and give them the information that their bosses were going to ask for. We’ve solved the major issues and are still working to clean up some more minor issues, but they’ve already offered to give us a reference.

The second case was with a Freecom Tough Drive I bought. It’s meant to be powered off the USB bus, but PowerBook G4s don’t supply enough power that way so the one I bought for my wife has sat in the drawer for quite a while. Recently though our regular backup drive failed so I really needed to get it working. Turns out they’ll ship you a free power adapter if you need it, you just have to email them. I did, and got a response within about 30 minutes to say the adapter would be in the mail asap. Needless to say, I’m seriously impressed and will be sticking with Freecom for any portable hard drives I need in the future.

It’s easy to think of support as a cost centre for your business and something that should be outsourced, but the reality is that it’s one of the best opportunities for impressing your clients, building great word of mouth and perhaps most importantly, getting real world feedback on your products so you can make them better in the future.

Michael Krigsman sticks it to Nick Carr and includes an interesting assertion: that how good software is can be decided by how much revenue it drives:

Nick, please let the market decide whether enterprise software is “good” or not. There’s a simple metric for measuring this: it’s called revenue. Just for kicks, compare the revenue of enterprise companies, such SAP or Oracle, to consumer-oriented firms such as Twitter (click to follow me).

Interesting point, but wrong. The amount of revenue software drives is determined by a number of factors (go ask an economist for the full list), some of the really key ones in the enterprise vs consumer questions include:

• The ability to pay of the target market. It doesn't matter how good the software is, if the customer only has $10 that's all they can pay for it.
• The size of the market it targets. Brilliant software for a niche market will generate less revenue that average software for a big market.
• The amount of and quality of competition. This is the really big point that Michael misses – if you are the only solution to a big problem for people who can afford to pay a lot, you will make money hand over fist almost regardless of how bad the software is.

A much better way of judging how good software is for a mature market, would be how much room there is for a new competitor. If someone can enter the market and solve the problem better than you they'll take away your customers and make money instead. Unfortunately, this is a particularly complex metric because you also have to factor in how rapidly the entire market is growing etc.

This of course leads us to the question, is the enterprise software arena ripe for an upstart with a far more sexy, usable product to come in and take a lot of market share? To a degree yes, but only if they can also solve the existing problems that are well served by enterprise software – support, scalability etc. All the things that the enterprise sales process currently focuses on.

The conversation around enterprise software goes on, with a couple of good responses to my last post that I want to highlight. Firstly, ddoctor (aka Dylan Just who recently started working here at Ephox) in the comments:

I’m thinking of making this one of my career goals – making enterprise software not suck.

Then you're very much in the right place – that's what we do…. He goes on to give some very good advice on designing good UIs, but it misses a key point that I was trying to make in my last post:

Enterprise software doesn't suck because the engineers can't do better, it sucks because the sales process prioritises things in a way that guarantees that it will.

If you want to fix enterprise software, you have to fix the sales process – you have to get real end users involved in making the purchasing decisions and clearly demonstrate the financial benefits of good UIs in terms of user productivity etc. Our product manager, Damien Fitzpatrick1 makes this case quite well:

For example, lets take a team of 50 knowledge workers getting paid about $30 an hour each. As part of their daily tasks they have to add information to a wiki, to a blog and perhaps to a content management system. To do this our hypothetical knowledge workers will be using my favourite web word processing interface; EditLive!. Conservatively I’m going to assume that we can save each one of these people 10 minutes a day (that’s only about 60 clicks a day). Over the course of the year this means a saving of $62,500 just through a few less clicks.

That's the kind of argument you need to get into the sales process for enterprise software because it's simply not on any of the request for tender checklists or feature requirements right now.

Discipline and Punish2 also picked up on my post with an interesting take on things. I particularly agree with:

Bad usability and poor extensibility are thus only symptoms of the underlying disease: a lot of enterprise software is clearly built with centralization as its founding principle. It's designed to appeal to managers and executives but especially a particular kind of manager who wants top-down, command-and-control abilities over her organization.

It's true, most enterprise systems focus on the management of data rather than the creation or the actual use of data, however I suspect there's some confusion between the trends in the consumer space and the trends in the enterprise space:

A natural consequence of this mindset is that Google's done an excellent job building an open, extensible, and inclusive platform that most enterprise vendors can only describe in their marketing literature. If Google does disrupt enterprise software it won't be because of its army of PhDs or any kind of "Google Magic." Rather it will be yet another data point in the long, long history of "big", open technologies disrupting "small", closed technologies.

The catch here is that the trend towards open technologies with a horde of small vendors developing plugins, widgets or whatever they happen to be called, is very much a consumer trend. There's no such trend in the enterprise world, in fact it's quite the opposite – enterprises are more and more inclined to consolidate on one big vendor that supplies the entire stack. This trend is picked up on in all the major reports I've read (Gartner, CMSWatch etc) and is showing through in the number of deals we're seeing with multiple CMSs being replaced by a single instance from one vendor. It's also showing through in the success big vendors are starting to have in the new collaboration and social software market which until very recently has only been filled by small players. Expect those small players to either grow up fast, or be run down by the big players. It's very difficult to do well in the enterprise market if you're a small company and impossible if you're a small company without good partnerships and relationships with the big players.

Enterprise software will become more usable over time, but it won't be because of the threat of Google or openness running it down – it will be because enterprises start to realize the true productivity cost and you'll start seeing the argument Damien put forward more and more in enterprise sales. Better quality software directly helps your bottom line. That's where the changes need to drive from if they're going to succeed – not the desire for developers to make the world a better place.

It may be sad, but money makes the world go round.

 

1 – who seriously needs to blog more often….↩

2 – I couldn't find an actual person's name anywhere on the site….↩