SOFTWARE ECONOMICS PART 3
About people and problems
During the 20+ years of software development experience in all layers of organizations I have VERY often seen that people describe any problem they are confronted with in terms of solutions to that problem. Accepting the solution as they describe it might eventually bring you, the developer in problems as many more issues might arise during development. Did you ever hear about requirements creep? Well, here is the classical situation how this can happen, and there are several other possibilities as well.
So our first DUTY is to find out whether the solution as described is the answer to the real problem. If we are able to put aside the proposed solution for a while and focus on the assumed problem we might find out this is the outer layer of the onion. The simplest way to peel this “problem onion” is with one basic question “WHY?”
WHY “WHY”, and how often??
Asking WHY the proposed solution is indeed a solution might give an answer that goes one layer deep. Asking then WHY the client needs that problem solved brings you yet another layer deep. Most of the times, asking about the problem that is then solved and WHY it needs to be solved (what good does it do for the client) will eventually bring you to the real core of the problem.
Using this information as a starting point might give totally new specs, if any, for the software that will solve this alleged problem (if any software is needed at all at that time).
WHY don’t I give an example?
Did I not? Hmmm, maybe I should do it, Oh well, WHY NOT. On one assignment I did some requirements gathering. During that type of work I found there was a wish to create a structure of 3 databases, identical in structure, posted on 3 different machines. These databases should be able to update themselves if they could connect over the network.
So I asked, “WHY do you want this, what does it fulfill?” The answer was that they wanted to assure that any layer in the hierarchy of the company could work with or look at the most recent data.
I immediately thought of user-rights first that could be set on one server, so I proposed that but still they insisted on having this structure of 3 databases. Not being sure what they wanted I asked once more: “WHY do you want this, do you really want everybody to look at the same data?” The answer was, “yes we want this, it feels like it is essential for us, and that way we also have a backup possibility.”
The word back-up triggered me, I had the gut feeling something else was going on here, So once more I asked, “WHY do you want this back-up feature, it has nothing really to do with data-synchronization or rights on the database”. Then they told me, “We have one server here, it serves both the factory as well as the office, this heavy workload brings the server down once or twice a week for nearly 2 hours, if we can save our data in 3 places instead of one we will be able to pick up our work much quicker.”
Obviously the malfunctioning / overloaded server was the problem here. I calculated for them how much this down-time did cost them. With 75 people in the factory and about 35 people in the office and an average of 1.5 times down A WEEK for 2 hours this would cost them about 1,716,000 euro on a yearly basis on employee costs alone ((75+35)*1.5*2)*100 euro/h.
Since this company was very strict on budgets I asked them whether they had these costs included in there budgets…. Guess what, they had not.
Getting a server for about 10,000 Euro (included some additional, off the shelf, software) they saved a lot of money, without me writing one letter of code. And they had that back WITHIN a week, saving 33000 euro a week ain’t that bad, is it?
The morale behind this is that as developers we should not have the attitude to develop blindly what the customer asks for. We can sometimes be of absolute more service to ask further until we have a clear view on what the REAL problem is. Using that as a starting point we can then again decide whether or not developing software is the way to go.
This asks courage, especially when you do this the first time, or you are in need of some turn-over. However, on the long run this will absolutely serve you and your company in terms of reliability and turn-over.
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: