|
I agree, incomplete specifications are often the main problem.
|
|
|
|
|
AlexCode wrote: I believe it's a lack of a full & deep book of specifications.
Bu how could we set up the specs if neither we programmers nor the customers have more than a general idea about what to produce.
R&D is the very process of getting this idea!
So, a full, detailed spec is pure poison! What is needed is a highly iterativem flexible, lightweight process. Probably involving prototypes destined to be scrapped.
During the time the full, in-depth-spec is grunted out by the concerned several comitees (involving any number of high, medium and low managers), one could have prototyped the relevant parts, decided the set of features and maybe started the real design.
To me it seems as if programmers crying for specs are crying for help, desperatly fighting their management process.
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"
|
|
|
|
|
jhwurmbach wrote: Bu how could we set up the specs if neither we programmers nor the customers have more than a general idea about what to produce.
R&D is the very process of getting this idea!
So, jh, you're saying it's okay to give a deadline when no one knows what needs to be done? Let the design changes begin!
NO ONE should be quoting times on a project defined with just "a general idea about what to produce."
If design-by-prototype is the methodology, then payment and time for the prototype development should be in the cost and paid up-front, and only after development, sign-off and payment for the prototype is a final price and time estimate produced.
A full, detailed spec defines the requirements, leading to a decent estimate of the development effort, and therefore time and costs, leading to a decent quote. The spec also defines when you're done, or at least a reasonable facsimile of it.
"Programmers crying for specs" are like builders looking for architectural drawings - let me prototype your house, give me a sign-off, then we'll start for real.
Or manufacturers looking for a sale estimates - I'll build a gazillion Edsel's, see if you can sell them.
Or better yet, a surgeon wanting for a diagnosis - let me take out your kidney, and if it doesn't help, I'll take out the other one, then maybe the spleen, then a little lypo on the tummy, remove a few brain cells,...
Don't worry, we'll get something you like as long as your cash holds out.
Gary
|
|
|
|
|
ghle wrote: So, jh, you're saying it's okay to give a deadline when no one knows what needs to be done?
Well - it depends 
But in principle, there is always the Triangel consisting of resources, features, and time.
Pick the two you want to keep fixed.
Normaly, when the deadline is really fixed (e.g. the underlying hardware is already in production), then the features will be clipped.
ghle wrote: let me prototype your house, give me a sign-off, then we'll start for real.
You did not ever work with an architect to build your house, right?
Because looking at prototypes is the one methodology by which an architect(-company) sells ist products.
You get to look at a whole lot of houses to see the architectural details you wwant to have included.
Precise because you, the customer, can not possibly make all the relevant decisions up-front in an informed manner.
ghle wrote: Or better yet, a surgeon wanting for a diagnosis -
I dont know what "Schnellschnitt" is in english, but I describe you the procedure when prostate cancer is to be removed:
The prostrate is cut out, as are the firse level of lymphatic knots sitting "downstream".
Then a pathologist is cutting it for microscopy, determinig if the cancer penetrated the outer capsule of the prostrate and whether there are signs for cancer in the lymph-nodes.
If both are negative, the surgeons close the wound.
If any one is positive, another layer of lymphatic nodes is inspected.
If these are also positive, metastasis can not be ruled out and the wound is closed, but the pationt will get chemotherapy.
ghle wrote: A full, detailed spec defines the requirements, leading to a decent estimate of the development effort,
In the business where I am working, we are building measureing-machines with a evaluation software.
Thats probably different from the n+1th business-logic.
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"
|
|
|
|
|
jhwurmbach wrote: ghle wrote: let me prototype your house, give me a sign-off, then we'll start for real.
You did not ever work with an architect to build your house, right?
Actually, I did. I looked at "his" designs. The plans were not acceptable and I learned after 3 revisions that the architect did not have the vision I needed. So I paid him for his designs and went somewhere else. I did NOT pay for the house. The builder didn't dig the foundation. (It turns out most of his designs were modifications of someone else's work - i.e., house plans.)
Time, Quality and Cost - the customer can pick any two.
Regarding the prostrate surgery - the surgeon goes into the surgery with a clear definition on what he is to do, how to do it, and scenarios and tests that indicate additional procedures. It is not an unknown, neither the initial nor the additional procedures. And there is likely a known time-to-completion for each process, which helps schedule the operating room and all associated services.
BTW - Software R&D along with hardware R&D, which appears to be your project, definitely creates different time considerations.
OT - My father, chief of surgery before he retired, was told by a neighboring auto mechanic, "What we do is very similar, diagnosing mechanical problems then fixing the problem."
Humoring the man, dad said "I guess you're right. Have you ever changed a valve in an engine?"
"Of course, many times" was the expected response.
"Ever do it with the engine running?" my father then asked.
End of that conversation! 
![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
Gary
|
|
|
|
|
I break down and cry. Plain and simple.. Maybe I should become an alive organ donor. I have to die sometime anyhow
Your point? Hire a lawyer?
|
|
|
|
|
For starters, the specification that goes with the project proposal to be signed by the customer must reflect 100% what the customer wants at that time.
This should be the Step 1 of a complex process that is software development.
From this point, changing specs are no problem to the development process because they imply a re-specification and a new time line.
This is so simple, why to we (I include myself on this) keep messing up?
My short answer is :"Because we don't review the specs..."
We keep accepting new functionalities to the apps without even telling the customer they will take time to deploy.
After a dozen "small" functionalities we have a week of extra development and a customer still thinking everything will be done on the same schedule.
Now, or the initially defined schedule is perfect (it never is) or the "fear factor" we put on the time line is enough to handle this slip... none usually combine enough time and the schedule gets out of control...
Then you try to explain the customer you had to do all that extra work but it's too late, they just don't care about it, it passed too much time since they have ask you to do it and you actually said you would do it without any comments...
What I mean is, there must be a specification,this specification must be updated as there are changes to it and this update must be transparent to the customer, "he" must know about the development changes so there's no surprise when "he" expects to receive the product.
|
|
|
|
|
AlexCode wrote: What I mean is, there must be a specification,this specification must be updated as there are changes to it and this update must be transparent to the customer,
That is what I am saying with other wordes "iterative", "agile".
Deep, detailed, multi-volume specifications are enormously costly in itself. They tend to be taken as if being etched in stone and brought down from mount sinai.
Maybe there are segemtns where this works, but as a whole you are only forcing the customers to try to stuff *everything* in there. Up to a level where no one can handle the complexity - and thats where projects start to fail.
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"
|
|
|
|
|
jhwurmbach wrote: Deep, detailed, multi-volume specifications are enormously costly in itself.
But necessary... you need something to base your development costs.
No customer will embrace an ongoing project without even having an initial budget for it.
Like I said, we need a well documented book with all the specifications and we must update it whenever there are changes to it. This is the only way we have to protect ourselves from customers saying the slip fault is entirely ours.
|
|
|
|
|
AlexCode wrote: jhwurmbach wrote:
Deep, detailed, multi-volume specifications are enormously costly in itself.
AlexCode wrote: But necessary... you need something to base your development costs.[...]we need a well documented book with all the specifications and we must update it whenever there are changes to it.
You can't update it. You can possibly write an secification-change-request. and delivert it to your specification manager. This manager will then let the specification-change-request-steering-comitee decide upon your request.
See what I mean? A deep, detailed specification is unchangeably fixed. It is an valuable asset to both sides, developer company and customer. Sometimes, both use it like a weapon against the other side...
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"
|
|
|
|
|
Yep, that's what I mean too.
The structure you must present the change request to depends on how big the customer's organization is, but the basic idea is there.
You need to present that change-request proposal that is based on their changes demand... so they must approve that time-line changes or the changes won't be made at all...
It makes no sense that a customer can ask whatever he wants and you must do it if it wasn't specified on the initial specs.
New specs, new definition, new time-line...
I know this isn't linear, and the customer relationship usually requires more flexibility than this but it helps if we preserve the basics in mind when time comes to discuss the project issues.
|
|
|
|
|
Often the customer isn't clear what they need and come up with a list of specs that, if fully defined, would generate a project of several man-years without really delivering quickly what the customer wants. if a list of requirements is seen as a wish list which can then be processed by the project manager into a list of those items which need to be done first (along with essential dependencies) and the team can get started on those then a working product can be produced (and corrected if necessary) earlier in the project life cycle. Obviously there are issues with budgeting such an approach and a lot more details to be worked out with the approach that I don't have the space or time to go into here but I find that my projects are up and running faster with a lot of the wish list dross excluded. Want the customer really wants (whether they know it or not) is the essential functionality that lets them do their job as easily as possible. Everything else is icing on the cake.
OK, you guessed it, I'm a ScrumMaster. See the Control Chaos Web Site for more details on SCRUM.
Life in the fast lane is only fun if you live in a country with no speed limits.
|
|
|
|
|
SCRUM is just a new hype and absolutely not the silver bullet! It is nothing more than a box of project management rules which were valid and known years before SCRUM was born.
In my opinion it is not nessesary to give those rules a name (for example SCRUM - or XP or Agile or whatever). Also I think it is not the best idea to live 100% under these rules.
Just pick the parts you need to manage your development departmant. So you will get you own project management rules and you can call it "Ultra-Scrum" or "PX - Programming Extremist" or whatever.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
