Software for Multiple Customers
To follow up on my previous post about fully flexible software, I wrote about projects with a single customer or at least one entity that pays the bill and dictates the requirements. That is, of course, only one type of project, even if it arguably is a huge chunk of the programming market, including consulting work, custom development and in-house development work.
The other kind of software project involves multiple customers (from dozens to hundreds to even millions). For example, enterprise software and consumer software (both desktop-based and web-based). Enterprise software is, in many respects, similar to consumer software except that a few people (the purchasing people at companies) serve as proxies for many users.
One way to look at this kind of software is to think, how easy would it be if the software was developed in such a way that changes are easy. This way, when users want something new, you can give it to them faster and keep them happy and keep them as customers. You can also acquire new customers faster by giving what they want. There are a couple of fallacies here:
First, this line of thinking appears when the business has already acquired a few customers. But before that happens, the business has zero customers and it needs a product that can satisfy at least a few people so that they can be customers. So the priority for a business would be to build something that people need versus build something that can be changed easily. Time from zero customers to “some” customers is money being burnt by the business that has to come from somewhere.
Second, you don’t know what people want to change. They may be perfectly happy with some parts of the system and don’t want to change them, resulting in wasted time you spent in making them customizable. As you would expect, users request changes in the screens that they commonly access, and ignore the ones they rarely use. It would be better to spend time there.
This is not to say that you shouldn’t design your software properly. Choosing the right development tools and framework is a start. Researching your users, and planning for a future where you want your user base to expand are good things. In fact, you should probably think about a quick first version to entice early adopters and a second version that is more mature, and have a plan to make it work.
At the same time, remember that there are other worthwhile investments of your time than simply customizability. For example, spending the time to get the user interface right can pay back in spades. For example, read the comparison between Google, Bing and Yahoo Maps. Or read about the Close Tab behavior in Google Chrome. Someone took the time to think the functionality through., making a huge difference in usability and buzz.
There are many aspects of code – maintainability, scalability, design, etc. They all compete for your time. Pick the right battles.