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

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

#231

Post by Retric » Tue, May 07, 2019, 9:39 PM UTC

hnlmorg wrote: post #223

Retric wrote: post #157

Earlier quoted context omitted.

That’s irreverent as each estimation is based on that team and it’s situation. If I am going to spend 20 hours a week stuck in meetings that’s going to impact my estimates.

It shouldn't do. Estimations should be based on FTE (full time equivalents) of the broken down tasks. An estimation shouldn't be guesswork of a delivery date based on your current teams situation but rather a calculated value of the number of days of effort (eg it would take 1 person 82 days if they worked on it for 7.5 hours a day) with a little margin added for any unforeseen technical hurdles that will inevitably…

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.

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

#232

Post by zoomablemind » Tue, May 07, 2019, 9:45 PM UTC

unreal37 wrote: post #110

I worked in software development within companies for 20+ years. The "why does it take so long" conversation has come up a lot. So on one hand, I see the argument. Simply opening unknown code, and making a change no matter how small, is a risky game. You need to research the impacts, test, and walk slowly through a deployment you haven'y done in ages. I totally get that. But I also see the other side. Why DOES it tak…

What's crucial here is that someone previously set the expectation of "one-line change"

Maybe a savvy client, maybe a happy dev. Most likely this situation happened not for the first time.

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

#233

Post by falcongod082 » Tue, May 07, 2019, 9:45 PM UTC

Balgair wrote: post #116

novaleaf wrote: post #101

Earlier quoted context omitted.

my own anicdata: Integrate a default proxy into our existing "choose proxy" workflow takes about 2 weeks, and I'm currently on my 3rd month of those 2 weeks :) Reasons for the delay: 1) Proxy is a stand-alone application. Needs it's own deployment and build configuration 2) Main app was running on Node 6.x. High time to upgrade to 10.x as 6.x LTS is running out. 3) Upgrade to 10.x breaks some modules we depend on (Go…

My own 'magnification' index is as such: Take whatever time I think it should take. Then double that number and go up one time unit. Exp: I think it should take me 3 hours this afternoon to do this -> 6 days. I think it should take me 2 days to to this -> 4 weeks. I think it should take me 1 week to do this -> 2 months. I think this should take us one month to accomplish -> 2 years.

This is brilliant.

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

#234

Post by vitro » Tue, May 07, 2019, 9:45 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…

So far analogy that worked for me is a house building one.

Something along the lines:

If you expect to build a cottage and it turns out to be actually a cathedral, that is the source of the extra time or rework.

Or, imagine you build a wall inside a house. But once the wall stands, suddenly you remember, that you wanted to have a window there. Or an electric socket. Imagine what extra work that will be.

It is more easy for clients to imagine that and they understand the necessity of planning and a why some changes, although they seem like a small ones, may actually take a lot of time.

I have the feeling that software is too abstract to reason about for non developers.

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

#235

Post by Drdrdrq » Tue, May 07, 2019, 9:52 PM UTC

avgDev wrote: post #167

ma2rten wrote: post #99

Earlier quoted context omitted.

If it's language that has byte-code like java or .net you might be able to decompile the production binary.

Good suggestion. I have decompiled the version in production. I will admit that reading it, is extremely frustrating as there are no objects and fields are named field1, field2, field3.

Still, you can compile + decompile the code you have, and compare that to decompiled production app. This might allow you to apply any cganges back to the code.

Btw, it's not a dev who lost the code, it's the company and inadequate development process. It should never have been the single dev's responsibility to make backups.

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

#236

Post by rdiddly » Tue, May 07, 2019, 10:01 PM UTC

munk-a wrote: post #208

rdiddly wrote: post #132

Earlier quoted context omitted.

Paying down technical debt should be exactly as easy/hard to justify, as paying down monetary debt. They behave the same and have the same effects over time; that's why debt is such a good analogy.

I disagree, technical debt is a much more liquid quantity that can be easily paid off in as little or great a chunk as you wish. If you as a company offered to let everyone pay off tech debt with 10% of their time, but force it to be 10% on a daily basis you'll likely end up accumulating more debt - paying off monetary debt a little at a time by diverting x% of revenue to it is a particularly good way to handle debt…

So tech debt is harder to subdivide arbitrarily, I'll buy that. And it's harder to quantify in the first place, which seems to be one of the theses of this "dear client" letter.

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

#237

Post by hnlmorg » Tue, May 07, 2019, 10:02 PM UTC

Retric wrote: post #231

hnlmorg wrote: post #223

Earlier quoted context omitted.

It shouldn't do. Estimations should be based on FTE (full time equivalents) of the broken down tasks. An estimation shouldn't be guesswork of a delivery date based on your current teams situation but rather a calculated value of the number of days of effort (eg it would take 1 person 82 days if they worked on it for 7.5 hours a day) with a little margin added for any unforeseen technical hurdles that will inevitably…

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 yourself to make estimates for the reasons you've described. Sure there will always be a variance from person to person but you stand a greater chance of that averaging out if you discourage engineers "owning" code bases.

> Further, interruptions don’t just cost time, they also reduce productivity around them.

You missed my point regarding meetings. I'm saying if you estimate a project based on FTEs (different methodologies and frameworks will have different terms but they usually amount to the same concept) then time spent in meetings becomes a modifier you can easily adjust for, rather than a hidden time sink that you can't account for.

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

You don't need to make the estimate on hypothetical people. You just need a system of tracking and reporting the hours people spend in a working day. For example in JIRA you can log time against a ticket and you can create generic tickets for meetings. Therefore after a week / sprint / arbitrary point in time you can view where your engineers have spent their time and if it's below the allocated time for that project you can then either:

- enforce a new policy (eg are all the engineers going to every meeting when just one or two representatives would suffice? Are some meetings just duplicates or redundant? etc),

- inform project managers that there will be a deadline slippage due to resource constraints

- hire more resource to compensate

- or all of the above

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.

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

#238

Post by jen729w » Tue, May 07, 2019, 10:08 PM 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…

So I just said that in order to get a project planned properly you need to spend way more time planning it, and you literally said "yuck", let's use agile instead. Which is ... not planning it properly.

And anyone wonders why we're in this situation? We dug this hole, kids. (And to be clear, I'm guilty. I'm not trying to be better than anyone. I am not! I'm just attempting to explain it.)

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

#239

Post by irq11 » Tue, May 07, 2019, 10:09 PM UTC

watwut wrote: post #220

irq11 wrote: post #211

Earlier quoted context omitted.

”Well,this is basically lack of trust between you and your devs” It’s pretty amusing how many definitive responses I’m getting from devs who are diagnosing my problem without any knowledge. It’s also telling how different they are. Like I said, there are reasons, and I’m aware of them. I’m also fully aware of the technical barriers. The devs are padding their schedule, and think they’re being clever about it. They ar…

Are you saying there is trust between you and developers? Cause you surely don't trust them and the way you describe their communication sounds like they don't trust you. Also, if they give you non-padded estimate, that is the one they will occasionally miss, will typical manager of your company force them to work weekends and evenings or otherwise punish them? Or will typical be ok with it and accept it as risk fact…

Rather than second-guessing a total stranger on the internet - concerning a situation about which you know nothing - you would do well to question why you insist on assuming that everyone is as bad as the worst manager you’ve had.

To answer your question: no. I don’t do any of that. Also, this situation has nothing to do with aggressive schedules.

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

#240

Post by laughfactory » Tue, May 07, 2019, 10:20 PM UTC

thanatropism wrote: post #95

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…

> . 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. Most of these look like MBA problems. That said, maybe more experienced coders should be doing MBAs (which isn't just about attending classes but about networking, acquiring a wide…

Ugh. MBAs? No thanks. Usually it's interactions with MBA-holding folks that gives me heartburn. They try to mechanize everything. I agree that an MBA education is probably fairly useful for developers, as long as you can retain your perspective and balance the two worlds--they are very different after all. I'm _very_ business-minded (though I don't have an MBA) and I still run into extensive frustration when I get these kind of queries from the business: why is this taking so long? As this article laid out well, the change or new feature is often conceptually simple but there can be _so_ much required to make conceptually simple things actually happen. Unless you have real development experience before becoming "management", I doubt it's possible for a developer to truly convey that complexity to you. Ultimately it ends up becoming a matter of trust, and frequently competent managers realize over time something along the lines of "well, if every developer I've ever had has taken a long time to deliver conceptually simple things then perhaps that means there's a lot to do to deliver things I think are simple." Sadly, there remain some managers who remain convinced, in the face of all evidence to the contary, that all developers are lazy, slow, and just need to be whipped more and harder.