Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When did estimates turn into deadlines?

domainanalysis.io

Post reply on HN
Print view View original

221–230 of 237 posts

Re: When did estimates turn into deadlines?

#221

Post by MichaelZuo »

ethbr1 wrote: post #213
MichaelZuo wrote: post #210

Earlier quoted context omitted.

Wouldn’t a hybrid system make more sense? To only assign blame to people/teams when they’ve guaranteed in writing that it would be so and so, avoiding the downsides. And blaming the process when there were no such guarantees?

The issue with any hybrid system is you have to play the incentives out at scale. E.g. if blame is assigned when there's a written guarantee, why would anyone ever make a written guarantee? And not trying to be obtuse, but I've only ever seen blameless cultures work in absolute. Compromises let back in all the nasty mal-incentives you see driving unproductive CYA behaviors.

E.g. Some people with lower amounts of credibility will be eager to make guarantees in writing, if they want to sound more convincing than someone with higher credibility who disagrees.

Something like a new engineer disagreeing with a PM, a PM disagreeing with higher management, etc…

There’s many reasons why that would be a favourable choice.

Re: When did estimates turn into deadlines?

#222

Post by mattmanser »

Tostino wrote: post #128
analog31 wrote: post #65

Earlier quoted context omitted.

One technique is to run the modernization project, but use maintenance of the legacy software to keep the business going. Such maintenance could be for keeping up with hardware changes, OS upgrades, new features, and so forth. I've seen projects run in parallel like this for 10+ years.

I just got done doing exactly that with my old SaaS I built / worked on for a decade. Went through a roughly 3 year rewrite process while utilizing maintenance mode on the framework I had originally decided on back in 2014 and which sadly had an "upgrade path" of "you look like you could really use a full rewrite for your entire frontend" to get on the very next major version in like 2016. I'd say the main "use" for…

I've been doing this a while now, and as far as I can tell, there's always a way to run two frameworks side by side and migrate. And existing users get new stuff right away.

I've done it backend, I've done it frontend. With web apps it's always possible, it's the fundamental nature of the web and browsers.

Frontend is trivial because of how browsers work, every page could run a different framework if you were that mad.

Backend I've had two frameworks on one server for multiple migration projects. There's usually a way unless you're switching language.

But worst case scenario, say you wanted to change everything, I'd stick a load balancer in front. Route according to the end point requested. Then gradually migrate end points. You might need some craziness around authentication, but that's the sort of issue that is solvable with a week's work by a single, good, developer.

What was so complicated that stopped you doing that? Genuinely interested.

Re: When did estimates turn into deadlines?

#223

Post by rightbyte »

mewpmewp2 wrote: post #218
rightbyte wrote: post #200

Earlier quoted context omitted.

Ye. The manager need to be a programmer and involved in the project to be able to evaluate the participants. I guess 'estimation poker' is a way to counteract the obvious strategy to coast and look competent. In poker you can also look good by underbidding your peers and then snatch the easy ones to look good while the scapegoats look bad. The strategy need some social status or incubent code knowledge relative to th…

I have thought about how it would be fun to have something where people will either openly or blindly estimate and bid. In practice I might be concerned about few things like introducing too much of a competitive culture within the team. Or it could lead to a place where people get too specialized and knowledge doesn't spread around, since everyone will bid on things they have experience with, and so they will be the…

I think any process step that resembles a game might be problematic.

And a major problem with group estimates is that given how much knowledge a person has about the code, the effective time will vary so much.

So dunno. I have no experiance as a team lead or manager.

I would probably not track task time at all as a manager. It would give the illusion of insight. Rather some loose percent worked by project per programmer.

Re: When did estimates turn into deadlines?

#224

Post by Tostino »

mattmanser wrote: post #222
Tostino wrote: post #128

Earlier quoted context omitted.

I just got done doing exactly that with my old SaaS I built / worked on for a decade. Went through a roughly 3 year rewrite process while utilizing maintenance mode on the framework I had originally decided on back in 2014 and which sadly had an "upgrade path" of "you look like you could really use a full rewrite for your entire frontend" to get on the very next major version in like 2016. I'd say the main "use" for…

I've been doing this a while now, and as far as I can tell, there's always a way to run two frameworks side by side and migrate. And existing users get new stuff right away. I've done it backend, I've done it frontend. With web apps it's always possible, it's the fundamental nature of the web and browsers. Frontend is trivial because of how browsers work, every page could run a different framework if you were that ma…

That is actually part of the "extra support" we decided to pay for.

The application was originally written in Vaadin 7, Vaadin 8 had an absolute ton of breaking changes and we could not migrate in time, and then the breaking changes continued to compound as new releases happened and they migrated away from GWT, making a "big bang" rewrite not practical.

Their extended support included a tool called multi-platform runtime, which allowed the old application and new application to be run side-by-side and each section replaced one at a time. So that is essentially what we did. Still took 3+ years to do the rewrite.

Re: When did estimates turn into deadlines?

#225

Post by 93po »

bigiain wrote: post #51
redleggedfrog wrote: post #9

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…

> I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. I worked at a place where this management insanity was endemic, which lead to everyone padding all estimates with enough contingency to account for that. Which lad to the design team, and the front-end tea…

was this a company based out of Portland by chance? sounds like my last employer

Re: When did estimates turn into deadlines?

#226

Post by interactivecode »

DennisP wrote: post #201
aoeusnth1 wrote: post #45

Earlier quoted context omitted.

In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks. Maybe this is a good strategy for dealing with people who aren’t going to judge you for delivering slowly, or for managers who don’t know what the fuck is going on. For managers who…

I wouldn't advocate "super-inflated" estimates but within reason, there are long-term benefits if you go about it right. Where I mostly worked, managers cared about deadlines they could tell to external clients, which they really hated to miss. Early on, I didn't realize that, and gave my best guess. If I guessed the correct median, I was missing it 50% of the time, and managers kept getting mad at me. So I switched…

Being reliable is very valuable for the company. Better for you, better for the company. Unrealistic deadlines is bad for everyone involved. Especially for day to day work

Re: When did estimates turn into deadlines?

#227

Post by groby_b »

smegger001 wrote: post #149
groby_b wrote: post #143

Earlier quoted context omitted.

One way to get the point across is by stopping to pretend estimates are precise. Instead of giving a single fixed estimate, give one with error bars. "3 months, plus minus 4 weeks". Most engineers know their estimates have error bars, but have somehow been bludgeoned into forgetting to mention them. It's also helpful from the management side - the size of the error bars makes it immediately clear how confident folks…

>It's beyond me why we, as a supposed engineering profession, are unable to talk about risk, probabilities, and confidence intervals. And that isn't just on managers. Because management quits listening after hearing "3 months," and bad management heard "3 months minus three weeks" and goes "okay 2 months it is".

Outside of cartoons and a couple of rather bad environments, that's just plain made up nonsense.

Management in most places is rather interested in getting planning right, not making up numbers and then failing at achieving them. They often lack the training to get it right (both because we have non-engineers as managers, and because we give shit management training to the engineers that become managers), but "management quits listening" is just an excuse.

I'm in this thing for ~4 decades now, at a good number of companies of all sizes (3-200,000) and I've seen the "not listening and insisting on made up numbers" exactly once. I see however a lot of engineers refuse to even attempt to make reasonable estimates.

Re: When did estimates turn into deadlines?

#228

Post by ppeetteerr »

redleggedfrog wrote: post #9

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…

For starters, never commit to a timeline without doing your due diligence. We're not selling carpets. Anyone who gives a time estimate on the spot is setting themselves up for failure.

Second, always pad your estimates. If you have been in the industry longer than 6 months, you'll already know how "off" your estimates can be. Take the actual delivery date, divide that by the estimated date, and that's your multiplier.

Re: When did estimates turn into deadlines?

#229

Post by dizhn »

baxtr wrote: post #173
vander_elst wrote: post #159

Earlier quoted context omitted.

My method is take an educated guess multiply by 2 add 1 as extra buffer and then change it to the next unit, e.g. day->week, week->month, months->quarter. So for something that it should take 1 day I'd say 3 weeks. It seems a lot but at the end there's usually so much red tape, burocracy and and technical debt that it usually ends in the latter ballpark.

Nice algorithm!

Governments around the world must be using it too where a year turns into 3 decades.

Re: When did estimates turn into deadlines?

#230

Post by mmcdermott »

ben_w wrote: post #17
loloquwowndueo wrote: post #11

Earlier quoted context omitted.

Montgomery Scott recommends 4 instead.

A friend suggests doubling the number and increasing to the next unit — hours become days, days become weeks, etc. I've certainly seen some environments — plural — where a task that should take 1 hour actually takes 2 days, and one that should take 2 days takes 4 weeks.

> A friend suggests doubling the number and increasing to the next unit — hours become days, days become weeks, etc.

I don't know. Going from 8 hours => 16 days seems like quite the markup.

Post reply on HN