Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss. print.
SOFTWARE ECONOMICS

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 first 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, in the remainder of the articles in this series, the importance of our beloved Fox within this context.


What do I mean by “Engineering”. Saying we are software engineers, and continuing to say this, does not make it a truth. It takes more than “just” creating code, to call ourselves engineers. First and for all I want to say that there is nothing wrong with creating code, if nobody cared to do that there would not be any software, let alone the presence of computers of any kind. If I am well informed those machines need software… (LOL)

Also I would like to state that calling yourself an engineer might be restricted by law. In the US there are several states where calling yourself an engineer while you miss some legal requirements might be against the laws of that state. In my working career I have seen engineers (by diplomas and by law) who made quite some expensive mistakes (probably educated mistakes) while I have also seen “non engineers” who made very wise decisions, economically and tradewise. What I understand here by an engineer is a person who has the way of working and thinking that might be expected from an educated and experienced engineer. Whether or not that person received an education as an engineer is not relevant in that perspective. It goes about the state of mind.

As Arthur Wellington said so well in 1887 in his book about railroad engineering, “engineering is the art of doing well with one dollar which any bungler can do with two”. Within Wellington’s definition each and every person making decisions in a business environment and really thinks twice before spending the money and on how to spend
the money best for the business, is, in that perspective, an engineer. Money has many forms. Whether you speak about the hard cash, a plastic creditcard or the hours you spend on some piece of work, these are all representations of money.

So, if you can make educated decisions on how to spend your money (time) against several alternatives and you can defend your choice with good rationales the chance is big your client gets some more bang for his hard earned bucks.

Setting software project constraints.
I assume here the ideal situation that the need for a piece of software arises and you have to start from scratch. Nothing is being developed yet. You do not inherit any code from a more or less illustrious developer who walked out for any reason.

Do you recognize the following situation?

One happy day you walk in at one of your customer’s office and he tells you he needs some software. He tells you what he needs to solve a certain problem he has to deal with and asks you for a price. You do your calculations, go over them once and again and finally come up with a price. The customer turns a bit pale round his nose and stutters, with sweat on his forehead and shaking hands, “t...t… t… that much?????”

HOLD YOUR HORSES HERE!!
SO, what was not right in the picture I described?
Do you have specification? Well, maybe…
Do you have complete specifications? Well, maybe…
Do you know what, solving the problem AS DESCRIBED, will bring as a profit for your client? Most likely not (yet) Does your client know how much he will profit by solving this problem? Same answer here, most likely not (yet). Is the problem that the software has to solve, the real problem?

AHA!! Now here is a question that nobody has asked yet. What if the problem can be made quite a lot smaller, maybe, just maybe, you can solve the REAL problem with a simple thingy, against a marginal price that the original question brought forth. Are the specs, as you originally received them, complete then? No way. They are ready for the shredder. All this leads to the question: “What is the real problem, and what is needed to solve that problem.” Only when that is clear you can start calculating. This is an entirely different area that I will look into in one of my later articles. Let’s talk money here, ‘cause that is what those PHB people are interested in.

Money, spent on anything in a business environment cannot be spent in a different way. Thus, allocated money is also a potential opportunity loss for other alternatives. Knowing that worldwide as much as 65 to 75 percent of all software projects are losing money for the owners makes it clear that we need to do something here. Getting an insight view on the financial consequences is one of those things.


For the sake of this article I will assume that you have a clear picture on what the client wants. You also have a clear picture on what it takes to develop this software.

The first thing to determine is the financial consequences for this project in terms of cost and profit. The primary reason people are in business is to make money. For that they take a certain amount of money, buy something that helps them make more money. This can be done either by reselling the sold good or to work more efficient so they can do more in less time. Kicking in an open door? I know.

The difference between the original price and the money they get is their profit.

One other thing they could do is put the money in the bank, get the annual interest and live from that money. In business they try at least to make the same interest as a bank and prefferably a lot more. This interest they make by doing business can be expressed by the MARR, which stands for the Minimal Attractive Rate Returned. This is expressed in a percentage of the original investments. In my example I will assume a MARR of 16%, any investment giving a lower interest will be rejected.

With this in mind we get back to the situation I described above. You determined the real problem, have the specs set up for the software to develop, you have a picture in mind what this might cost. And now you take the daring step that makes you stand out from other software shops. You go to the client and say something like, “Listen buddy, I could give you a price, now that I know what you need. However, before doing that I would like to set some constraints on the project in a financial way. That way we both know what we are up to. As for me this would be useful because then I know whether or not it is useful in a business sense to develop this software for you, I hate shooting myself in the foot. Let’s see what money you make, by using this software.”

Step one is to see how long this business asset will be in use. Are there any changes in the foreseeable future that might make the software obsolete? Think in terms of foreseeable changes in laws, business environment, new hardware that requires huge changes to the software and so forth. In this example I will take a lifespan of 5 years, an acceptable horizon in a business environment.

Step two is to determine the profits the software will bring within that time slot. For the sake of this example I assume your client needs a multiuser application
to be used on 3 different departments within the company. 25 employees will be using the software on a daily basis to perform their tasks.

Further investigation show that the average assumed profit by using this software will bring the time to perform tasks done by the employees down with 1 hour a day, thus freeing time for other tasks. These new tasks might bring some extra money, yet to be determined thus not taken into consideration here. In one year one person works an average of 225 days. (365 days – 104 weekend days, some time for vacation, short leave like sickness, days for holidays on working days etc).

It also shows that the new information might make it possible for the company to create new opportunities in new markets with an average of $100.000 a year. The costs for the employees, considering their wages, the costs for using computers, phone and officespace is near to $100 an hour.

The assumed money the company thus makes in those 5 years are as follows:
$2,812,500 saved on working hours.
$500,000 for new business opportunities.
Total amount $3,312,500 in 5 years. This is $662,500 a year.

Step three is to determine the amount of money the company would have to invest right now to make those same 3.3 Million in 5 years time. This is where the magic begins. Since it is obvious that the future is a series of equal payments and we have to find the unknown present we will use the Equal-payment-series present-worth calculation.

The formula for that is:



i is the interest in terms of the above mentioned MARR of 16%
A is the annual payment being $662,500 a year

We can now calculate P (present worth) as:
P = 662,500*((1.16)5-1)/(.16*(1.16)5)
P = 662,500*((2,1003416576-1)/(.16*2,1003416576))
P = 662,500*(1.1003416576 / 0.336054665216)
P = 662,500*(3,2743) (rounded to the fourth decimal)
P = 2,1847,766.75

So, in order for the company to have $3,312,500 in these 5 years they would have to invest 2,2 million right now. Wasn’t the saying “Time is money”? Well, it is!

OK, back to our situation.
One morning you walk in at one of your customer’s office and he tells you he needs some software. He tells you what he needs to solve a certain problem he has to deal with and asks you for a price. You do your calculations, go over them once and again and finally come up with a price.

Since you and your client now knows how much he would have to invest normally to get 3,3 million in 5 years time he laughs his head off, you only asked $500,000 to develop the software…

Lets see what that does for the MARR, just for the sake of this financial exercise.

We now have a known present and a known future, being an investment of $500,000 and a future of $662500 a year. What interest would that bring… Well that’s simple it is 662,500/5000 which is 132,5%. There goes one happy customer. And here is one happy developer (originally calculated the software on $150.000).

In my next article I will go a bit deeper into this financial stuff, and then show how the Very Fine Programming language of VFP will shine against, ahem, well, that other MS framework….

ABOUT THE AUTHOR: BOUDEWIJN LUTGERINK

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 http://weblogs.foxite.com/boudewijnlutgerink.

FEEDBACK

Prasad Sakharkar @ 2/2/2007 7:44:24 PM
Great Article, I have actually posted question about this in the forum and then just found your article.

It is like you are describing my situation over here.

MR GONZALEZ @ 1/23/2017 12:27:13 AM
LOKKING FOR A PARTER IN bussiness call 9179416423 thank you MR G



Your Name: 
Your Feedback: 

Spam Protection:
Enter the code shown: