Dear Client, Here’s Why That Change Took So Long • Hacker News Board

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

#21

Post by VBprogrammer » Tue, May 07, 2019, 4:34 PM UTC

projektfu wrote: post #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 t…

That change may not be worth the cost, or even just the opertunity cost, of doing it.

Someone presumably thought it was a good idea to make the change and assumed it would take only a few minutes work. I think the senario is that they are given an estimate of up to a day and can't understand how a developer could spend that much time on it.

For me it's a little too close to the memories of an old job. I tried in vain to argue with the owner of the company that having a 15 minute estimate category was pointless because the change itself would be drowned out by the fluff (creating branches, setting up data for a manual test, creating pull requests etc).

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

#22

Post by megous » Tue, May 07, 2019, 4:34 PM UTC

While some of that may be true, it feels ridiculous/inappropriate as a response. The customer doesn't want a disertation about programming/support practices. The customer wants something made cheaper.

That can be satisfied to a large degree. You can just as well tell the customer: "OK, I'll do the obvious chnage, if something else breaks, we'll fix it later. It seems likely all will be fine. Ok?"

Some customers will be ok with that. And you'll bill for 30mins or whatever and everyone's happy.

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

#23

Post by SketchySeaBeast » Tue, May 07, 2019, 4:35 PM UTC

projektfu wrote: post #18

stronglikedan wrote: post #14

Earlier quoted context omitted.

I don't think four hours is unreasonable for any type of shop (with 4-8 being CYA estimating). One or more resources likely have to do most of the steps below. * Document the customer request * Investigate the customer request * Create and document the requirement * Assign the task * Switch current context * Deploy a dev environment * Make the change * Submit the change to QC * Test the change * Deploy the change * C…

Totally agree it's a reasonable time. I think that it's a waste of time to argue why it takes time to do your work. You'd only write that letter because you feel bad about charging your client for your time. A better letter if you wanted to write one would be about the benefits you provide and the completeness of your work. I wouldn't even mention the time it takes.

If you're charging T&M money, and the client comes back with "why does it cost that much?", what would you suggest? Assuming burning the bridge isn't an option.

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

#24

Post by raiflip » Tue, May 07, 2019, 4:36 PM UTC

It seems like most of the comments here either didn't read or missed the point of the article. Yes, this is a simple change. Yes, pushing a fix out in a day is actually pretty fast. But the author using a simple example to illustrate a point. Better than taking a complex example that takes 5 paragraphs to explain. Moreover you can easily extrapolate all the parameters in the article for complex examples.

The primary point of the article is that there are very common inefficiencies in our industry that, if we tackled responsibly, would greatly reduce the turn around time of producing changes to the code base.

The point I took away the most from is how much having a single point of change for a single concept and periodically cleaning the code base to keep it this way can dramatically increase productivity.

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

#25

Post by ravenstine » Tue, May 07, 2019, 4:37 PM UTC

commandlinefan wrote: post #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…

I blame HTML and things like Dreamweaver, Flash, and MS Word in making a whole generation of non-technical folks believe that software development is trivial text-editing and drag/dropping. If "my nephew in high school makes webpages|games|apps" then it can't be all that hard to do, right? Better hire some code monkeys so I can kick back and relax. Hey, why is my assembly line so slow? Yah, mules!

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

#26

Post by ghostly_s » Tue, May 07, 2019, 4:39 PM UTC

raiflip wrote: post #24

It seems like most of the comments here either didn't read or missed the point of the article. Yes, this is a simple change. Yes, pushing a fix out in a day is actually pretty fast. But the author using a simple example to illustrate a point. Better than taking a complex example that takes 5 paragraphs to explain. Moreover you can easily extrapolate all the parameters in the article for complex examples. The primary…

I read the whole thing, and if the author was trying to use this as a simple example to illustrator a more general point, they did not communicate that effectively.

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

#27

Post by shaftway » Tue, May 07, 2019, 4:40 PM UTC

delinka wrote: post #19

commandlinefan wrote: post #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…

You're missing a critical part of the equation: the inexperienced software engineer. Inexperienced software engineers are less expensive, so you can hire more for your payroll budget. These juniors tend to think "yeah, that sounds pretty straightforward. I can do that in a week." It actually takes two months. It takes experience to estimate even nearly correctly. And MBAs love to buy some less expensive, less experie…

Or even worse, they actually do knock it out way faster than expected, but it's buggy and unmaintainable.

I was that inexperienced software engineer once. At the time a grizzled veteran tried to drop a knowledge bomb on me and said "A good programmer can write about 14 lines of code per day". It took me a really long time to figure out that he had mis-quoted something. It should have been "A good programmer only writes about 14 lines of code a day, they're just the right 14 lines."

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

#28

Post by chris11 » Tue, May 07, 2019, 4:41 PM UTC

megous wrote: post #22

While some of that may be true, it feels ridiculous/inappropriate as a response. The customer doesn't want a disertation about programming/support practices. The customer wants something made cheaper. That can be satisfied to a large degree. You can just as well tell the customer: "OK, I'll do the obvious chnage, if something else breaks, we'll fix it later. It seems likely all will be fine. Ok?" Some customers will…

> Some customers will be ok with that.

I'm not sure I would fully trust that. The client probably won't be happy if bugs from poorly tested code keep coming up. And it sounds like the client might question the dev teams work, if they are currently questioning the team's estimates.

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

#29

Post by plausibilities » Tue, May 07, 2019, 4:43 PM UTC

bfdm wrote: post #15

commandlinefan wrote: post #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…

There is a small subset of devs that will rush and get the work "done" in the underallocated time. The catch is in, of course, the Definition of Done. This is why we spend time aligning teams on exactly this. Sure I can fire off that one line change and tell you it's done. But, does it work? Is it right? Do you care? Typically this sub-par work is done by inexpensive outsourced development shops being managed by a cl…

Handyman Contractor mentality vs Civil Engineer mentality in a nutshell

Unfortunately not everyone cares about resilience and certain performance thresholds when it comes to construction, especially when budgets become involved.

Some customers will are happy to cheap out for a hack-job remodel in the hopes that they can flip their home and run off before the bagholder realizes they got a lemon.

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

#30

Post by heartbreak » Tue, May 07, 2019, 4:43 PM UTC

toddsiegel wrote: post #11

I do not think that is a good email for discussing a single, small feature. No client is going to want to read it. It's too long and detailed (1855 words!) and will probably only _increase_ their frustration. It is a good idea to discuss with stakeholders, at a high level, why things _seem_ to take long, but I find that works best as a conversation. No one wants a tome like this in their inbox.

I really doubt this is an actual email sent to a client. Obviously it’s too long.