The user can move the box anywhere they want it, but most of us think that it shouldn't go smack in the middle like that. It obscures the primary data and is an unnecessary step for the user to move it. One of our customers asked for a quote to get that fixed. Got that - a quote to reposition a popup box? ...Quoted at 40 labor hours.

Granted I understand about adding in time for project management and QA. But still.... WTF?

I suppose it all depends on how many pixels you have to move it...

jetcitywoman:

The user can move the box anywhere they want it, but most of us think that it shouldn't go smack in the middle like that. It obscures the primary data and is an unnecessary step for the user to move it. One of our customers asked for a quote to get that fixed. Got that - a quote to reposition a popup box? ...Quoted at 40 labor hours.

40 hours, eh?  How heavy is the box?  Do you need to use a crane to move it?  Because that would cost extra.

Just save the last position (so it will be wherever they moved it to next time) and redisplay it. Sounds like the customer needs to add more feature requests to fit that 40 hours.

When I was first out of school, I was working on an app that was translated into 7 languages at the time.  It was used to help diagnose engine (and other mechanical) problems with our equipment.  I was given the task of updating one of the strings, to which I replied, "That shouldn't be too hard."  The project manager responded with "There's nothing easy in ET" (ET being the software we were working on.)  Sure enough, about 8 hours later, the string was correctly repositioned for all languages.  A "simple" task of moving the string took 8 hours.  From that time on, my mantra became "There's nothing easy in ET" because sometimes even the "simple" things take a ton of time. Not necessarily because the software is written bad, either, but simply to verify changes etc.

40 hours to move a box seems a little excessive though.  Sometimes quotes come back high to discourage the user from going that route, I wonder if this is one of those times.

 From a previous WTF...

“Nothing – and I mean nothing – in IT takes less than 80 hours, and whatever you think it’ll actually take, multiply it by 20, and tell management that. You see, 80/20.” 

http://thedailywtf.com/Articles/The-Speedup-Loop.aspx 

taylonr:

Sometimes quotes come back high to discourage the user from going that route, I wonder if this is one of those times.

 I would bet your right.. Its like saying, "We're doing this as a favor for you, so if you're willing to pay."

My last company used to have a very demanding customer who wanted crazy unfeasible things done that would take forever (and was dictating the time-schedule).  Usually not enough time to hire new people to add to the project or anything.

Not wanting to turn down the customer's crazy request, the company would just come back with what they thought were excessive prices.  On more than one occasion the customer accepted the crazy price.

Moral of the story: Overcharge for everything.  Either they'll pay for it, or you'll have less BS task to distract you from the one not-overpriced-enough monster.

Bert:

 From a previous WTF...

“Nothing – and I mean nothing – in IT takes less than 80 hours, and whatever you think it’ll actually take, multiply it by 20, and tell management that. You see, 80/20.” 

http://thedailywtf.com/Articles/The-Speedup-Loop.aspx 

Some of the best advice I got in university was from a programmer who did a lot of freelance work. He said that however long you think the project will take, multiply it by 3. You'll still be lucky if it's done on time.

Of course, he was a Smalltalk programmer and you can't always trust what Smalltalk programmer say.

shakin:

Of course, he was a Smalltalk programmer and you can't always trust what Smalltalk programmer say.

Oh, and, by the way, I happen to be a Smalltalk programmer, too...  :-) 

I worked for a company where clients could request customized plug-ins.  The quotes we gave them were, of course, ridiculously high.  Given the industry that we were in (I'm not telling!), the clients usually signed off on it anyway.

The best part, though, was that our company still owned the plug-ins, which were generalized enough such that any one could use it.  If client 2 came along and wanted the same functionality, we'd given them the same ridiculous quote, which they would pay, wait a few weeks and then give them the previously designed plug-in.  It was like a license to print money...if only I got a cut... 

vt_mruhlin:

Moral of the story: Overcharge for everything.  Either they'll pay for it, or you'll have less BS task to distract you from the one not-overpriced-enough monster.

It's a good system to use. I occasionally get contract gigs punted to me by mates of mine, and often it's doing unpleasant maintenance work and usually when I'm already very busy, so I quote about triple my normal contract rate. Either they say no and I keep my free time, or they say yes and end up paying me enough that I don't care about working ridiculous hours.

pitchingchris:

Just save the last position (so it will be wherever they moved it to next time) and redisplay it. Sounds like the customer needs to add more feature requests to fit that 40 hours.

While this makes the most sense, all of a sudden you have to contend with a lot of other issues like "what if the user changes resolutions or had a 2nd monitor they don't have now".  Not to mention figuring out a suitable way to store the settings, etc.  Sure, most systems have a preferences scheme already fleshed out, but you can't rely on that.  Suddenly you're writing all kinds of code to make sure its within screen bounds, that it stores correctly, check to make sure the setting is there, if not, create it, etc. etc. etc.   Its a situation where, if you're going to do it for one window, you should just do a blanket sweep on all of them to make something like that worthwhile.

shakin:

Some of the best advice I got in university was from a programmer who did a lot of freelance work. He said that however long you think the project will take, multiply it by 3. You'll still be lucky if it's done on time.

I was often guilty of underestimating after starting my first "real" job (you know, where you actually have deadlines and estimates that are not "oh sure, that'll be easy gimmi a few minutes").  A co-worker shared a interesting method with me.  Add 1, and increase to the next logical unit of time.

1 minute becomes 2 hours, 2 hours becomes 3 weeks.  However I'm sure it all falls apart once you're estimating in weeks/months.

vt_mruhlin:

My last company used to have a very demanding customer who wanted crazy unfeasible things done that would take forever (and was dictating the time-schedule).  Usually not enough time to hire new people to add to the project or anything.

Not wanting to turn down the customer's crazy request, the company would just come back with what they thought were excessive prices.  On more than one occasion the customer accepted the crazy price.

Moral of the story: Overcharge for everything.  Either they'll pay for it, or you'll have less BS task to distract you from the one not-overpriced-enough monster.

Totally agree ! If you've ever done contract work or worked for somebody who undercharged just to get in the door, you'd be surprised how much stuff they want just to fit that price. Better you overcharge like you said.. Then they won't ask for more without a good reason because they don't want to pay too much more than they have to. Works for everyone.

belialNZ:

shakin:

Some of the best advice I got in university was from a programmer who did a lot of freelance work. He said that however long you think the project will take, multiply it by 3. You'll still be lucky if it's done on time.

 

I was often guilty of underestimating after starting my first "real" job (you know, where you actually have deadlines and estimates that are not "oh sure, that'll be easy gimmi a few minutes").  A co-worker shared a interesting method with me.  Add 1, and increase to the next logical unit of time.

1 minute becomes 2 hours, 2 hours becomes 3 weeks.  However I'm sure it all falls apart once you're estimating in weeks/months.

 

snoofle:

belialNZ:

I was often guilty of underestimating after starting my first "real" job (you know, where you actually have deadlines and estimates that are not "oh sure, that'll be easy gimmi a few minutes").  A co-worker shared a interesting method with me.  Add 1, and increase to the next logical unit of time.

1 minute becomes 2 hours, 2 hours becomes 3 weeks.  However I'm sure it all falls apart once you're estimating in weeks/months.

 

Based upon 25 years of experience, it doesn't fall apart!

Ah, but what you're not telling us is that it at the time you expected it to only take you 2 years to gain that experience!

jetcitywoman:

Quoted at 40 labor hours.

project management - 1 day

actuall coding - 1 day

QA - 1 day

Documenting the feature - 1 day

unexpected buffer - 1 day

5 x 8h = 40h

Looks like a well calculated project to me.

Actually it may happen that the client in question is a regular customer that gets somewhat lower hourly rates so they made it up by increasing the number of hours.

Nelle:

5 x 8h = 40h

Looks like a well calculated project to me.

5 x 8h = 4h

snoofle:

belialNZ:

I was often guilty of underestimating after starting my first "real" job (you know, where you actually have deadlines and estimates that are not "oh sure, that'll be easy gimmi a few minutes").  A co-worker shared a interesting method with me.  Add 1, and increase to the next logical unit of time.

1 minute becomes 2 hours, 2 hours becomes 3 weeks.  However I'm sure it all falls apart once you're estimating in weeks/months.

 

Based upon 25 years of experience, it doesn't fall apart!

Last project I worked on, (very optimistic) estimate was 2 months x 3 people, going productive after 6 months x 6 people. So, the little bit forced calculation is: estimate was 2 months, effectively 3 years (6 x 6). Oh well, it does fall apart a little. OTOH the multiplying factors are never exactly right.

PJH:

Nelle:

5 x 8h = 40h

Looks like a well calculated project to me.

This came through on the mail as

 

5 x 8h = 4h

and I was wondering if you were using a flash calculator.

but 40h is 28 !   assuming you were doing hex :)

No no no, you guys are using the wrong units to begin with! You need to measure everything in kilotons!

E.g. you have 10,000 kT of ironium, and it costs 2,000 kT of ironium to build a Doom Star, but a doom star can do 100 kT of damage in a salvo and has 5,000 kT of damage resistance and costs 100 kT of ironium in monthly fuel.

 Therefore your doom star has an overall efficiency rating of... 42 kT! :P

When I was a coder, the way I would estimate things was, I'd figure out the number of files that would have to be touched (be they source code, html, xml, config files, etc) and multiply it by 8 hours. No matter how small the change to each file. Everybody always said my estimates looked too big.. but then the only project that was ever on time in the history of the company was one that I estimated my way.

However, even using my rule of thumb, it seems like a WTF if you have to touch 5 files to move a window around.

Licky Lindsay:

When I was a coder, the way I would estimate things was, I'd figure out the number of files that would have to be touched (be they source code, html, xml, config files, etc) and multiply it by 8 hours. No matter how small the change to each file. Everybody always said my estimates looked too big.. but then the only project that was ever on time in the history of the company was one that I estimated my way.

However, even using my rule of thumb, it seems like a WTF if you have to touch 5 files to move a window around.

@Lindsay: Nice avatar :)