When talking about the #noestimates subject, one reaction (or analogy) I quite often get is "If you would buy a car..." (you can put in anything here really) "...wouldn't you want to know what it costs?". Or similar "If you would remodel your kitchen, don't you want to know when it is finished and what it will cost?"
Yes, of course I would, there is nothing wrong with knowing, roughly, what something costs. But when it comes to creating software (building a system with software) the analogy doesn't quite fit.
Here is what I think:
First. As an individual you seldom make investments that you expect to payoff. There is almost never an expected return of investment. At least you don't make the investments based on it. But as a company, you should! If you want to invest in something, it must be valuable. Otherwise you probably shouldn't invest. Sometimes it's difficult to calculate the payoff for the investment, but it is always good to discuss it; what is the payoff if we build this software? That should at least have higher priority than what something costs. Because, if something costs $1000 and the expected return is $2000 or if it costs $10.000 and the expected return is $20.000, what would you invest in?
And if it is unimportant what the return of investment is, why is it important what it costs? (And you should then really try to shift focus).
When it comes to the question "How long will it take?" the obvious response is "Does it have to be finished at a specific date?" Sometimes it has to, sometimes not. There is quite often other resources that has to be booked or reserved (internal and/or external), that is important. But try to delay those decisions as long as possible. So the response might be "How far in advance do we have to book resources?".
And again, if something takes six months and returns $1000 or if it takes a year and returns $10.000, what would you prefer? And remember the old saying: Noone remembers a system delivered late, but everyone remembers a bad delivery.
And if it is unimportant what the return of investment is, why is it important what it costs? (And you should then really try to shift focus).
When it comes to the question "How long will it take?" the obvious response is "Does it have to be finished at a specific date?" Sometimes it has to, sometimes not. There is quite often other resources that has to be booked or reserved (internal and/or external), that is important. But try to delay those decisions as long as possible. So the response might be "How far in advance do we have to book resources?".
And again, if something takes six months and returns $1000 or if it takes a year and returns $10.000, what would you prefer? And remember the old saying: Noone remembers a system delivered late, but everyone remembers a bad delivery.
Secondly. The analogy is wrong in another way. Building a system isn't the same thing as buying a car (or anything). Software isn't a "dead" thing. Software has a soul, a heart, a life. So a better analogy is "How much does it cost to buy, breed and educate a dog?" That is really hard to tell, it depends on so many things. Especially since dogs are individuals, just like software tends to be (or at least should be).
Correct software is "alive" in the same way a building design is "alive." Buildings, nice buildings are much more that concrete and steel. But those funding the constrution of the building in which they are going to place tenants or art work, or customers buying the contents held in the building have some expectation of the cost of the building when it is ready for occupancy and a date of when they can occupy the building.
ReplyDeleteThe architect, the structural engineers, the welders, all contribute to "bringing to life" the beauty and functionality of the building. But the finance people, the people paying the money for this "thing of beauty" really do need to know with some degree of confidence the total final cost, and the expected occupancy date for them to continue to be interested.
Same for software. Someone, someplace, somehow, pays for all this ambiguity about features, functions, emergent "beauty" of writing software for money.
You ignore their interest at your peril. All the esoteric discussions of "big ended versus little ended" to stretch an analogy of the late 70's about how the bits were arranged in Motorola versus Intel processors, is a moot point - a silly point actually - to those paying for all this creativity.
Agree. But there's an important difference. Buildings, for the finance people, has an explicit return of investment. They know what they can charge those moving in to the building. In rent or fixed single price. They know that the building cannot be to expensive to build because they won't be able to sell it (noone wants to buy or rent it for that price). They know, in advance - before they build it, what the payoff for the building is.
ReplyDeleteDo we build software on the same promises?