|
Arguments against cut'n'paste estimation
One of the worst nightmares I've ever had dealing with estimations with a client is about having to *explain* to him that there is no such thing as cut'n'paste development that is going to cut time to five minutes just because the screen (or component, or service) *looks* similar to another one that is already made.
How the %$#/(&% do you explain to a non programmer why programming takes time?. They just argue that: "it is almos the same!! How difficult can be to cut and paste the code and make some little changes?. I don't think you need 3 days just to make that!"
On the other side, I also think that programming is still more complicated that it should be. How many times you have done stupid little Create/Modify/Delete screens to manage simple database catalogs and so?.
It must be quite annoying to management people hearing that you cannot deliver their little stupid change that is supposed to be very similar to the current functionality just because the former developer did something that does not allow you to make the change easily enough.
Should I put toghether a '5-minute introduction to programming' presentation and give it to every customer before talking about time estimates?
The worst thing is that most of the times I have run into this kind of argument has been with promoted-to-the-level-of-their-incompetence former-programmers that still dont get it.
=(
.NET Developer
Friday, January 30, 2004
My response to "it shouldn't take three days to do that!" would be to hand them the keyboard and tell them to write the damn thing themselves, if they know so much.
Alyosha`
Friday, January 30, 2004
.NET Developer wrote, "I also think that programming is still more complicated that it should be. How many times you have done stupid little Create/Modify/Delete screens to manage simple database catalogs and so?."
See Joel's Fire and Motion article.
When I first I got into this business, I wrote more Create/Read/Update/Delete (CRUD) business applications than I care to remember. Creating them tended to be a pretty straight forward process. Just about every large corporation/consulting firm was programming with COBOL, used skeleton programs, standard routines, etc. Back then we called it "fill-in-the-blanks" programming as opposed to cut'n'paste development. I miss those days simply because I was usually able to put in a normal 40 hour work week as a salaried employee.
One Programmer's Opinion
Friday, January 30, 2004
Well for certain kinds of applications, business accounting types I do now have a framework which means I can plug together solutions quickly with a minimum of coding.
But then the coding is the least part of it.
Simon Lucy
Friday, January 30, 2004
One way to explain why programming takes time is to say that programming is a bit like writing a mystery novel.
In a mystery novel, there is a murder in the beginning, a lot of clues in the middle, and the murderer is revealed on the last page.
Let's suppose you want to change the murderer. Instead of the butler, the murder was committed by the waitress. Sounds like a simple change. Just change the last page and be done with it.
Not so! You must go back and check every clue and change them appropriately.
Humans can tolerate a certain amount of mistakes in a mystery novel but computers do not forgive mistakes. In a computer program every clue must be correct or the program does not work correctly.
jannek
Friday, January 30, 2004
jannek, aweseome analogy. I've been pondering how to explain this to people all morning, after reading the main comment in this thread. I think you hit the nail on the head. If you don't mind, I'll be re-using that analogy (probably often) in my daily work now :)
Andrew Hurst
Friday, January 30, 2004
Very nice, jannek. Mind if I cite you on my blog so I can remember that for later? (=
Sam Livingston-Gray
Friday, January 30, 2004
I have this Mercedes that I would like very much for Ford to duplicate. How difficult can it be? You just take some measurements and make the machinery to the same specs....
No, you mean it's not that easy?
www.MarkTAW.com
Friday, January 30, 2004
jannek:
Great!!
That was what I was looking for, some simple way to understand and explain why *little* changes mean a big difference when put in the context of a system that is not prepared for that change.
thanks everyone for your comments.
.NET Developer
Friday, January 30, 2004
"there is no such thing as cut'n'paste development that is going to cut time to five minutes just because the screen (or component, or service) *looks* similar to another one that is already made."
Yes there is. It's called Ascential DataStage. :)
T.J.
Friday, January 30, 2004
"Mystery novel" is a good analogy! But I was reminded of something Steve Maguire said in "Writing Solid Code", in chapter 7:
"Using surprise and suspense in a mystery novel is critical, but using them in code is terrible. When you write code, the plot should be so obvious and boring that other programmers know well in advance what's going to happen."
Designing systems that are sufficiently decoupled that you can change the details of one without affecting the other is HARD though. And sometimes, even that isn't enough. Why? Because the assumptions about what the decoupling should be can themselves be insufficiently flexible.
I've got an amusing (well, I find it amusing, your mileage may vary) story about a "trivial" customer request that involved re-architecting most of Visual Basic, but rather than posting about it here, I'll just put it up on my blog.
http://blogs.msdn.com/ericlippert/archive/2004/01/30/65327.aspx
Eric Lippert
Friday, January 30, 2004
I like the mystery analogy as well.
One I've used in the past is a watchmaker. When you've gotta change the size of one gear, all the other gears have to adjust too. Different sizes, speeds, teeth patterns, etc. I also use the analogy to describe why I like programming.. People can understand tinkering in machinery when they have a physical analogue.
H. Lally Singh
Friday, January 30, 2004
 Recent Topics
Fog Creek Home
| 
