SOFTWARE ECONOMICS PART 2
Software Economics and VFP
There are more than enough articles available on how to create robust and well working software. Not may articles however, describe the economics behind the decision making on software. This article is the second in a range of articles describing some useful techniques to help you, as software developer, in the discussion with your clients (I consider your boss a client as well) on how to decide for the most elegant way for developing software. Of course, since we are all VFP developers, I will emphasize the importance of our beloved Fox within this context.
To start with
This article “seems” to be an article based on for-profit business. Of course, most businesses simply exist because their owners want to make money by investing money in activities that make more money. So, what if you work for a non-profit organization? Then this article is for you as well, even though these types of organizations are indeed not interested in MAKING money they at least want to do as much as possible with the available money.
This article shows one of many ways how to do as much as possible with a little as possible money.
Things wear out, like it or not, and so does software. Of course, it will not deteriorate like cars, buildings, computer hardware or human bodies, after all, software is created by putting zero and ones in the right order (Geez’ my ol’ body could use some new 1’s and 0’s ;-) ). Software will wear out due to lack of support of the software development tool, it will wear out because the platform is no longer supported, it might wear out because new technologies are available and corporations want to use that for creating new business opportunities. Any investment, done in software or hardware, not only should thus make money for the company, but also represents a business loss. It is our duty, as software developers, to keep the loss in software to a minimum, and to make the investment as small as possible, thus making the return on investment as big as possible.
Sunk Cost and salvage value
At any time a decision has to be made whether or not software should be replaced. When dealing with hardware we could sell the stuff. You can put your car on e-bay, go to a real estate broker to sell the house or bring your computer to a second hand shop to sell it there. Some even go to the plastic surgeon to renew their faces or suck away some fat from their bellies (the latter is not so much a replacement though, is it?)
With software this is hardly ever the case. Most of the time, software is licensed on somebody’s name, it might be custom made software not useable in other lines of business or simply there is too much business logic completely tailored for the customer, thus making the software useless for others in the same line of business.
Whenever selling anything we bought in the past we have sunk costs.
At any moment in time you bought that state-of-the-art PC, now, three years later, that machine is not so state of the art anymore so you decide to sell it, the price you get is the salvage value of that hardware. The difference between the price you ever paid and the money you get now is the “sunk cost”.
In a perfect world you have reserved some money to cover these costs when you sell that hardware (a car too is hardware, so is your house) in order to get a new version of that hardware. This allocated money cannot be used for other investments, therefore represent a (business) loss.
In the case of software, as we saw, there hardly is a salvage value, thus the price paid for that software is also the sunk cost. The natural tendency among people (and YES, here is a revelation, managers seem to be human as well!) is to keep those costs as low as possible. So, this same tendency makes that software is very often used until completely “worn out”.
But never mind what way you turn it, also software should be replaced or updated at some moment in time. The real question is, how much would a company invest in this replacement (and thus, how much sunk cost are they willing to make) and how much would that investment bring for the company.
Let’s take a look at defenders and challengers.
Defenders and challengers
The defender in this article is a home grown Fox 2x application with 40 concurrent users, call-agents in a callcentre. Since the application is created in-house the sources (and thus insight in the business logic) are available. Its challengers are a new to develop C# application and an off the shelf application.
The application handles incoming transactions made by calling customers.
The annual turnover the company makes with that fine piece of work is $1410K currently. The application itself consists of near to 450 Function Points.
Marketing reports show that by updating the application to a new version might near to double the turnover for this work. New markets are found and they (these marketeers) are very eager to explore those new markets, so the need for a new and faster version is absolutely present, they actually needed it yesterday. So, no matter what way you twist or turn, a short development/implementation cycle IS high priority.
Expectations are that this new software should run for 5 years.
Management has also heard of this great new silver bullet, .Net, (OK, I wash my mouth when I am through with this article) therefore they decided to “go for it”. Temporarily forgetting about money and thinking about how they can boast to their fellow managers in the business club they use the latest technology (brag, brag, brag)…
On the other hand, there is one manager (not really high on the ladder, but hoping to get there) who found this off the shelf application that has it all…. After “some” customization.
The costs for new hardware is not taken in consideration in this comparison, management decided a while ago already that the computer room might need an upgrade anyway.
Meet Mr Vince F., Programmer
The in-house developer is the ever admirable and very educated Mr. Vince F., he is a programmer. He is also a Very Fast Programmer (yes, he likes car-races). Apart from that he is also a man who tends to keep his mind clear and loves facts. His most famous quote: “One fact can swipe all arguments off the table…”. He made this little list of all options and he did put up some figures.
Rebuild phase 1(1)7 days5600 Rebuild Phase 2(2)10.5 man months181650 Duration3.5 months Maintenance (annual)3 man months51900 Data throughput 11200 recs/sec Turnover increase3*
Rebuild26.25 man months454125 Duration7.5 months Maintenance3 months/ yr51900 DBA 30000 Data Throughput 9300 recs/sec Turnover increase2.5*
Customization10.5 man months181650 Duration3.5 months Licensing40 licenses ad 12000480000 DBA4 man months / yr69200 Maintenance2 man months / yr34600 Data throughput 15407 recs / sec Turnover increase4.1*
The “duration” in the above table is the actual time it will take from the start of development to the actual implementation and use of the app.
Speak the language that those PHB types understand, MONEY!!
Putting this in perspective of money: The defender has a rebuild in 2 Phases. During phase one all the generated output of the designers (meaning all the .spr’s, mpr’s, prg’s and reports) are recompiled in the latest version of the sly Fox. Cautious as always Vince F. takes 7 days for that, making sure he can handle unexpected behaviors and compile errors (if any). He also sees a chance to rewrite some of the most important code for that end of the application. In the second phase he will redesign the software. Although he is strongly for the attitude “if it ain’t broken, don’t fix it” he also has found many areas where changes in the code might bring advantages in speed and lower the cost of maintenance.
The possible turnover, created by pushing the new app to its limits, might increase with a factor 3, meaning that this eventually might be $4230K. More then enough for these happy marketeers who see a possibility for twice the current turnover.
Since the time to recompile will take only a week the agents could start this newly compiled app after that time already.
Total costs for rebuild and maintenance will be $ 239150. Availability after starting phase 2 will be 3.5 months. Meaning that in the first year a possible turnover can be made of (4230/12)*8.5 = $3060K (3,060,000). During the remainder of its lifetime this application cost $51900 for maintenance.
So the turnover for this app is 4,230,000-239150=$3990850 in the first year. For the second and consequetive years the turnover will be 4230000-51900 = $4,178,100. In total, 3990850+(4*4,178,100) being $20,703,250
The first challenger has a cost of $536,025 in the first year and $81,900 in the years to come. When pushed to the limit this app can generate 2.5 time the turnover the current application generates, meaning a yearly turnover of (1410*2.5) = $3525K.
Since the time to market this first alternative will take 7.5 months there will be 4.5 months left meaning the turnover in the first year will be $1,468,750. During the remainder of its lifetime the application will cost $81,900
So turnover with this app will be 1,468,750 – 536025=$932,725 in the first year. 3,525,000-81,900 = $3,443,100 for the remainder of the years. In total 932,725+(4*3,443,100) being $14,705,125
The second challenger has a cost of $765,450 in the first year and a remainder of $103,800 in the years following. The possible turnover for that version is 4.1*1410K, meaning $5781K on an annual basis. In the first year there will be 8.5 months that the company can work with this app. Meaning that they can possibly make $4095K that year and $5781K in the years to follow.
The result will be 4095000 – 765450 = $3,329,550 in the first year. 5,781,000 – 103800= $5,677,200 in the years to follow.
So, to repeat the above: Total turnover for this second challenger are 3,329,550+(4*5,677,200) being $26,038,350. Just for the sake of this excercize we will take a look at the return on investment.
Applicationdevelopment costs over these 5 yrs annuallyTurnoverAVG annuallyROIDefender374504,140,65011056%Challenger 1908252,911,6753206%Challenger 21323305,207,6703935%
Challenger 1 has both a smaller turnover as well as a smaller ROI compared to challenger 2. It will therefore be rejected. The defender not only has a higher throughput than challenger 2, it also has a lot higher ROI (2.8 times)….
Happily as ever our dear Mr Vince F., Programmer, goes to work the next morning in his Very Fast Car… What was that “crrrrrack?” looking in his back mirror he sees the remainder of challenger 2, spread all over the street. With a sad smile on his face Mr Vince F realizes that another silver bullet just bit the dust. “When will they ever learn so he wonders.”
To be continued…
ABOUT THE AUTHOR: BOUDEWIJN LUTGERINK
Programming is one of the many hobbies of Boudewijn. He has worked with computers since 1985 and is the author of two books from Sybex. He has a weblog at
Enter the code shown: