Friday, July 10, 2009

Software development business: Peculiarities in delivering results

How software development differs from other types of business? At a first glance there should be no difference whether you sell custom developed software product or some made-to-order material product. Be you a tailor or a software developer, a customer just comes to pay you for a product he/she needs, be it a shirt or an application.

Unfortunately, it’s not so simple. The difference is caused by the nature of product: Software app looks like something absolutely “unmaterial”, like an idea, just a product of somebody’s thinking process. If such, a customer at any given moment feels free to require changing of any single, big or smallish, part of it instantly. When ordering a shirt from a tailor - its model, fabric and buttons are being agreed before the work begins; and as the shirt is made, no sane customer would ever dispute, for instance, number of sleeves or would say that he/she wants a collar to be done inside the shirt. For a shirt there remains only one issue: Whether it fits or not. This becomes absolutely another thing if we speak about software: Post-requirements similar to having three sleeves or a pink collar inside the shirt, at the waist level, are quite habitual.

Okay, software app is something different to a usual material product. If so, can we judge a software app as a bespoke artwork? Unfortunately, my answer again is: No, we can’t. If you order some portrait or a landscape, you would judge the result in general terms: “I like it!” or “It’s awful!” I hardly imagine a person saying that the landscape is perfect, but that grass under the third tree if counted from the left should have been painted 1.5 inches longer. With respect to software app, you would never be surprised with similar judgment.

That is why we have requirements. Long live to them! Requirements are supposed to be if not material, but at least a written base of the agreement between the customer and the developer. However, as the work is done, and the customer comes to see the result, you might hear something like: “Wasn’t it obvious, that this button should have been in the upper right corner of the screen?! I remember exactly that in our phone call I insisted that here should be a pie-chart rather than a table!” And your feeble attempts to refer to the requirements would be repelled indignantly: “It was obvious!” or “I remember I told you!” In this case you would better have either patience of Job, or good law department, or both.

So, certainly you must use fitting formal approaches, but it's not enough. One more "must have" is your personal attitude: We should be totally and implicitly friendly to a customer. Saying ‘friendly’, I mean it. Not just routine smile or even high five (still routine, though), but fair intention to do what the customer really wants, often after helping him/her understand what he/she really wants. It’s not pure altruism: Being really good to customer you are good to yourself. No other way to success in developing bespoke software.

4 comments:

  1. No doubt, software is not clean art, thing-in-itself. Comparisons are perilous, but I would say developing software is more making art rather than producing material wealth. However, it is commercial art, art for sale, art with predefined (and changing) requirements, art with effective business processes behind it. From this point of view, software developer should be a little bit artist. If not he/she is just coder who is able to make only 'soft shirts' by standard templates.

    ReplyDelete
  2. Interesting Tom DeMarco's article which concerns discussed problem.

    http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

    ReplyDelete
  3. Thank you, it's really interesting. I would agree with Tom about the general ideas, though to my mind he has moved too far in his conclusions. Truth, as always is somewhere in the middle. Truth might be not palpable because it lies in the fourth or even fifth dimension, but usually each of us envisions it clearly. :)

    ReplyDelete
  4. Here is a valuable discussion of the Tom DeMarco's article: http://www.codinghorror.com/blog/archives/001288.html.

    ReplyDelete