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

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

#241

Post by cgio » Tue, May 07, 2019, 10:29 PM UTC

yebyen wrote: post #210

Balgair wrote: post #188

Earlier quoted context omitted.

For me, it's more of a guestimating rule. Sure, some tasks take less than I'd expect them too. Sure, some take a LOT longer than even my guesstimate. But this helps me 'plan for drought and pray for rain', so to speak.

To clarify why this strategy is not as bad or egregious as it seems, one must only ask: what are the consequences of overestimated time for work (that gets delivered early?) And what are the consequences of underestimating work? Would you rather deliver a product with finished surfaces or cut corners? Proper design and good overall test coverage, or zero budget for maintenance? It also helps to understand that manage…

The consequence of overestimating is you don’t get the project. Occasionally that’s the consequence of proper estimation too, as people tend to underestimate when selling the project to get it through. Once I estimated a project at 3 months team of 5. They told me it should be 3 months team of 2. “We are doing sales mate” they told me. “You are, I am doing delivery” I responded, and then did neither sales nor delivery. ..

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

#242

Post by gmueckl » Tue, May 07, 2019, 10:31 PM UTC

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…

A lot of the most serious software engineering work that I have done had much the same ratio: coding the a solution that mostly works was easy. Making sure that it is robust against all kinds of failures (CPU, RAM, bus/external device failure, random bit flips etc.[0]) and does the right thing was a lot of work.

[0] The system I worked on was hardened against all of that and some more failure modes.

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

#243

Post by dllthomas » Tue, May 07, 2019, 10:58 PM UTC

ma2rten wrote: post #229

dllthomas wrote: post #154

Earlier quoted context omitted.

Even if it's not, decompilation might be useful. What I'd try is decompiling both the running version and the build of the available source code, and see if the diff is informative.

Last time I checked x86 decompilers were not that useful. They were producing code that is not compilable, often completely failing on more complex, translating code compiler boilerplate into code. This was a while ago so maybe things improved since then.

The goal here is some window into "what changed". For that, we don't need "compilable", and boilerplate won't be an issue provided it's stable (by no means guaranteed, to be sure).

If I had to bet at even odds, I'd bet against it being useful. But the win is potentially large and the effort isn't.

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

#244

Post by Retric » Tue, May 07, 2019, 11:17 PM UTC

hnlmorg wrote: post #237

Retric wrote: post #231

Earlier quoted context omitted.

Accurate time estimates need to be associated with specific individuals. Someone who is familiar with the relevant code is simply faster than someone who is not. Further, interruptions don’t just cost time, they also reduce productivity around them. Now, you can try and do effort estimates using hypothetical people. But, at that point you have already given up the possibility of an accurate answer.

> Accurate time estimates need to be associated with specific individuals. Someone who is familiar with the relevant code is simply faster than someone who is not. This is one of the many reasons why I disagree with giving projects to specific individuals. Not only do you end up silos of knowledge (which is a risk if that engineer should leave / get fired / die in a bus accident) but you also make it harder for yours…

I agree estimates are never going to be 100% accurate but that doesn't mean there aren't better ways to estimate than just applying guesswork based on your current teams circumstance.

The entire dev team walks out, and yes this actually happens surprisingly often and could happen to you’re team tomorrow. Now, what happens to all your estimates?

Well clearly anything short term is now worthless. You can build a new team and use older effort estimates as a guide, but with different skill sets and a massive learning curve they in no way translate into FTE hours.

Effort estimates can survive those kind of transitions. But, time outside of a functional team is not meaningful.

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

#245

Post by crikli » Tue, May 07, 2019, 11:31 PM UTC

Good lord, tl,dr. And I'm a dev. Client sure as hell wouldn't read all that. And I know this because at the start of my career I wrote those kind of long-winded explanations before I realized that nobody was reading them.

Brevity is a virtue.

"Dear client, the change itself took very little time but making sure that this change did not have unintended ripple effects took a lot more. We are careful and deliberate when deploying changes to your production application because in this mission critical application, downtime and errors are not acceptable. If you'd like more detail I can provide it during our next regularly scheduled catch-up."

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

#246

Post by yebyen » Tue, May 07, 2019, 11:35 PM UTC

cgio wrote: post #241

yebyen wrote: post #210

Earlier quoted context omitted.

To clarify why this strategy is not as bad or egregious as it seems, one must only ask: what are the consequences of overestimated time for work (that gets delivered early?) And what are the consequences of underestimating work? Would you rather deliver a product with finished surfaces or cut corners? Proper design and good overall test coverage, or zero budget for maintenance? It also helps to understand that manage…

The consequence of overestimating is you don’t get the project. Occasionally that’s the consequence of proper estimation too, as people tend to underestimate when selling the project to get it through. Once I estimated a project at 3 months team of 5. They told me it should be 3 months team of 2. “We are doing sales mate” they told me. “You are, I am doing delivery” I responded, and then did neither sales nor deliver…

Estimates for internal client is a different ballgame than estimates for sales, it would seem.

My approach to the same project would be different if I know that I get to walk away when the project is over, versus if I know I'll be the one to maintain the project when this phase is over and it goes into production. I work for internal clients lately, and I can't honestly say it's my way or the highway, but if you ask for an estimate, I'm going to give you an estimate.

If you tell me the deadline then we're having a different conversation entirely. (And that's OK! Deadlines are better than estimates in my book, especially if the consequence of missing the deadline is some unfinished garbage goes to production, or doesn't ship at all as we had to move on to the next thing. If you asked me for an estimate and told me "that's too much, do it in less" then you didn't really want an estimate, did you? Just tell me the deadline and I'll deal with it, in that case, let's not play games.)

Here's another approach: tell me how much time you want to spend on this project, then I'll put a pen to paper and tell you what part of the scope we can deliver given the resources you've allocated. Don't like that very much? OK, you write the plan and I'll say "yes sir." But that's not why you pay me, is it?

Estimates are a function of scope, time, and cost. If you tell me to do it in less time, I'll do it in less time, but it's going to come at the expense of one of either feature scope or quality. This is not a negotiating tactic, it's just a statement of fact. If you tell me I have to shave off a bunch of time without sacrificing anything, then we're not having an honest conversation and we're not going to have a good time. I'm sorry you had a bad experience, mate.

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

#247

Post by munk-a » Tue, May 07, 2019, 11:59 PM UTC

aeorgnoieang wrote: post #215

munk-a wrote: post #59

This simple change and the recommended fix has another issue that this post missed or dismissed as a non-issue. What if the deadline is pushed back after the email reminder is sent? Do some users rely entirely on the email reminders and might they need a followup email saying "Just kidding, actually you've got more time" - assuming you resolve that question, when the due date comes up again should you send another em…

The post covered that, tho not the specific details you mention.

That's why I mentioned it, actually taking the time to see what a change can effect itself takes time, and if changes are pushed through in an hour then no one is stopping to think about what systems you might be breaking.

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

#248

Post by HillRat » Wed, May 08, 2019, 12:11 AM UTC

Buttons840 wrote: post #226

jen729w wrote: post #219

Earlier quoted context omitted.

My boss/friend just sat (passed) his PMP [0] exam and was talking to me about it as he learned. The main thing that I learned is that the amount of time they say you need to spend planning a thing is waaaaaaaaay longer than we’ve ever spent planning a thing. Orders of magnitude longer. And you plan it multiple times over, with rounds of stakeholder engagement, rounds of risk analysis, rounds of breaking it down and a…

> you need to spend planning a thing is waaaaaaaaay longer than we’ve ever spent planning a thing. Orders of magnitude longer. And you plan it multiple times over, with rounds of stakeholder engagement, rounds of risk analysis, rounds of breaking it down and analysing each component and figuring out what it is and how long it will take and what can go wrong and the dependencies and so on and so forth ... and then goi…

Agile doesn’t excuse you from having to do the work of resourcing, budgeting, business alignment, goal setting, sprint planning, acquisition, and so on. For bite-sized projects with just a few developers, it’s less of an issue, but for a project covering PMO, design, QA, change management, and multiple technical workstreams you have to have — and need to communicate to the business — at least a reasonable idea of what you’re getting into.

You ain’t wrong about how most businesses implement “agile,” though. :)

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

#249

Post by chiefalchemist » Wed, May 08, 2019, 12:49 AM UTC

> "In other words, spending 1/2 day to a full day (4-8hrs) on this task is roughly 2x-4x the effort..."

My personal rule of thumb is: It either takes 1 minute, 1 hour, 2 hours, 4 hours, or 8 hours. Or obviously longer, but for the back of the envelope type of things these tiers work.

There's no 3 hours or 5 hours. Nothing ever take 3 or 5 hours. Perhaps sometimes 6 but at that point - due to distractions and side fires - it's a full day. Call it 8 and stop kidding yourself.

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

#250

Post by chiefalchemist » Wed, May 08, 2019, 12:54 AM 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…

> " then maybe I could understand why they STILL think we’re lying."

They think that because occasional something that sounds (to them) as being the same simple request does take and hour or two. That's all they remember. That's all they want to remember.

Frankly, short of critical bug fixes, is there ever really a real biz need to deploy such updates almost immediately? Why not say, we expect to have to coded and tested in time for our next scheduled update" or something like that. This way they see the big picture and don't get to know - cause they don't really need to know - the nitty-gritty details.

I'm not against transparency. But the fact is, clients need to be managed, as do their expectations.