Earlier quoted context omitted.
Nonsense. Code is copy-pasteable; other things are not. One can give very accurate estimates of how long it takes to build a brick wall because building brick walls takes time and labor. You can make highly accurate estimates of how long it takes based on how long it has taken to do the exact same task in the past. But suppose I laid one brick and then could copy-paste it, then copy-paste that into four bricks, then…
Building brick walls is easy to estimate not because it is physical labor but because the company has done it many times before. Ask a construction company to estimate a unique one-off job and they will most likely fail. And that is despite them getting a lot of resources for investigating and planning which software engineers almost never get.
When did estimates turn into deadlines?
121–130 of 237 posts
Re: When did estimates turn into deadlines?
#122Earlier quoted context omitted.
Heuristics I'd learned was "double the time and bump the unit". So: 2 hours -> 4 days, 1 week -> 2 months, etc. (I'm not sure where this turned up, but it's a long time ago, going on three decades.) The other option is to carefully track tasks, relevant dimensions, estimates, and actual performance, and see if there's any prediction modelling which can be derived from that. Problem is that this a classic instance of…
So 1 year -> 2 decades?
Note that this also comes out about the same if you're using months (12 months -> 24 years (2.4 decades)) and (at least within a factor of two-ish) weeks (52 weeks -> 104 months (0.867 decades).
I'm not claiming this is accurate, I'm stating that it's a heuristic I'm familiar with.
This may have been in Arthur Bloch's Murphy's Law and Other Reasons Things Go Wrong, though I'm not finding it in comparable collections. Possibly from project planning literature I was reading in the 1990s (DeMarco & Lister, Brooks, Boehm, McConnell, etc.).
Re: When did estimates turn into deadlines?
#123I often see takes on this topic from the engineering side. "It's hard!". "Managers just don't understand". It feels like as a community, it would be useful to get more articles seeing things from the other side and exploring functional approaches beyond provide-a-worst-case-scenario-estimate. There's a reason this dynamic is so pervasive. In order for everyone in an organization to do their job well, people do often…
The whole world runs on deadlines and timelines. Even a president is elected for a specific duration. If you're in a B2B setting, the customer demands (sometimes even contractually binding) at least the Quarter when something will be delivered.
Time is the only common denominator by which different activities can be coordinated. Without some heed to time, there will be no coherence.
Re: When did estimates turn into deadlines?
#124> Can you imagine if the insurance company started arguing with the repair shop, asking them—no—telling them that they would only pay the $18,000 and not the additional $20,000 because that was the original estimate? Does that sound ridiculous to you? It does to me, too. No, actually, this sounds quite realistic and in many cases even reasonable. Medical insurance does this literally all the time. Insurance companies…
Our bad assumption is in thinking that only the final output matters, regardless of when and where it is delivered. Like saying that it only matters if the train arrives at the station, regardless of when it does.
The problem is anyone depending on us downstream will get impacted. And yes, estimation is tough, requires foresight, and maybe a lot more things, but that's what being a professional means.
Re: When did estimates turn into deadlines?
#125A lot of ink has been spilled on this topic. The solution is simple: get better at estimating. Software engineers act as if they're the only ones in the world who are asked to estimate and then held accountable. It's a skill issue.
If you're hiring architects and engineers to design and build your home, you might already have a pretty good idea of the home you want. The people you've hired provide estimates on cost and timing based on solidly known quantities. They've put in a basement like that before. They've worked with your weird materials. Their vendors report on material status daily. Software development is not surrounded by this sort of…
Contractors have to plan for surprises as well. The thing is they've done enough similar work to understand the risks and account for them in budget and timelines.
I think a lot of software engineers, possibly because of the classical world they inhabit, are reluctant to look at things as probabilistic. Your estimate can take into account unknowns you just need to estimate the likeliness of encountering certain snags and the penalty they will impose.
Re: When did estimates turn into deadlines?
#126A lot of ink has been spilled on this topic. The solution is simple: get better at estimating. Software engineers act as if they're the only ones in the world who are asked to estimate and then held accountable. It's a skill issue.
It's literally impossible to know what you don't know. Sometimes you discover things in the process of your work that couldn't have reasonably been accounted for on first estimate, and it is not good practice to always give an estimate that assumes a 5x difficulty multiplier for some unforeseen reason. Yes, if this is an "every time experience" then there could be a skill issue or possibly some other undiagnosed or u…
Software is the same thing. There are unknowns but there aren't unlimited possibilities.
Re: When did estimates turn into deadlines?
#127Earlier quoted context omitted.
You make projections instead of estimates. You split the work that needs to be done into many tasks and project from past experiences. You cannot rely 100% on any estimates either, and all you are doing by demanding estimates is creating stress and making people less productive. The meta work imposed by that in itself will make a project take more time, as everyone will be padding their estimates.
What is the difference between a projection and an estimate?
Re: When did estimates turn into deadlines?
#128The article is about modernization projects, which have soft deadlines because ostensibly the legacy software is still running while you're developing the replacement. There's always budget pressure, and promises may have been made, and users may be hoping for new features and eliminated frustrations... but if the replacement is a day late, it really wouldn't matter much. Conversely, if you're trying to launch a spac…
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.
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 utilizing their maintenance support, was the fact that they would still fix issues with browser incompatibility, security issues, etc.
Like the fact that back in the day Chrome changed background tabs to no-longer respond to push notifications unless they are the active tab (after some delay)...it broke things in our app. But luckily we able to lean on the vendor for those types of issues, because there was very little my team could do to make a rewrite of a massive webapp any faster than it was already going.
Glad it's done, and I am out.
Re: When did estimates turn into deadlines?
#129Earlier quoted context omitted.
> 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…
This is literally the endgame. And the only cure is instead building a company that's tolerant of mistakes while still aspiring to excellence. The one I've worked at which got the closest had a corporate culture that failures were atrributable to processes, while successes were atrributable to individuals/teams. Of course that had its own negative side effects, but on the whole it made the company a lot more honest w…
Re: When did estimates turn into deadlines?
#130Earlier quoted context omitted.
I think general problem on HN is that you can't say something "bold" without people going "nuts" - especially when it comes to estimating work. In my experience (been hacking since the '90's before it was cool) great developers are great at estimating things. And these are not outliers, all except 1 great developer I've had pleasure of working with over these years has never been "off" on estimates by any statistical…
It really depends on what you are working on. When I did agency type of work, building things you have built before, from scratch, it's easy to estimate. E.g. some sort of e-commerce website from scratch. On the other hand, working in a large corp, with massive legacy systems, unknown domain knowledge and dependency on other teams, it becomes near impossible. What might have been a 2 hour task in agency, might either…
My comment was not really geared towards chaotic organizations but general sense (especially in myriad threads on this forum) that SWEs think that somehow our profession is so “special” that we cannot possible know how long something will take. I simply do not accept that and personally believe that more likely vast majority of SWEs simply suck at their job. there are roughly 4.5 million of us, how many are really good at their jobs (big part of which is estimation)? probably like 0.4% :)