Krishna Kumar is a software development manager from New Hampshire. He writes on topics related to software development, programming, project management, and business management. Krishna is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

Software for Multiple Customers

02.02.2011
| 3025 views |
  • submit to reddit

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.

From http://www.thoughtclusters.com/2011/01/software-for-multiple-customers

Published at DZone with permission of Krishna Kumar, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Sadsds Dsadsadsa replied on Thu, 2011/02/03 - 4:33am

I've read your article twice and am still clueless as to what you are saying.
You also seem to confuse customers with users. An application, when in production, may have millions of users that does not mean we have millions of 'customers' in the sense of someone providing requirements. Agreed, customers and users are terms not defined but in the world of software development there is a difference - maybe roles is a better term? Its unlikely an application will have millions of roles.
"So the priority for a business would be to build something that people need versus build something that can be changed easily."
The priority for which business? The one paying that wants the system or the one building the system.
Anyway, the answer is simple - build the system they need. Anything else is risky and wasting time building something that may never be needed.
I'm guessing you work in a waterfall environment, hence the muddy nature of your arguments and reasoning. WATERFALL DOES NOT WORK.

Thomas Kern replied on Thu, 2012/09/06 - 10:51am

Thanks for great posts. I’m a huge fan of pragmatic solutions and i tremendously value simplicity. Over 15 years of my career, the most frequent problem that i see in software development is over-engineering. It can be done under different pretexts but the result is always the same – overspending in time and budget, unmaintainable complexity and wasted effort. I fully agree with you that software should be first usable and only then – reusable.

http://www.java-tips.org 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.