Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

simplethread.com

Post reply on HN
Print view View original

81–90 of 285 posts

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

#81

Post by munk-a »

SketchySeaBeast wrote: post #23
projektfu wrote: post #18

Earlier quoted context omitted.

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.

Itemize the bill, break it down relentlessly into tiny components and show how long different facets tied to the feature build took, ideally pin some of the time on them if it's appropriate ("Remember when you guys were a bit wobbly on the background color, well we had quite a few meetings and dev was tied up while we were talking, it ended up taking us about three hours between those two hour meetings and then an additional thirty minutes to redo the change three times - thankfully we held off on testing until we'd all gotten on the same page.")

The more explanation you get out there the better, if you're honest (or a good faker) people will be reassured by your explanations - but accept that not all clients are profitable ventures, a customer who can't pay for the time it'll take isn't one you should take on, just try and leave things in an amiable state.

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

#82

Post by adrianmsmith »

Raphmedia wrote: post #35
ghostly_s wrote: post #6

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've worked in a web agency that billed by the hour. Clients would ask for justification on why something would take 5h of support instead of 2.5h because the previous similar request was done in half the time during the development of the app. What they don't understand[1] is that if they ask for an urgent fix after deployment, they're going to pay for a developer that had free time this very moment to pull and inst…

> Often, requests look very similar but are very different to each other. "Why does it takes 3 hours to add a button on the sidebar while it takes 1 hour to do it in the content of the FAQ page?"

There is a good XKCD on this topic: https://xkcd.com/1425/

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

#83

Post by munk-a »

unityByFreedom wrote: post #77
munk-a wrote: post #64

Earlier quoted context omitted.

Please don't excuse this, when management over promises and devs "under" deliver, then the axe never falls on management. The best work environments I've seen are where devs and management work together to supply estimates of a reasonable scale and where time is taken in project planning to chop up big goals into small tickets in a developer-meaningful manner.

Absolutely, it makes no sense for a manager to set timelines without conferring with devs. Devs should set timelines, and business people should set "how much benefit will this bring". The combination of these two things yields priority.

I agree, and the biggest difficulty that ends up coming out of this fact is that things like paying down tech debt are hard to justify from a business perspective, this is a legitimately hard problem that everyone who ends up in project planning will have to deal with. When you hit it try and rely on talks by experts in the fields and external resources to enlighten the business side as to the value that paying down tech debt will give you.

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

#84

Post by [deleted] »

Raphmedia wrote: post #35
ghostly_s wrote: post #6

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've worked in a web agency that billed by the hour. Clients would ask for justification on why something would take 5h of support instead of 2.5h because the previous similar request was done in half the time during the development of the app. What they don't understand[1] is that if they ask for an urgent fix after deployment, they're going to pay for a developer that had free time this very moment to pull and inst…

[deleted]

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

#85

Post by jmilloy »

jshowa3 wrote: post #67
jmilloy wrote: post #45

The idea is sound, but this letter is truly surprising to me. Instead of a succinct summary of what goes into the change, we get a long-winded narrative that reads to me as full of excuses. I think a more useful email would be a breakdown of the time actually spent, and a proposal for improvement, something closer to this (obviously sent after the feature has been deployed, and obviously including additional items fo…

Do you think a housing contractor is "making excuses" when they apply the rationale requesting to take down a wall in the house by saying: 1) we need to investigate the condition 2) check if its load bearing 3) check if it runs electrical or plumbing 4) check if it is to code No, they're telling you the rationale of what goes into making a change. I agree that this isn't something you should send to clients. But, eve…

Really, I don't think that the developer is "making excuses" here. Which makes it all the more unfortunate that the letter as written sounds like excuses.

> The next question will be, "Why does it take 4.5 hours to manually test?"

I'm not sure it will. In my experience, clients are usually surprised about how long something takes not because they think specific tasks are taking too long, but because they aren't really aware of what the tasks are nor of their tradeoffs.

"You're right, it took longer than expected. I chose to spent some time setting up automated tests. That took extra time now, but will save much more time later."

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

#86

Post by avgDev »

drewolbrich wrote: post #70
avgDev wrote: post #41

Earlier quoted context omitted.

Spot on. I was 1st SE at the company I am at now. Previous applications were developed by outside contractors. I tried making some changes to that code base and found massive issues. Source code was older than the compiled application. Massive methods that were 1k+ lines long. Business rules all over the place in IF statements. Barely any documentation/comments. Only way forward is complete rewrite. I'm a relatively…

Even though the code you are interacting with appears awful, you may want to reconsider the rewrite strategy. This post may be helpful: https://www.joelonsoftware.com/2000/04/06/things-you-should-... Consider rewriting only a handful of small parts that are causing problems critical to the success of the product, and making small improvements to the rest of it as needed over time.

This is impossible in my case, the source code is outdated. We do not have the source code of the project, which we run in production. The dev lost it.

I have tried working with the source code but it has many bugs and it appears to be two years out of date. This leaves us with an application only in its current state with no way of making any changes.

I may be able to extract pieces of information, reuse some stored procedures and so on.

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

#87

Post by SkyBelow »

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

This isn't all on the non-developers. I've walked into two rooms this week, which contained several senior developers, and when I asked them about non-functional requirements, they had to ask what they were, and why they were important. I've also seen teams where the Defintion of Done doesn't include any steps at all towards deployment. Done is when someone approves the pull request. Not surprisingly, it takes longer…

>when I asked them about non-functional requirements, they had to ask what they were, and why they were important.

Based on my own experience with NFRs, these are perfectly reasonable questions.

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

#88

Post by dllthomas »

adanto6840 wrote: post #54
avgDev wrote: post #41

Earlier quoted context omitted.

Spot on. I was 1st SE at the company I am at now. Previous applications were developed by outside contractors. I tried making some changes to that code base and found massive issues. Source code was older than the compiled application. Massive methods that were 1k+ lines long. Business rules all over the place in IF statements. Barely any documentation/comments. Only way forward is complete rewrite. I'm a relatively…

I've been a stakeholder in many a "rewrite is the only way forward" projects, though I have almost never actually advocated/voted for a "from-scratch" rewrite. I obviously say this having none of your domain-specific context -- so grain of salt -- but, in my experience, a total 'scratch' rewrite is rarely the right answer. Furthermore, it's often nearly impossible to even be able to ascertain the 'right answer' until…

Also keep in mind that often the existing application is the only real artifact you have capturing all of the complexity and corner cases your rewrite will have to deal with.

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

#89

Post by throwaway55554 »

irq11 wrote: post #80
noego wrote: post #40

Earlier quoted context omitted.

On the flip side, I've seen far too many teams move at the speed of molasses, for reasons unrelated to the intrinsic complexity of the problem. Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc. I wouldn't be so quick to assume that ev…

I’m dealing with this right now. A team that is downright arrogant about reducing their well-padded schedule, taking months to do a job that should take weeks, at most. Getting them to do anything is like pulling teeth, and accompanied with lots of arrogant lectures about how hard it is to estimate, how you can’t rush quality, and so on. It’s mostly bullshit. This team has historical reasons for their bloated schedul…

Sounds like a hiring problem. Start hiring some new devs and keep them separate so as to not contaminate them. As they come up to speed, let one of the other devs go. Wash, rinse and repeat.

Note: I'm a dev and I can tell you I very much dislike working with prima donnas.

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

#90

Post by Retra »

irq11 wrote: post #80
noego wrote: post #40

Earlier quoted context omitted.

On the flip side, I've seen far too many teams move at the speed of molasses, for reasons unrelated to the intrinsic complexity of the problem. Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc. I wouldn't be so quick to assume that ev…

I’m dealing with this right now. A team that is downright arrogant about reducing their well-padded schedule, taking months to do a job that should take weeks, at most. Getting them to do anything is like pulling teeth, and accompanied with lots of arrogant lectures about how hard it is to estimate, how you can’t rush quality, and so on. It’s mostly bullshit. This team has historical reasons for their bloated schedul…

Perhaps shipping simply produces more value for you than it does for them?
Post reply on HN