Custom software curtails and stretches: A question of demand
AR Goodman and A Garcia
Software Engineers and Psychologists (true!)
Center for the Psychoanalysis of Artificial Intelligence. Valencia, Spain
Building custom software has become very popular in some markets. The time-to-production is longer and it is far more expensive than buying commercial software, but there is no need to pay any maintenance license year after year. The other big advantage is that the customer pays for what he (or she) exactly needs... if he is really able to explain what the hell he (or she) wants, which often it not as obvious as expected. Let me explain what kinds of issues are faced by custom software architects by drawing a parallel between them and architects for buildings. In order to design a successful project, the first thing to consider is what type of building the customer wants to build, but in our parallelism the answer is usually far but clear: 'It’s difficult to say in advance. Begin to build a cottage and then we will see if it is enough to fit our demands'. Then you are prompted to ask about the types and amount of users to consider, but the answer will still be of little use: 'Anyone. The maximum'. At this point, the customer normally appeals to the magic words: "modularity" and "technology". New technologies are aimed to allow the design of modules which can be combined in different ways to compose different results. In the customer’s perfect world, modules can create a cottage and then turn it into a 14 level office building ... But, how much is this magic? Oops, there is always a very limited budget. And the last key requirement... 'the building must be ready in 6 months'. We have to consider that an architect needs time to draw all the plans required to guide the construction team ... Ummmmm ...In our parallelism, the customer feels this is a waste of time because highly specialised teams are not supposed to require detailed written explanations to know what to do or how to do it... Two weeks should be enough to draw and write every plan, schedule or documentation. How does this senseless situation eventually evolve? Software companies usually agree to these requirements. They design a “modular” software application which is built in the frame of a 12/18 months project, delivering a “cottage” in the first phase. The first 6 months of the project are mainly dedicated to find out the accurate details of what the customer really wants. The transformation into a “14 level office building” is left for a second phase that is not included in this project because of timing and budget issues. Of course, in such conditions the quality of the result is far from perfection. Nowadays everybody is familiar with the “mistake culture” (you, reader, probably are a Windows user, so you know what we mean):
AR Goodman and A Garcia
Software Engineers and Psychologists (true!)
Center for the Psychoanalysis of Artificial Intelligence. Valencia, Spain
Building custom software has become very popular in some markets. The time-to-production is longer and it is far more expensive than buying commercial software, but there is no need to pay any maintenance license year after year. The other big advantage is that the customer pays for what he (or she) exactly needs... if he is really able to explain what the hell he (or she) wants, which often it not as obvious as expected. Let me explain what kinds of issues are faced by custom software architects by drawing a parallel between them and architects for buildings. In order to design a successful project, the first thing to consider is what type of building the customer wants to build, but in our parallelism the answer is usually far but clear: 'It’s difficult to say in advance. Begin to build a cottage and then we will see if it is enough to fit our demands'. Then you are prompted to ask about the types and amount of users to consider, but the answer will still be of little use: 'Anyone. The maximum'. At this point, the customer normally appeals to the magic words: "modularity" and "technology". New technologies are aimed to allow the design of modules which can be combined in different ways to compose different results. In the customer’s perfect world, modules can create a cottage and then turn it into a 14 level office building ... But, how much is this magic? Oops, there is always a very limited budget. And the last key requirement... 'the building must be ready in 6 months'. We have to consider that an architect needs time to draw all the plans required to guide the construction team ... Ummmmm ...In our parallelism, the customer feels this is a waste of time because highly specialised teams are not supposed to require detailed written explanations to know what to do or how to do it... Two weeks should be enough to draw and write every plan, schedule or documentation. How does this senseless situation eventually evolve? Software companies usually agree to these requirements. They design a “modular” software application which is built in the frame of a 12/18 months project, delivering a “cottage” in the first phase. The first 6 months of the project are mainly dedicated to find out the accurate details of what the customer really wants. The transformation into a “14 level office building” is left for a second phase that is not included in this project because of timing and budget issues. Of course, in such conditions the quality of the result is far from perfection. Nowadays everybody is familiar with the “mistake culture” (you, reader, probably are a Windows user, so you know what we mean):
We wonder, if customers know in advance that their requirements are not realistic and will lead to a virtually useless product, why do they act is such a way? This is really hard to guess, except from a surrealistic perspective. What strategies do software companies develop to improve these situations? Well, this is another story…
