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

161–170 of 285 posts

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

#161

Post by williamdclt »

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.

I don't think that people are good at that. I've been asked before to give a low and a high scenario, but all I can really do is to tell you how long I think it would take (I did a +/- 50% of the estimation, and explained what I did).

Sometimes there's a specific uncertainty that changes radically the estimation. But remove this uncertainty and we're back at estimating and doing +/- 50%.

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

#162

Post by megablast »

throwaway55554 wrote: post #89
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…

Sounds like a hiring problem. Start hiring some new devs and keep them separate so as to not contaminate them. As they come up to speed, let one of the other devs go. Wash, rinse and repeat. Note: I'm a dev and I can tell you I very much dislike working with prima donnas.

Oh yes, keep them separate from the people who know the application, how it works, what it integrated with, all the codes, all the issues. Brilliant!

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

#163

Post by a-afterglow »

paganel wrote: post #55
jrockway wrote: post #7

Earlier quoted context omitted.

I am guessing they want to pay $50 for 10 minutes of work instead of $2400 for 8 hours of work.

You’re most likely correct and it’s a thing that has bugged me on and off ever since I started realizing that some of us, programmers, are not very well suited to linear working (for a lack of better word) like for examples accountants or lawyers. Sometimes you spend an entire day on trying to fix an issue/bug with no luck, until the following day when all of a sudden a brilliant idea comes to you and you solve every…

Sometimes it's not a brilliant idea but actually something you just kept overlooking....

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

#164

Post by megablast »

commandlinefan wrote: post #98
bluGill wrote: post #91

Earlier quoted context omitted.

In my experience it takes months of looking at existing code before you see the good architecture under the superficial mess. In other words, work in the current code for at least a year before proposing a re-write. Source code older the the application doesn't mean much as a statement - any good process will build off a CI system which only takes old source code. The question is how different is the application the…

> it takes months of looking at existing code All the while listening to management say, “this should be a one line change, why should it take more than a few hours?”

> this should be a one line change

Oh great, you do it then.

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

#165

Post by megablast »

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…

Ha, hilarious. I have had changed that were done as soon as they were mentioned, but still required several more meetings to ensure everyone was aware of the upcoming change, had signed of on it (even though it was a severe bug), and discussed it ad-infinitum. Including how to do it, even though I already did it at the start of the meeting. Approximately 100x the time it took to do the work.

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

#166

Post by megablast »

avgDev wrote: post #41
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…

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…

Sounds like you don't even have source control and a CI system.

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

#167

Post by avgDev »

ma2rten wrote: post #99
avgDev wrote: post #86

Earlier quoted context omitted.

This is impossible in my case, the source code is outdated. We do not have the source code of the project, which we run in production. The dev lost it. I have tried working with the source code but it has many bugs and it appears to be two years out of date. This leaves us with an application only in its current state with no way of making any changes. I may be able to extract pieces of information, reuse some stored…

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.

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

#168

Post by avgDev »

kolinko wrote: post #121
avgDev wrote: post #102

Earlier quoted context omitted.

Would you take this approach even if the framework is outdated? Part of rewrite is to switch to a newer framework and make general improvements in maintainability, reliability and speed.

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.

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

#169

Post by brlewis »

On the flip side, when a change doesn't take long to implement because of a successful campaign waged against technical debt, it's important to communicate that to the stakeholder too, even though they won't ask. I implemented such a change on Friday afternoon and made sure to talk about why it went well at sprint review and at sprint retro.

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

#170

Post by novaleaf »

hinkley wrote: post #117
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…

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.

yours and a lot of other comments seem to hint that this work may not be strictly required? I'm a bit surprised.

At least in my case, as a public facing SaaS I don't think running Node 6.x past it's LTS window is a valid choice, so better to bite the bullet now. If I went about doing the minimum work, it just adds more code/complexity that needs to be refactored when upgrading Node.

Post reply on HN