The Cost Of "Configurability"

As most of us already know, there are quite a few solutions to a problem. Now, how do we choose what to opt for if more than one solution seems to make sense ? Most people that I meet come to a decision almost immediately on this issue. Provide both the solutions and make it configurable so that the customer can choose whichever he prefers.

Wow!!! That's bloody brilliant... Why didn't I think of that before?

Because, I didn't want to run away from the problem. It's an easy task to leave the decision making to someone else. And leaving the decision making to the most uninformed person (a.k.a "customer") is not exactly wise.

The customer doesn't always know what he wants. This has been iterated dozens of times by people like Joel Spolsky. However, for some reason, things that make make sense doesn't seem to catch on as "agile" does... :-) Hats off to Steve for his excellent articles:

http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

http://steve-yegge.blogspot.com/2006/10/egomania-itself.html

(The "agile" interpretations in my company would make another very interesting read... )

The problem is pretty much of a known issue. "Common Sense" is just not that common... But what really gets wasted over here and what I am arguing for? I get paid the same regardless of how many solutions I provide. The cost incurred over here is something which is missing to most people. The two solutions and "configurability" are going to cost us more time and instead of creating an iPhone after iPod, we are going to be stuck with the rather envious task of arranging the music in folders named after Artist & Album rather than in folders such as F00, F01 and so forth.

The company is pretty much going to lose its edge over competition for favoring work that provides immediate and probably less money rather than spending time on something that would enable it to capture newer markets or a bigger share of the market.

Well, the focus should be on what the customer needs rather than what he asks... But would it not offend existing customers if we don't deliver what they ask? Well, that's where the customer engineer's role is critical. He has to be the smooth talking guy who basically tells, "Wow, that's a great idea.. Let me discuss with the engineers back home and get back on it. BTW, our engineers have started work on this great new product that does blah blah blah...". Its that simple really...