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

201–210 of 285 posts

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

#201

Post by gilbetron »

cutenewt wrote: post #153
gilbetron wrote: post #125

Earlier quoted context omitted.

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've always wondered why we don't provide estimates with a low, median, high scenario. It'd create a lot less disappointment and more accuracy.

Beta distribution is a bit better, which is basically what you are talking about:

https://www.isixsigma.com/methodology/project-management/bet...

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

#202

Post by _bxg1 »

zknz wrote: post #197
_bxg1 wrote: post #33

Earlier quoted context omitted.

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?

Because like writing and basic arithmetic, it's relevant to some degree in the majority of other fields. Code is used in medicine, quantity surveying, manufacturing, film, oil drilling. It's a field that cross-cuts fields, and decision-makers who don't have a basic understanding of it are going to make worse decisions no matter what their organization's primary focus is.

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

#203

Post by gubbrora »

shaftway wrote: post #27
delinka wrote: post #19

Earlier quoted context omitted.

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 writ…

This is highly codebase dependant ime. The less you have to read and think about wtf is going on the more you can write.

And generally the stronger coupling the more you have to read.

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

#204

Post by notatoad »

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…

>But I also see the other side. Why DOES it take 8 hours to do a simple one-line code change? That's ridiculous.

you might be right, but if you're not in a position to help make it take less time, that's not a helpful discussion to have. the reality is that it takes that long, and complaining doesn't make it faster.

The procedures that take time exist for a reason, and i'm sure in every organization there are opportunities to make the process faster. But when somebody who wants a change says "why does it take that long", they aren't looking for helpful ways to improve the process, they're looking for an exception to the process be made so their specific change gets out faster.

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

#206

Post by zoomablemind »

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…

>"...taking months to do a job that should take weeks, at most..."

Well,this is basically lack of trust between you and your devs. Or lack of common understanding of priorities. I'm not sure if you're a project mgr or a client, but clearly some expectations are misaligned. Perhaps you don't see their barriers or they don't agree with your priorities

The existing contract doesn't work, so some mediation is due to close that distrust before any damage is done. After all it's the team that you currently consider yours.

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

#207

Post by pjmlp »

dkarl wrote: post #194
bfdm wrote: post #15

Earlier quoted context omitted.

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 i…

We do.

That is why any proper RFP answer already provides a broad overview how the problem would be tackled, and possible solutions to the described problem.

Also why during the project development, at various delivery phases, artifacts like architecture diagrams, documentation and UAT from customer team take place.

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

#208

Post by munk-a »

rdiddly wrote: post #132
munk-a wrote: post #83

Earlier quoted context omitted.

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…

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 as a private company as it ensures there's plenty to reinvest and the cost the debt is imposing is well known.

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

#209

Post by cromulent »

Software development is magic to most people. You have the same laptop as them, and somehow you make stuff that works and makes them money by flexing your fingers.

They don't know how to internalize that - they are dealing with a magician that turns dirt into gold and gets paid by the hour.

It's totally irrational. If you were a plumber then there would be a physical manifestation of the work.

Software managers who have never written code are also often suspect, in my opinion. They can be professionals of magic management without understanding, liking, or even appreciating their field.

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

#210

Post by yebyen »

Balgair wrote: post #188
zbigniewc wrote: post #134

Earlier quoted context omitted.

Such approach assumes that literally all tasks are minefields full of unpredictability. But are they really? In my experience such reasoning and 'magnification' applies only to minority of cases, while most of the time you hopefully deal with well-enough understood domain and codebase to accurately estimate the effort based on the initial judgement.

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 management will ultimately decide that we need to do the project in half the time, and with these extra features you didn't ever plan on building.

My budgeting strategy is to always assume that for whatever scope you have planned, 50% of the complexity that you will need to deliver in order to reach the finish line, remains unknown at any given stage of planning. Compensate upward if there still remain known unknowns.

Post reply on HN