Live data from Hacker News

Dear Client, Here’s Why That Change Took So Long

simplethread.com

1–10 of 285 posts

Re: Dear Client, Here’s Why That Change Took So Long

#3
Too much protest here. I feel you'd be eventually judged on those numbers as well. Are you a time & materials shop? The fact is that you either start a clock when you start working on something and stop it when it's done or you have standard times that things should take (like an auto shop does.) If you're working efficiently, you can tell your client that you work efficiently and this is simply how long the change took. If you're procrastinating and charging the client for the time, you should fix that.

Re: Dear Client, Here’s Why That Change Took So Long

#4
post #2

Part 4: learn to bill by the day and never again have to worry about justifying how long a simple-sounding code change took to make.

So would you bundle up a series of these into a day? Or just assume the client is cool with this taking a day?

I believe you're also assuming you're servicing a client whose got a lot of budget to blow on a lot of small changes.

Re: Dear Client, Here’s Why That Change Took So Long

#7

I'm not a dev, but this feels like arguing with a strawman. There are really customers who complain that a change to their codebase took a single day to implement? I would be utterly thrilled if I could get a vendor to turn around anything that quickly

I am guessing they want to pay $50 for 10 minutes of work instead of $2400 for 8 hours of work.

Re: Dear Client, Here’s Why That Change Took So Long

#8

I'm not a dev, but this feels like arguing with a strawman. There are really customers who complain that a change to their codebase took a single day to implement? I would be utterly thrilled if I could get a vendor to turn around anything that quickly

It's not a strawman, it tends to be an issue if you work somewhere where the core business is not software and client managers are less used to dealing with software or saas products and make commitments based on what they are more used to.

If the bulk of the business that clients deal with are happy to make ad-hoc changes and updates to delivered delivery materials on a per-hour basis they can often turn those around in a few hours, and then they ask for the same from a computer system and get a shock when they are quoted 10 times the price for a change to a "cheaper" thing. They're paying more for the manual work generally and see the computerised system as a "cheap option".

Re: Dear Client, Here’s Why That Change Took So Long

#9

I'm not a dev, but this feels like arguing with a strawman. There are really customers who complain that a change to their codebase took a single day to implement? I would be utterly thrilled if I could get a vendor to turn around anything that quickly

A day would be incredible. We have a show stopping issue with a vendor's software. Several reports we have to run daily takes 6-12 minutes to run, when it should take seconds at most.

I've been communicating with their lead reports developer. The fix is done, tests are written, QA has given it the rubber stamp, but he's simply not allowed to push it to our instance until their next code release on the 22nd. It makes no sense, and it's certainly not how I run our side of things.

In the meantime, my users will lose 6-12 hours of productivity this month (15 days, 4 reports, 6-12 minutes each.)

Re: Dear Client, Here’s Why That Change Took So Long

#10
What gets me is that software has been a mainstay of modern business for _at least_ 30 years. And this whole time, every single professional software developer has been telling every single non-software developer the exact same thing, over and over: this takes longer to do than you think. If, say, 80% of developers were knocking things out, problem free, in an hour or two and the other 20% were hanging back like a 50’s union boss saying, “yeah, that’s going to be an all-day job easy”, then maybe I could understand why they STILL think we’re lying. Even if 20% of the devs could get things done in the time they seem to think it takes and the other 80% were hemming and hawing I could still understand this perspective. But that’s not the ratio. 0% of devs can reliably complete tasks in the time that MBA’s seem to think it should take and 100% of devs take longer than they “wish” it would take and THEY STILL AREN’T PAYING ATTENTION.
Post reply on HN