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

131–140 of 285 posts

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

#131

Post by stickfigure »

novaleaf wrote: post #101
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…

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…

While all platforms have some measure of this phenomenon, the update treadmill problem does seem to be especially acute in the javascript ecosystem.

I update Java dependencies maybe once a year; it's usually painless and incompatibilities are highlighted by the type system. If you let your JS dependences get stale by a few months, you're looking at hours or days of work. And that doesn't count the massive shifts in build systems and frameworks that seem to happen annually.

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

#132

Post by rdiddly »

munk-a wrote: post #83
unityByFreedom wrote: post #77

Earlier quoted context omitted.

Absolutely, it makes no sense for a manager to set timelines without conferring with devs. Devs should set timelines, and business people should set "how much benefit will this bring". The combination of these two things yields priority.

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.

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

#133

Post by hinkley »

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…

There was some CivE professor that people liked to quote who talked about how he had no qualms flunking people from his classes because a degree in Civil Engineering was a license to kill.

If you let dumbasses through the system, they will build a pedestrian bridge in a hotel lobby that fails and kills a hundred people at a party.

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

#134

Post by zbigniewc »

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.

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.

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

#135

Post by hinkley »

maccard wrote: post #107
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…

On the contrary, there are plenty of devs who won't take on any work until it's been designed, scoped, run through management, prioritised and scheduled, when the actual fix is a one line change that would have taken less effort than the meeting where it was prioritised. There's a happy middle ground between the two, and assuming developers who will deliver quick fixes are all hacks who don't care is counterproductiv…

Those people got burned by managers who like to think that all of their problems are one line fixes that can be rushed out.

They think that 'simple' from the user's perspective is 'simple' from an engineering sense and usually those are inversely correlated.

Essentially that engineer has grounded the management team. They can't be trusted to behave so their toys have been taken away.

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

#136

Post by unityByFreedom »

munk-a wrote: post #83
unityByFreedom wrote: post #77

Earlier quoted context omitted.

Absolutely, it makes no sense for a manager to set timelines without conferring with devs. Devs should set timelines, and business people should set "how much benefit will this bring". The combination of these two things yields priority.

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…

Tech debt is manageable if you start out with the right culture.

If you start out with an environment where devs feel rushed, you will run up tech debt very quickly, and it will be harder to get on the same page later when dev slows to a crawl

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

#137

Post by rdiddly »

dfjhdkjfhsdkf wrote: post #42
dsp1234 wrote: post #31

Earlier quoted context omitted.

This isn't all on the non-developers. I've walked into two rooms this week, which contained several senior developers, and when I asked them about non-functional requirements, they had to ask what they were, and why they were important. I've also seen teams where the Defintion of Done doesn't include any steps at all towards deployment. Done is when someone approves the pull request. Not surprisingly, it takes longer…

I agree with your comment about senior devs. it seems as devs climb the ladder many get a superiority complex where they could do things quickly and others cannot. I was once a tech lead of a team where the architect had been berating and criticizing a team member for weeks over something he thought should take a day. I suggested he should take over and complete it. It took him weeks to complete.

the architect had been berating and criticizing a team member for weeks

If berate is truly the appropriate word (upon investigation), and I had any say in the matter, I would fire his toxic ass immediately.

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

#139

Post by hinkley »

drewolbrich wrote: post #70
avgDev wrote: post #41

Earlier quoted context omitted.

Spot on. I was 1st SE at the company I am at now. Previous applications were developed by outside contractors. I tried making some changes to that code base and found massive issues. Source code was older than the compiled application. Massive methods that were 1k+ lines long. Business rules all over the place in IF statements. Barely any documentation/comments. Only way forward is complete rewrite. I'm a relatively…

Even though the code you are interacting with appears awful, you may want to reconsider the rewrite strategy. This post may be helpful: https://www.joelonsoftware.com/2000/04/06/things-you-should-... Consider rewriting only a handful of small parts that are causing problems critical to the success of the product, and making small improvements to the rest of it as needed over time.

At the end of the day, GP is claiming zero confidence on being able to maintain this piece of code. It's come out of their mouth as "I want to rewrite this" but what it means is "I think it would be less painful to rewrite in a way I can support than to bumble around like an idiot for 3 years in this one."

There are a lot of things you can do with that input but you really have to acknowledge that there's a pretty big problem here, and some empathy is going to be part of our path out of this mess.

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

#140

Post by commandlinefan »

maccard wrote: post #107
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…

On the contrary, there are plenty of devs who won't take on any work until it's been designed, scoped, run through management, prioritised and scheduled, when the actual fix is a one line change that would have taken less effort than the meeting where it was prioritised. There's a happy middle ground between the two, and assuming developers who will deliver quick fixes are all hacks who don't care is counterproductiv…

> There's a happy middle ground

Yeah, the happy middle ground is a management infrastructure that doesn't insist that you say exactly how long everything is going to take before you start doing it and accept that there ARE unknowns in software development.

Post reply on HN