Mark Halloran

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.

m

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.

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

m

You can get Craig Larman's book with a pair of video tapes, too. Here's the link for it on Amazon....
http://www.amazon.com/exec/obidos/ASIN/0130255599/qid=982680280/sr=1-2/ref=sc_b_2/105-5547603-7743127
For my money, though, I would just read the book.

Mark

Originally posted by bf19314:
I heard some bad thing about it. No sure, your should try Craig LArman's Apply UML and Pattern.

I'm currently working on SCJD and am really enjoying the project. Reading this thread gives me pause because I like the nature of the work as a developer (if I can assume I will have a non-trivial application to develop).
I think I would still be interested in the materials which are covered by the Architecture exam, though I would be loathe to get too far away from the code for now.

Mark

Not sure which would require less work, though I agree with another post that the journey should be enjoyable anyway. I'm currently working on SCJD and am having a lot of fun with it (so far, anyway).
Not that I was necessarily motivated by this, but I'm quite certain that I saw a salary survey a year or so ago which compared SCJD vs. SCEA where SCJD came out on top. This was probably before the arch exam was revamped, though, so maybe it would be diffrent today.

Mark

Originally posted by Raj Mehra:
Just wondering if someone has done all of the three. I need to know which one should be better choice a SCJD or a SCJEA. Out of these which one requires more labor.
Thanks in Advance,
Raj.

Oh... I should probably have mentioned that this book covers the 23 GOF patterns with Java implementations and adds a few that I hadn't seen before.

Mark

Originally posted by Mark Halloran:
I got some value from Patterns in Java, Vol. 1 by Mark Grand. Here's a link on Amazon...
http://www.amazon.com/exec/obidos/ASIN/0471258393/qid=982678768/sr=1-1/re f=sc_b_1/105-5547603-7743127

Mark

I got some value from Patterns in Java, Vol. 1 by Mark Grand. Here's a link on Amazon...
http://www.amazon.com/exec/obidos/ASIN/0471258393/qid=982678768/sr=1-1/ref=sc_b_1/105-5547603-7743127

Mark

I'm not familiar with that book. I highly recommend UML Distilled by Martin Fowler, however. You will probably find that it is the shortest book on UML, which is a real blessing IMHO. I bet it does cover UML in sufficient detail for the arch exam.

Mark