My previous post expressed some personal frustration at my bank arbitrarily deciding to change my credit card on me. As a result of this change I get no benefits but am being forced to bear the cost of dealing with multiple entities to change my payment details. In thinking about this I've realised that there are relevant parallels with software development.

Software products exist to provide benefits and these benefits are obviously the single most important factor in the suitability of software to a user. What it is important to understand is that most users don't really care which software it is that provides them the benefits; software is rarely an end in itself. All other factors being equal users will choose the software that gives them the most benefit. In many situations this will not be your software.

There are three main reasons why we shouldn't all give up and just let the best software in each category win:

• There's no such thing as "best" as all users have different needs.
• All factors aren't equal. Users don't always make informed or rational choices and different software packages cost different amounts of money.
• Changing from one software product to another is costly. Depending on the nature of the product, it can involve rewriting existing code, replacing hardware and retraining users. These costs can be substantial.

The first two factors apply to all software selection scenarios. The third applies only when a user wants or needs to change the software that they are using. Making the wrong choices here can seriously impact the number of users who choose to continue with your product rather than try an alternative. This can be highly problematic unless you're unique and have found a way to survive long term only on new customers.

Let's consider an example. You have a website with content on a topic of reasonably broad interest, supported by advertising. A website is probably the ultimate example of the "don't care" software application. As an end user I don't care what you used to build it, I just want it to work in my web browser. If it does that, it's fast enough and I have reasonable confidence that it's secure I have no interest it what's going on behind the scenes. It's irrelevant to me. It's also a very good example of software with very low conversion costs. There are relatively few sites with sufficient compelling content to lock users in on that basis alone. The low cost of web publishing means that there will likely be many other sources for the kind of content you provide.

As such if your site is more difficult or demanding people will go elsewhere. This can be seen with things like requiring sign-in, surveys or click-through advertising. You will take a hit from these as users take advantage of the low cost of change to avoid the hassle of interactions not directly related to getting to the content they want.

If you are providing a component for use in other applications then your end users shift to be developers. When a developer uses your component it introduces coupling between it and their application. Depending on the nature of the component and the skill (or lack thereof) of the developer this coupling can be very deep. This can mean that replacing your component would be expensive and time consuming due to the development and testing effort required. Even if there is an alternative component that provides improved functionality it may not be justifiable to switch as the additional benefits are outweighed by the large conversion costs.

If you change your component so as to break existing applications then this cost buffer evaporates. You do not even need to make sufficient changes such that switching to an alternate service is the same or lesser cost as staying with your component, provided that the benefits users will obtain from the new component are greater than the difference in conversion costs of staying with your component and the costs of switching to an alternative.

It could be taken that the above is an argument that your component should never change so that everyone using it is locked in to it forever. This is not a view I endorse. There are a number of factors that oppose such a view:

• If you make no improvements then the gap between the benefits of your component and the alternatives will grow sufficiently large that the cost of conversion will be outweighed by the benefits of switching.
• Stagnant components are unlikely to attract new customers or convince existing customers to upgrade.
• Customers who have been mistreated or perceive that they have been mistreated will switch to alternatives even if a strict cost-benefit analysis doesn't justify the change.

This is of course a problem. You will inevitably need to change something but in doing so you will impose costs on your users. You will therefore need to ensure that they have sufficient benefits that they will stay with your software. This is true regardless of the nature of the change. You may have what you consider to be very good reasons for requiring users to log into your website to see your content or for changing the API of your component without altering what it ultimately does.  End users don't care. You're imposing a cost upon them and they're not getting anything in return.

So to bring the argument back to my banking situation:

• The bank has imposed costs upon me, in that I will need to change payment details in a number of places.
• I have received no benefits from this change. Indeed one of their customer support people told me that everything was staying the same apart from my getting a new piece of plastic.
• I don't care why the bank has made these changes. They may be getting a better deal with their business partner but that's of no benefit to me. Indeed insofar as they're getting a better deal I'm angry that they've chosen to do so at my expense.
• By imposing a certain level of cost regardless of the option I choose the previous excessively costly options become justifiable. This may have a greater overall cost but could result in a better overall outcome.

The lesson here is that despite previous adequate if not brilliant service an imposed cost without benefit to me is resulting in me considering alternate providers. This is a risk also present in software development and requires consideration when making changes that will negatively impact end users. How to do this (i.e. the difficult bit) I leave an an exercise for the reader.