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

191–200 of 285 posts

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

#191

Post by Qwertystop »

jmilloy wrote: post #50
bobm_kite9 wrote: post #48

Our internal model of the world is always simpler than the world itself (otherwise it wouldn't be a model). This whole article is just saying "Dear client, here's why your model is insufficient". Which is a much nicer email to write than "Dear client, here's why my model was insufficient". Which is what happens when the estimates go south

I'd almost argue that, in the example, the clients model wasn't insufficient. If you want to include "implement automated testing" in a small feature request without telling your clien, then your client is probably right to be surprised!

Perhaps I misread it, but I think the only testing being included was for the specific change. The bit at the end was "if we had the time to do a lot of general refactoring and testing not tied to the particular feature being done right now it would save time in the future".

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

#192

Post by snovv_crash »

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

Three months ago I found myself in yet another discussion with a PM about time estimation. I gave him an analogy I use for non-developers, where you try to estimate how long it will take to pack a kitchen into boxes for moving, the catch, I said, is that there's a significant chance each time you open one of the cupboards or drawers there might be a whole other kitchen or even house behind it. He responded with, "wel…

I like to use civil engineering analogies too. This cupboard one is great, I'll have to remember it.

Like for people who want a 50% demo at a 50% timepoint, asking if they'd ask to drive a truck halfway across a bridge when it was half completed. I mean, you could build a bridge that way, but it would be way easier to lay all the foundations first, then build support structures, then finally pave it at the end.

Another one is when someone asks to tack on a feature on top of some system that really can't support it, comparing it to asking to build a second story on a tent. They wanted the cheapest, quickest to set up, lightest on resources system, and that required certain tradeoffs. To build their new feature, it would often be easier, quicker and safer to rewrite the whole thing from scratch.

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

#193

Post by kjs3 »

dsfyu404ed wrote: post #49
plausibilities wrote: post #29

Earlier quoted context omitted.

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.

The handyman spends 20min thinking about how to solve the problem. The civil engineer spends 20min thinking about how to solve the problem and 20-days making sure there's no way whoever signs his paycheck is going to be told by a court to pay out a bunch of money if something goes sideways. An professional engineer is basically just a lawyer for the laws of physics. You're not paying for his ability to come up with a…

You can not 'read a book' and assess the structural strength of a skyscraper, or a dam across more than a creek, or any number of other things we only trust PE qualified CEs. I hear people claim otherwise, almost exclusively from more or less generally unqualified people who want to diminish the accomplishments of others and claim qualifications don't matter.

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

#194

Post by dkarl »

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…

What's wrong about this is that from the client point of view, Definition of Done ends up depending on who they're talking to more than their situation.

Hence the sibling comment of "Handyman Contractor mentality vs Civil Engineer mentality." It becomes a question of identity rather than a question of what the situation demands.

I'm not sure how to fix this, but I don't think the problem is as bad in practice as it is in discourse. I don't think people who see themselves on the "Civil Engineer" end of things would do the equivalent of providing CAD drawings and structural analysis for someone who asks them to replace their mailbox. On the other hand, it's still a problem if they talk as if they would.

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

#195

Post by novaleaf »

Techonomicon wrote: post #183
novaleaf wrote: post #170

Earlier quoted context omitted.

yours and a lot of other comments seem to hint that this work may not be strictly required? I'm a bit surprised. At least in my case, as a public facing SaaS I don't think running Node 6.x past it's LTS window is a valid choice, so better to bite the bullet now. If I went about doing the minimum work, it just adds more code/complexity that needs to be refactored when upgrading Node.

People are hinting that it is not strictly required to get what was initially desired done. And that seems 100% true. You do not have to do everything at one time. You can easily to one thing, and then right after that, literally right after, do another. You could have gotten the proxy up and going, and then upgraded node. It's not about "doing the minimum work" it's about understanding the problem space, what can be…

okay thanks for the tips, you and everyone else :)

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

#196

Post by SkyBelow »

Qwertystop wrote: post #185
SkyBelow wrote: post #87

Earlier quoted context omitted.

>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.

I think this is a parse issue -- is this > I asked them about [the non-functional requirements for this project] and they had to ask [please give me details on those requirements] or is it > I asked them about [non-functional requirements as a general concept] and they had to ask [what are these new things you speak of, I have never heard of such a thing] ? The former is reasonable, the latter less so.

For me, it was more "These things you call NFRs, I do not understand the purpose of them, especially given how they are decided."

Requirements like "The system must be secure.", "The system must not go down.", or "The system must not have performance issues."

I'm lost as to what the purpose of such statements are as they don't let me know where real focus needs to be given. Not every system is mission critical and deserves equal resources devoted to ensure uptime.

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

#197

Post by zknz »

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

It's a failure of education. This is one reason why everyone should have a basic understanding of code: not so they can all become programmers, but so they can get a mental handle on these systems and the people who do program them. It's the auto-mechanic problem; if you don't understand the thing yourself, you have no way to know whether or not you're being taken advantage of. So you tend to just split the differenc…

Why is 'code' different to any other skilled profession - Medicine, Plumbing, Quantity surveying, Piano tuning, Speech Therapy -

Why is it essential that 'everyone' knows about code -why draw the distinction?

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

#198

Post by chris_wot »

Symbiote wrote: post #187
novaleaf wrote: post #170

Earlier quoted context omitted.

yours and a lot of other comments seem to hint that this work may not be strictly required? I'm a bit surprised. At least in my case, as a public facing SaaS I don't think running Node 6.x past it's LTS window is a valid choice, so better to bite the bullet now. If I went about doing the minimum work, it just adds more code/complexity that needs to be refactored when upgrading Node.

You either need to upgrade from Node 6 or you don't. That's nothing to do with adding a new feature, and should be planned accordingly. It's unfortunately very common for developers to hide maintenance tasks in other work, but clearly not ideal.

I agree. However, to be devil's advocate - quite a lot of developer teams aren't allowed to migrate to new systems until way too late, so it's not surprising they do it in unrelated feature requests/bug fixes.

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

#199

Post by zoomablemind »

droithomme wrote: post #34

When the customer demands a written explanation of exactly why a small change took 4 hours, an engineer has to investigate that completely and write up an analysis in language and sufficient detail for the customer to understand. The given letter would take me a couple hours to revise and get the wording just right and diplomatic. Since the customer is challenging the billing and there is the subtext of fraud, the le…

Exactly! When requests like this start popping in, it signals some ongoing distrust or latent disagreement between devs and the client.

If I were that client, a response of that kind would rather infuriate me as mudding the "clear" picture I see.

I believe, in this case, there's a bigger issue to address - the issue of trust and responsibilities. If client's expectations about how things should be done overpower his understanding of what the devs do, then projects/contract assessments probably missed the target audience. To realign such expectations the team needs more than just a bark back email.

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

#200

Post by DougWebb »

SkyBelow wrote: post #196
Qwertystop wrote: post #185

Earlier quoted context omitted.

I think this is a parse issue -- is this > I asked them about [the non-functional requirements for this project] and they had to ask [please give me details on those requirements] or is it > I asked them about [non-functional requirements as a general concept] and they had to ask [what are these new things you speak of, I have never heard of such a thing] ? The former is reasonable, the latter less so.

For me, it was more "These things you call NFRs, I do not understand the purpose of them, especially given how they are decided." Requirements like "The system must be secure.", "The system must not go down.", or "The system must not have performance issues." I'm lost as to what the purpose of such statements are as they don't let me know where real focus needs to be given. Not every system is mission critical and de…

As developers, the most useless bug reports we get are "It's broken". The NFRs you describe sound like "The system must not be broken", which probably makes a lot of sense to someone who's likely to submit a useless bug report.
Post reply on HN