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

111–120 of 285 posts

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

#111

Post by kl4m »

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.

Another viewpoint: https://john-millikin.com/sre-school/no-haunted-forests

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

#112

Post by Townley »

My favorite idea here is how it's a developer's job to articulate the issues with a client's code base to the clients themselves. Some clients just want the problem to go away, but smart ones recognize the importance of a high-level understanding of the state of their code base.

If you work for a cheapskate who's just nickel and diming about billable hours, the "Why does this take so long" question is nothing more than the rhetorical whining of a bad client. But in a healthy client-developer relationship, the question is important. It's a less-articulated, unfamiliar version of the following, which any good developer would find amiable:

"I, as someone invested in the success of my company, am seeking insight into a part of that success that only you have. I trust that you're not playing Minesweeper on our dime, and yet our current process isn't delivering the returns we expect. As someone who knows better than I do, are my expectations unreasonable and in need of adjustment, or are there investments that can be made to get us there?

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

#113

Post by hinkley »

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…

I bet those MBAs get mad at their mechanic and the guy rebuilding their kitchen every time they go 'over budget' too. The thing is they don't have much power over those people, but they do over us unless we are working as consultants.

Some of us wish there were safety codes for software like there are for plumbing and electrical. A lot of arguments reduce to "because what you're asking is illegal".

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

#114

Post by ww520 »

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…

Well the business side wants to squeeze down the cost at any chance they got. I had a client who would say something like "it's a simple change" every single time he made a feature request, no matter how big the change was. And it's been years he's been saying the same thing. It used to rile me up to go into detail on why it would take weeks to get some huge feature done. Now I just double whatever time estimate with him.

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

#115

Post by elemeno »

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…

But in a case like yours if sounds like steps 2 through 5 aren't strictly relevant to the change you're making, so it's no wonder that your estimate is blown out the water. (Sorry if I'm wrong, you've obviously got more context on your own platform than I do!)

It does make me wonder though if there is a trend of 'hiding' necessary maintenance work in larger tasks - if so that seems to me to be indicative of a larger problem around not being given/making the time to do those jobs as their own tasks.

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

#116

Post by Balgair »

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…

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.

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

#117

Post by hinkley »

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…

You need to get an agreement with the team that you're going to amortize future upgrade treadmill activities across all work that is done. You can't mortgage future productivity to get short term gains when your project is supposed to run for 5, 10, or 20 years. You'll spend most of your time working slowly if you work that way.

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

#118

Post by jimrhods23 »

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.

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

As I've gotten more experience as a developer, I've realized that most tasks take longer than I used to estimate..usually because I want to come up with a long-term solution and not just hack something together with no testing.

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

#119

Post by sound1 »

titanomachy wrote: post #12
SketchySeaBeast wrote: post #4

Earlier quoted context omitted.

So would you bundle up a series of these into a day? Or just assume the client is cool with this taking a day? I believe you're also assuming you're servicing a client whose got a lot of budget to blow on a lot of small changes.

Servicing a client with a very tight budget is a colossal pain. It might be inevitable early in your career but try to get past it as soon as you can. If your client has more time than money they will waste a lot of your time quibbling over price. The best clients have more money than time and will pay you well to make their problems disappear. They pay you to think about the software for them, so they can spend thei…

Great comment!

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

#120

Post by hinkley »

elemeno wrote: post #115
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…

But in a case like yours if sounds like steps 2 through 5 aren't strictly relevant to the change you're making, so it's no wonder that your estimate is blown out the water. (Sorry if I'm wrong, you've obviously got more context on your own platform than I do!) It does make me wonder though if there is a trend of 'hiding' necessary maintenance work in larger tasks - if so that seems to me to be indicative of a larger…

Yes, there is. Probably the best four projects I worked on, there was collusion to spread out the cost of necessary maintenance across all work items. Because nobody will agree to doing maintenance stories (this is how Scrum hijacks developer ethics). Never ask permission to do something that must be done.

Or to look at it another way, if no stories are maintenance stories, then all stories are maintenance stories.

Post reply on HN