This week's book giveaway is in the Reactive Progamming forum. We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line! See this thread for details.
No matter what process you use, you're going to be asked, "about how long will that take?" Which often degenerates to "exactly how long?" or "yesterday would be good." If you're lucky, you will have a thorough knowledge of the problem domain and requirements will be clearly stated. By that standard for luckiness, I'm no Lou Gehrig... Anyway, I thought I would call attention here to a story on Slashdot that may be of interest. I haven't read it all yet, but it seems a mathematical proof has been offered that could explain the sick feeling you sometimes get in the pit of your stomach when you have to guesstimate project schedules. Slashdot article
not only the schedule , but the cost estimation is also very important. infact the most important.
posted 17 years ago
Absolutely it must be true that accurate estimates have some value. And, of course, one can derive cost estimates from schedule estimates and these can be helpful as well. I think it would depend a lot on the project, though. For example, if a project were of an optional nature, accurate cost estimates could be used to decided about proceeding with the project. I tend to be involved more with "we need it" type projects, for which a cost estimate might be nice to have. At some level somebody says "do it" and we do, without much thought to cost. Usually at this point we don't really know the requirements anyway, so it would be an excercise in futility anyway. In fact, it is often the case that the real requirements are discovered along the way of the development process. I find it difficult to convey that, though, when I'm asked about schedule estimates. We talk about ideal engineering days (which don't exist in my workplace) and maybe a confidence interval, but often miss the fact that the requirements are a moving target. Also, it's interesting to note that studies done by (or at least cited in "Peopleware") DeMarco and Lister show that developers tend to miss their own estimates very frequently, miss estimates of a system analyst somewhat less frequently and actually work fastest in the complete absence of any schedule estimate. So, is estimating much ado about nothing?
Originally posted by shailesh sonavadekar: not only the schedule , but the cost estimation is also very important. infact the most important.
posted 17 years ago
Mark , don't you think that every developer adds his own safety & ultimately this becomes snow ball effect & the whole estimate becomes fail safe project estimate. still project runs in cost & schedule overrun . why ? Most of the time it is due to improper requirement analysis or infact no requirement analysis. some times it is due to failure of the technology to be used , rather time taken to master the technology taking a lot of time. that is why in XP , Kent Beck proposes to develop in incremental way & involving stakeholders at all time & one more thing not designing for future , but for today. you correctly mentioned about the " We Need it " project & " Do it " projects. it is very , very true in the flux of technology in today's internet arena. For that only you should have proper requirement analysis & the document signed by the client. that is why your SRS comes into picture & that is why the whole branch of S/W engineering is evolving. You mentioned about the Demarco's "Peopleware". it is really epic. regarding the issue of estimate of system analyst are more or less met , I really feel that when developer estimates , I think he / she estimates for one's own module. But , during actual project , since programmers being artist , they want to build everything from scratch. Using of the shelf components , reusing already exiting componets , the whole issue of reusability looses it importance & the target gets missed. testing is the area which is neglected . thus , a significant amount of time is lost in rework there. that is the best part of XP. you write test cases first. so the chances of rework are less. I think there also many people don't pay much attection. There is one principal in total quality management , you invest time & money in prevention ( Preventive cost ) than in firefighting afterwards. The whole issue still hinges on continuously changing requirements. it is not going to change & even customers are more tech - savvy now a days. so , the only otion seems to be incremental deelopment & following certain good practices of XP. What do you say ? Shailesh.
posted 17 years ago
I think we largely agree. XP makes a lot of sense to me, but as a technical sort of person I find it difficult to sell. I mean the people you have to sell it to think it comes in a box (and isn't Linux cheaper, anyway?)... I get it that a suite of tests has a lot of value, but unless that gets specified, it seems it is viewed as unwelcome activity. And heaven forbid two people working on the same thing at the same time! In starting this thread, I simply hoped to call attention to the difficulty of estimating IT projects. As far as I can tell, XP is not yet widely used and I would think many people would be able to relate to the problem of managers not understanding the true difficulties of estimating a project that they can't even specify in much detail. How there is a pervasive assumption that a developer somehow just knows how long it will take to complete a vague task in unfamiliar territory really escapes me.
ice is for people that are not already cool. Chill with this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop