/\ndy Hunt<br /> <a href="http://www.PragmaticProgrammer.com" target="_blank" rel="nofollow">www.PragmaticProgrammer.com</a>
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Originally posted by Mark Herschberg:
the other person goes off and does something totally different from what you expected, but it meets the specs you gave him!
/\ndy Hunt<br /> <a href="http://www.PragmaticProgrammer.com" target="_blank" rel="nofollow">www.PragmaticProgrammer.com</a>
Originally posted by Avijeet Dash:
whats r your notions of most difficult part of s/w development?
Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
!_I_Know_Kung_Fu_!
Originally posted by JUNILU LACAR:
The next hardest thing in development I think is getting people to break old habits.
I Hope This Helps
Carl Trusiak, SCJP2, SCWCD
Originally posted by Sanjeev Arya:
The most difficult thing to learn is to keep the focus (on having fun) in times of frustration.
Originally posted by JUNILU LACAR:
The next hardest thing in development I think is getting people to break old habits...While they are eager to learn OO style development, they are still hanging on to their old ways of doing waterfall-style SDLC.
It's a Catch-22: They want to do OO but they resist adopting practices that bring out the full advantages of OO because those practices are contrary to what they believe are the "correct" practices. "Yes, we'll do OO but we won't do iterative development and we won't do use cases and we'll have the testing phase at the end of the project, etc."
Junilu
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Originally posted by Sanjeev Arya:
The most frustrating thing in programming seem to be unclear and changing requirements.
Unclear: When the client is fuzzy about what they want the product to do. This is different from communication problems. I am talking about times when the requirements themselves are fuzzy.
Changing: This is even more frustrating when the clients see the product (maybe prototype), get a better idea of what they actually want), then change the requirements drastically.
This can be a pretty subtle issue... if they really acknowledge the workmanship, applaudand encourage you to do it even better the next time around, then thats still ok. But if they try to pretend they have known it all along that this is not what they wanted in the first place, thats really frustrating.
Sanjeev
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Originally posted by Desai Sandeep:
Developers usually do not understand the time factor as a crucial aspect for deliverables.They get into "analysis paralysis" or "design paralysis" stage.They keep saying "Let us understand the system little bit more" or "Let us design further before doing actual coding".Some one needs to always keep then aware about the time factor and about deliverables.
Take any project, you would always see the developer complaining - "If and only if, we were given further training, we would have delivered a better solution".
/\ndy Hunt<br /> <a href="http://www.PragmaticProgrammer.com" target="_blank" rel="nofollow">www.PragmaticProgrammer.com</a>
For me the hardest thing is to keep pace with technology.
Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
Originally posted by Mark Herschberg:
Your comments imply that iterative development brings out the best of OO. Can you elaborate?
have difficulty keeping my focus, getting lost in possibilities, instead of taking care of the necessities.
Dave Thomas <br />Author of "<a href="http://www.amazon.com/exec/obidos/ASIN/020161622X/ref=ase_electricporkchop/002-7467239-7061602" target="_blank" rel="nofollow">The Pragmatic Programmer: From Journeyman to Master</a>
Originally posted by JUNILU LACAR:
My reasoning goes back to software being more of an organic thing: something that needs to be grown rather than built. OO and iterative development are compatible because you can start by identifying major classes, build a skeleton, and grow the system from there. Software development is not a linear activity and OO development and iterative development reflect this non-linearity. There's a natural flow to it that is absent from the rigidity of the waterfall method. Procedural type programming should in fact also follow an iterative approach.
Junilu
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
Originally posted by Mark Herschberg:
I think OO benefits can be achieved independently of the process use; although I will conceed that a bad process can hurt an OO (or any) project.
Originally posted by Desai Sandeep:
- Developers usually do not understand the time factor as a crucial aspect for deliverables.They get into "analysis paralysis" or "design paralysis" stage.They keep saying "Let us understand the system little bit more" or "Let us design further before doing actual coding".Some one needs to always keep then aware about the time factor and about deliverables.
- Take any project, you would always see the developer complaining - "If and only if, we were given further training, we would have delivered a better solution".
[This message has been edited by Desai Sandeep (edited May 25, 2001).][/B]
Mark Herschberg, author of The Career Toolkit
https://www.thecareertoolkitbook.com/
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
|