Business is about creating value.

“Value” is here… um… pretty anything that is of value:  products, services, capital, information, emotions, health, security (taking over risks) or things leading to value (like software features or legal regulations). When value is created, it can be sold to customers in exchange to other kinds of value.

Normally, you have to invest some existing value to create new value. But sometimes, it is not the case. Especially in software development, you can often see how a new value is created as a by-product, or even because of NOT doing something.

One recent example is Microsoft’s web service technology WCF. In WCF, you define contract of a web service in protocol-agnostic terms. Actually, you just use plain old C# to do that. And then, you can expose the web service using one of many supported protocols by merely configuring a binding (at least, in the theory). When you create a new WCF service, is will be exposed in SOAP by default.

Now, suppose you have to implement a REST web service, and you have to use WCF because this technology is part of the company’s long-term strategy. So you create a new WCF service and add nuts and bolts allowing to expose it in REST. Will you then delete the default SOAP binding?

By NOT doing this extra step, you can create MORE value out of your service. Even if SOAP won’t be officially supported in your product, i.e. it won’t be tested and documented, it will be still there and, who knows, may be at some point of time, some customer will need it, and your sales will say, well, yeah, of course we have beta SOAP support in our current stable version: you can use it right now, and the customer will find your product useful, and buy it.

Likewise, I often see no reason in investing development efforts to restrict or limit something, unless security or some real customer needs this restriction for a plausible reason.

Some people use to argue that narrowing the feature set of a software down to only those situations we can foresee now (for example by declaring classes sealed, members private and performing argument validation inside of non security relevant methods) will increase quality, and therefore value, of the software.

I find such beliefs contradicting with the common sense. Later we always know more than earlier. The most informed decision is one being took as late as possible (but not too late). Taking decisions about usage of the software so early (during development) means making bad decisions. Only the user of the software can take a reasonable decision about its usage. And when the software can be successfully used (for a good purpose) in a way not conceived by the original creator, it is the best compliment. Because he has managed to create value by NOT doing something.