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

221–230 of 285 posts

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

#221

Post by aeorgnoieang »

Udik wrote: post #37

To me the main concern is that this shouldn't even be a code change: this stuff should be a matter of configuration. In a well-written system the dev time for it should be zero. But in general, the whole letter feels wrong: either the complications of such a trivial change depend entirely on legacy code that isn't responsibility of the current maintainer, and therefore the client knows well how hard and expensive eve…

I've actually come around to the opposite conclusion over the course of my career: everything should be hard-coded by default (tho using a well-named variable/constant/identifier). Making data-driven (e.g. configuration data driven) code is always more work and, unless you have strong evidence otherwise, [You Aren't Gonna Need It](https://martinfowler.com/bliki/Yagni.html).

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

#222

Post by Sharlin »

novaleaf wrote: post #176
hinkley wrote: post #120

Earlier quoted context omitted.

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.

I used to be all about jumping on the next fancy thing as soon as it was (pre)released. Having been burnt and learned my lesson, now I delay until it's blindingly obvious it needs to be done. But yeah, if it needs t be done, do it.

Version x.y.0 of most software is "public beta" quality. x.y.1 is "release candidate". x.y.2 might be production-ready.

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

#223

Post by hnlmorg »

Retric wrote: post #157
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…

That’s irreverent as each estimation is based on that team and it’s situation. If I am going to spend 20 hours a week stuck in meetings that’s going to impact my estimates.

It shouldn't do. Estimations should be based on FTE (full time equivalents) of the broken down tasks. An estimation shouldn't be guesswork of a delivery date based on your current teams situation but rather a calculated value of the number of days of effort (eg it would take 1 person 82 days if they worked on it for 7.5 hours a day) with a little margin added for any unforeseen technical hurdles that will inevitably crop up.

If estimations are based on FTE then you can factor in meetings, holidays, and even other projects that might suck up resources ("resources" in this case being your engineers work time) into your delivery date. You can detect very early on if your deadlines are slipping (assuming your team are logging their hours against tickers or a timesheet) and you can also make informed judgements ahead of time about whether you need more resources (were that's an option / the work can be scaled across more engineers).

Obviously this is harder if you're tackling a significantly larger "green field" project - you might have to start making some educated guesses in those instances. But most of the time you should have some idea about the work involved.

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

#224

Post by zoomablemind »

delinka wrote: post #19
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…

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…

The juniors are usually terrified by prospects of being responsible, so they get frozen or stuck

The estimating for juniors should be optional by default, but progress self-tracking mandatory. This way it yields facts without guilt and overpromiss. The team should estimate, the team should deliver.

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

#225

Post by Drdrdrq »

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.

For me it works pretty well if I imagine someone else (another team member who is less experienced) doing the job, and myself reviewing the code. It turns out my estimates about other people's work are much more accurate... :)

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

#226

Post by Buttons840 »

jen729w wrote: post #219
thanatropism wrote: post #95

Earlier quoted context omitted.

> . 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 a…

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

Yuck. I think the agile approach might be better here. It's better to expose your plan to reality ASAP and adapt along the way.

Except, that's not how agile really works. How agile works is "bosses" have an hour planning meeting, and then act as though they have a veeeeery robust plan (like you talk about) and get upset if things do go according to their quick one-hour plan. So much for adapting along the way.

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

#227

Post by ionforce »

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.

That model is too complicated for tiny minds. Just tell me when it will be done, man!

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

#229

Post by ma2rten »

dllthomas wrote: post #154
ma2rten wrote: post #99

Earlier quoted context omitted.

If it's language that has byte-code like java or .net you might be able to decompile the production binary.

Even if it's not, decompilation might be useful. What I'd try is decompiling both the running version and the build of the available source code, and see if the diff is informative.

Last time I checked x86 decompilers were not that useful.

They were producing code that is not compilable, often completely failing on more complex, translating code compiler boilerplate into code.

This was a while ago so maybe things improved since then.

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

#230

Post by pawelk »

everdev wrote: post #51
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've been developing for clients for 20+ years and 9 times out of 10 they do under estimate, but I think it has to do with lack of knowledge rather than anything malicious. I found myself doing it when I get quotes for home repair or construction. My mind immediately goes to "I don't think it should take that long" even though I have no idea how to estimate those types of projects. I wonder if it's because with somet…

> I found myself doing it when I get quotes for home repair or construction.

My quite recent conversation with a contractor about estimating our home renovation project went more or less like this: "Demolition: 2 days, foundation: 3 days, ground zero: 3 days, exterior walls: 3 days, floors: 1 day, ceilings: 2 days, attic and chimneys: 2 days... so about five months in total". I felt right at home and want to hire them. The jump from how much time each tasks seems to require in pure work effort to how long it may realistically take given the unknowns, downtimes, logistics and various overhead seemed similar to the way I do estimates. An hour here, a day there, another four hours for that... yeah, I need two weeks for this task.

Post reply on HN