|
AlexCode wrote: I believe it's a lack of a full & deep
I thought you were about to say "full & deep sleep!" 
Marc
|
|
|
|
|
That too! 
Another bad think project managers usually do is to force after hours when they're not necessary.
Sure the project is on delay but I only believe in "after hours" development when the release is to be made on the next day... maximum in 2 days, never more.
If a PM exposes a team to a long non stopping effort the bad side effects are greater that the profit we get from it...
|
|
|
|
|
AlexCode wrote: Another bad think project managers usually do is to force after hours when they're not necessary.
I had a manager who once recommended I put in 70-80 hour work weeks (there were no upcoming deadlines, he just thought this is what an engineer should normally put in). I wrote a letter to the president threatening to sue for labor law violations. Mr. Manager became my best friend after that. 
Marc
|
|
|
|
|
Nice boss you add there...
It's easy to look good on schedule like that...
Sadly enough there's a lot like that and after a short while project start slipping too.
|
|
|
|
|
AlexCode wrote: I believe it's a lack of a full & deep book of specifications. From this we get all sort of problems... nothing good can be expected from a bad
Not much good has come from over written, inflexible specifications either.
I shuddered when I read "book of specifications."
regards,
Paul Watson
Ireland & South Africa
Fernando A. Gomez F. wrote: At least he achieved immortality for a few years.
|
|
|
|
|
Sorry, just want to start asking what you mean by "shuddered", I don't know what that means, sorry.
by
Paul Watson wrote: inflexible specifications either
I never meant to defend fixed specs, I just defend that every peace of it must be documented for the good sake of the development process.
I even defend that when things get big and a lot of money is on the table the meetings should be recorded.
This is the only way you can defend yourself when a customer blame you for not delivering the "goods" in time. Not delivering in time in large-scale project mean that you must pay a fee (usually a big and nasty one) for each day of delay so you better document yourself when time comes to defend yourself.
|
|
|
|
|
AlexCode wrote: Sorry, just want to start asking what you mean by "shuddered", I don't know what that means, sorry.
To shiver convulsively. If you saw a dead person in the street, you would shudder.
regards,
Paul Watson
Ireland & South Africa
Fernando A. Gomez F. wrote: At least he achieved immortality for a few years.
|
|
|
|
|
I'm lucky I get anything done with the amount of other work I have to think about!
You don't have to be mad to code, but it helps.
|
|
|
|
|
I know that sometimes people just want us to do something for them, but they don't realize that we need very precise instructions. I often get the feeling that the users don't take the time to thorougly think about it. I like ot write code and help people and all that, but when people don't respect my time and my work, I'm very angry.
Something like this fell on me just last week. It went something like.
"Hey, could you do something for me? Parse this file and drop all lines which are like this."
And I was there, like,
"Sure, I'll just write some regex, and in 30 minutes tops it'll be done and compiled."
I did that, and after half a day, they added,
"actually, I only want the last few lines, the ones after the line which starts like this"
So, I thought to myself,
"in 2 minutes, add a boolean variable, another regex, and it'll be done"
Eventually, after a couple days,
"I need the info from that line you had to skip, so will you please add 3 columns with some data you'll get from a crystal ball." Actually, that last one, I had to figure out by myself, asked the question, and got the answer "Yes, I'll need that too". After thought, I should have done it secretly, wait for them to realise they needed it, and then deliver it.
I hope they don't ask me for a web report next. 
I should start making people realize what I must be given to properly do my work.
"Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra
|
|
|
|
|
Donkey Master wrote: I should start making people realize what I must be given to properly do my work.
Sure you must make them realize that you need proper information.
But that is what separates a software developer from a programming monkey, I think.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
#2 and #4 go together quite often, where the client doesnt understand what is needed, gives the task, and later changes the specs...alot...and often, as they refine what the actually want. Plus, of course, it sometimes just so happens that you are given the task, and the timeframe to fit into, and you're just not asked...and all that, along with being given additional tasks to finish at the same time.
So yeah, I vote for most of the options.
"impossible" is just an opinion.
|
|
|
|
|
Agreed, I'd have voted for most of the options too. All the mentioned reasons happen most of the time except for #3 that happens less often.
|
|
|
|
|
As a self-employed web-developer I think this is the most common reason that causes delay. I have had this problem so many times, when all of sudden client don't like something they said they loved it before.
Anyone else agree??
- Stop thinking in terms of limitations and start thinking in terms of possibilities -
|
|
|
|
|
Typically, in small companies, the development team are subject to the following turbulent turmoils:
1) Sales team has astronomical commitments to the client regarding the features and the date of promise.
2) The clients, who seem to make the most of the hapless state of affairs of the small vendor who might not have stringent processes would try to extort as many things as possible at the same price.
The result is that poor development fraternity would reel under acute stress and pressure.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Agree,
I work for small company. 2 weeks ago my boss called a meeting to 'happily' inform us the feature he sold to a client, which are none existent and will take us 3X more time than the promised date. Go Figure...
/* I can C */
// or !C
Yusuf
|
|
|
|
|
I could not agree more. 
Yes, everything on that list is relevant and often more than 3 or 4 options apply at any given time, but changing specs is (particularly at the last minute) not easy or fun. People always seem to think that it'll be a small nuisance you can overcome in 30 min.  Not realising that you might have to change the way the whole app works just to accommodate that "little change".
-- For a moment, nothing happened. Then, after a second or so, nothing continued to happen --
|
|
|
|
|
Parth wrote: all of sudden client don't like something they said they loved it before.
As a self-employed web-developer, isn't that the best you can get? Lots and lots of hours to bill?
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
I certainly agree that changing specs is one of the biggest problems. What I do is to write down those specs, tell my client what it costs, when it will be done, and then do the job. If the client changes their mind about the specs, I write the new specs down and call that version 2 ... I don't start implementing any new stuff until version 1 is done.
When the client suddenly changes his/her mind, then it is a whole new project.
Ask not whether it is useful. Ask what it is useful for.
|
|
|
|
|
This is why agile development is so magical.
|
|
|
|
|
JasonCordes wrote: This is why agile development is so magical.
Thats also why in most cases it is so mythical
codito ergo sum
|
|
|
|
|
This is why agile development is so magical.
Thats also why in most cases it is so mythical.
Only if you work for Ogres, Cyclopians, Trolls, and Orcs.
If your customers buy into it, it works fantastically.
|
|
|
|
|
I don't work with Ogres anymore
They take the word deadline a little to serious.
codito ergo sum
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
