I’m working on a project to relpace the funtionality of an existing system that is shared by two business units, so that each unit can continue development in differing directions. The customer asked me about how to make the decision of whether to build a change or new feature into the existing system and then later into the new system, or to build it only in the new system and force the business to wait until the next release.
It reminded me of the Decision Tree problem I faced before, so I set to work on answering the question. But I ran into a stumbling block. The two solutions are as follows:
a) build now in existing system, and then again in the new system
b) force the business to wait, and build it later in the new system
While the former option might not cost double because of the learning curve of the first implementation, the latter option might take a very long time if the prerequisite features for the change have not already been implemented in the new system. So both options have their own complexities. But in theory we can put costs down, and calculate the answer to the question:
a) = 50k + 52.5k = 102.5k (assuming 5% inflation over the year)
b) = X + 52.5k = ?
Hmmm… how do you put a price on the cost of forcing the business to wait? Well, I struggled with that, because its probably very specific to the features of the software and the particular problem at hand. But I asked my friend Mark who has an MBA and he said that he has faced this very decision from the customers point of view. His advice was to always force the business to wait. The reason is two fold. Firstly it intrinsically makes the business put more pressure on the development, causing it to occur faster – not necessarily with the usual cutting of features or quality, but often with the injection of more cash. Secondly, if you develop two systems, the chances of them becoming misaligned and to grow apart is increased, which can cost a lot to fix in the long run.
So, he suggests always forging ahead with the new system, and forgetting the old one. Saying that, I’m not sure I would simply follow that rule without at least doing some minor financial analysis – after all, business decisions should not be made from the gut, they should be calculated.
Anyway, this problem reminded me of where I originally read about this type of problem and its solution. I think the book was by Joel Spolsky (see www.joelonsoftware.com) but I’m not too sure. Anyway, the author was discussing whether to build functionality into software if the requirement is not actually a real one, just that it may become a reality in the future. Like if you are building a Zoo object, should you build the option to bathe all the animals, if its not a solid requirement at this time. Anyway, his options were:
a) build now, but 50% chance its not needed
b) build later, at increased cost due to inflation and having to understand problem and code again
He used values like:
a) = 50k for building now
b) = 55k (5% inflation, plus 5% ramp up) * 50% = 27.5k
So he calculated that its always better to wait until the requirements become a reality, unless the chances of them becoming a reality are very high (91% in this case). Sorry, the animals will have to stay dirty for the time being!
It’s for this same reason that we choose to worry about performance when it becomes an issue, rather than during the design and implementation stages. This is especially true with modern Architectures like JEE because they are designed for scalability and performance from the outset.
Finally, the promised picture to go with it:
