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

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

#211

Post by irq11 » Tue, May 07, 2019, 8:56 PM UTC

zoomablemind wrote: post #206

irq11 wrote: post #80

Earlier quoted context omitted.

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

”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 are not. Some of it does boil down to trust (i.e. bad history with previous managers), but a lot of it is just that they don’t want to do the thing because it’s less fun than other things, and nobody has ever held them to account in the past. A sufficiently lazy developer will find endless Legitimate Technical Justifications for not doing something he doesn’t want to do.

I’m not trying to generalize to all developers here, but I do know the people and problem I’m working with.

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

#212

Post by pjmlp » Tue, May 07, 2019, 9:00 PM UTC

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…

The purpose of those statements are to uphold contracts and compensation clauses when things go wrong and end up in court due to refuse of payment for delivering broken software (which might be debatable if that was indeed the case).

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

#213

Post by adanto6840 » Tue, May 07, 2019, 9:02 PM UTC

dllthomas wrote: post #88

adanto6840 wrote: post #54

Earlier quoted context omitted.

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.

This is a very good point and it's probably far more common than it is given credit for.

Sometimes you manage to catch some of these early on, but often they aren't caught until later in the process -- at which point the cost for the change (and the impact on budget/timeline, and potentially even the very architecture you set out to fix!) is drastically higher.

I've seen it happen a number of times where the 'spec' seemed simple enough at commencement & throughout most of the project; then you'd have each department test & the reports would start coming in... and the result would inevitably be a multiplier on the project scope.

Not from missing features mind you, but via the omission of 'complexity handling' / business logic which was documented -- but the code itself was the documentation, which isn't overly unusual (and IMO isn't even a particularly bad thing in many cases, though not all).

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

#214

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

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…

The problem here is the PM does not see himself a part of the team, your team, but is on 'other' team that is driven by other gears. The estimates is just an input for his process flow.

What's missing is another stream of input that should externalize the constraints and barriers in the flow of both yours and his teams. Even then, as long as PM does not see himself part of your team, all this is in vain, you'd be speaking foreign languages no matter the analogies.

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

#215

Post by aeorgnoieang » Tue, May 07, 2019, 9:13 PM UTC

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.

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

#216

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

It's because most software devs are beta males who are unable to express and stand up for their viewpoints. So their concerns get lost.

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

#217

Post by watwut » Tue, May 07, 2019, 9:20 PM UTC

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…

Aggressive pushback usually ensures the other side will treat you as the enemy. Which sounds like what happened there - typical management hates developers and vice versa.

Ate they having bloted estimates or not shipping within estimates? Why there are such large features anyway? Why is manager not a ten member but instead someone who don't belong?

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

#218

Post by adanto6840 » Tue, May 07, 2019, 9:22 PM UTC

avgDev wrote: post #168

kolinko wrote: post #121

Earlier quoted context omitted.

Yes. By the way - „Working effectively with legacy code”. https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe... If you start from scratch you may bump into the same edge cases that the original writers bumped into, and end up with a code that is not much better than the original - even in the original is 2 years out of date. I’m sure there were cases when writing from scratch was a good call, but I don’t re…

I guess if I do rewrite, I shall write about it as I go. If I fail it will make for a good story.

I'd emphasize that failure on a project like this may not be what you'd traditionally have in mind when thinking 'that project failed', though it happens and it could be that bad in the absolute worst case.

The issue is primarily that of the reward versus cost -- especially the opportunity cost.

When the system is rewritten, will the business have increased revenue or decreased cost? Will it do so significantly, surpassing at least the cost to rewrite (salaries, etc) -- that's the absolute minimum bar, but then you have to consider the opportunity cost which is the real concern:

If you had instead spent the same amount time adding new features, implementing an A/B test suite to increase conversions, improving marketing capabilities, retention mailers, or really any other activity that could positively impact the company business metrics -- would the impact be better than the impact of the rewrite?

In most cases the customers (internal or external) don't really know or care how good/bad the underlying code is, as long as the product serves their needs. When that's true, even partially, the value of 'rewrite' almost never exceeds the opportunity cost alone, let alone the absolute cost (and that's to say nothing of the risks).

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

#219

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

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 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 going back and doing it again until you’re sure it’s correct.

Why do we, as an industry, expect to be able to run a project to schedule when we often give it the most cursory of glances in the planning stage? I work for a very large integrator and we don’t plan at all. We jump in and start while we’re ‘planning’. It’s absurd.

He and I have long said that if the people who built [hospitals|bridges|aeroplanes] behaved the way we did, the world would look very different [1]. Now, thanks to my recent PMP-by-proxy, I’m starting to understand.

[0]: Project Management Professional. One of the main accreditations for project managers, I think PRINCE2 is the other one.

[1]: I’ve seen the project schedule for a railway line extension. “You really plan a concrete truck coming three weeks from now down to the half-hour?”, I asked my friend. She does.

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

#220

Post by watwut » Tue, May 07, 2019, 9:24 PM UTC

irq11 wrote: post #211

zoomablemind wrote: post #206

Earlier quoted context omitted.

>"...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 clos…

”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 factor?

I am asking because the one manager that complained about paddings was the one that took pride in manipulating people into weekends - including by claiming they promised it. I do tight estimates when I know I can be late and generous when I assume it will be law or don't trust management.