131–140 of 212 posts
It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
you forgot to multiply by pi
It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
I can't tell you are serious or satire. If you are serious that kind of estimate is as good as useless because the projects most likely won't be profitable. Can you imagine what will a property developer think if he is informed that his project is going to take at least twice as long to complete?
Property developers aren't doing R&D jobs. Most of software development is a multiplayer life sciences R&D, because even if you're not developing new technology, the combination of your chosen stack, target market, stakeholder personalities and management policies, makes your project a one-off job in an unexplored environment.
It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
Wait, are you estimating without taking into account the moon phase? Good luck with that.
Anything short of this isn't amenable to the scientific method.
Earlier quoted context omitted.
Get out of the company if it has this kind of management.
I hate to say it but from my 20+ years in the industry, this is the norm.
My conclusion is there are 2 kinds of engineer: good ones and shit ones. Good ones just need to be told what to do and be left to get on with it. They value autonomy, and any attempt to micromanage them with agile bullshit drastically demotivates them. Shit ones are shit. They need a good one to help them get through their tickets, by asking what's taking so long and showing them better ways of approaching the proble…
Earlier quoted context omitted.
Spoiler: no one thinks they should have to pay for software these days.
I think a lot about the effect that ad-driven business models and open source must have had on the propensity to spend money on software products. Both in terms of pricing and in terms of build vs. buy. Mostly because I’m always musing about software developers’ hard earned reputation as the cheapest customer demographic on Earth.
FWIW, I'm still enjoying, using and supplying open source, especially that as a power user, I can get a better deal on the whole thing. However, I think we need to recognize the unintended consequences this has, and that in a sense, we're ourselves responsible for the shitty and abusive industry we work in and live with.
It's not fake research. It's actually quite an established science in the 24 years I've been doing it. Take your first guess, double it, double it again if the stakeholder is a poser, add 20% per developer less experience than you, subtract 10% for the features you're going to essentially copy paste, add 15% for sick leave (browsing HN) and then double it for every question you have that are unresolved and divide it…
Earlier quoted context omitted.
The real problem is not with estimation but with the management denial. I was asked to estimate a project I owned as a “green” lad. I offered 6 months with a real detailed plan and up to a year with some extras. Based on past rates we had etc. I even did some statistical modeling. They disagreed. They decided to alter the approach, that the principal engineer had suggested and “it would take 2-3 months.” Two years la…
>>>. The real problem is not with estimation but with the management denial. ^^ This is the truth. All estimation processes in any company are just ceremony. Management already has a deadline fixed. They will make you agree to their deadlines, even though whatever process stipulated by them says otherwise.
The real problem is saying "yes we can do it all in that timeline" instead of saying "That's fine, but we won't get to everything. We will work with you to prioritise the most important things to get done in that time."
I know it's painful, but just hold that line. It's not lying or negotiating or padding; in fact it may be the only true statement you can say.
If a civil engineer were building a bridge, and couldn't do it safely in the budget and timeline, they'd say so, and the project manager would nod and diligently write that down. We have a more subservient relationship with project managers in software because we choose to.
Earlier quoted context omitted.
> But even a bad estimate gives you some handle on how easy or hard something is to do Can’t agree with this at all. A bad estimate is by definition bad. How does it give you a handle on anything if it’s unreliable? It’s like saying bad medicine is better than no medicine. And when you talk about breaking an estimating problem into smaller estimates, you’re now firmly in the domain of actually doing the work. An econ…
That's the problem. You have an opinion but no empirical evidence and you think your opinion is pretty good. There's plenty of material out there that is a bit more well reasoned that disagrees with your opinion. For example Don Reinertsen's books. Most Agile estimates are pretty bad. But that's OK because it's still better than just winging it. One of the realities of working with real companies is that they have th…
Wait - there is a large body of work that is better reasoned than a quick post dashed I off in haste before dinner?
> One of the realities of working with real companies is that they have things like dead lines
Using condescending terms like "real companies" is unnecessary. You know nothing at all about me or how I've come to my conclusions; you just make arrogant assumptions that you know better about this than I do. I'm open to being wrong and learning new things, but do you really think you have the Silver Bullet?
My experience over a large number of projects suggests that the whole premise that most commercial software project problems can be solved using technical, mathematical or scientific means is wrong. My opinion - which aligns with the results of large-scale studies such as the Standish Group CHAOS reports, the PMI Pulse reports and more - is that the problems with commercial software projects appear to be almost entirely social and organisational. Projects are too ambitious, too complex, and are executed poorly by inexperienced people. No amount of time spent on estimation is going to fix that.
I am unfamiliar with Reinertsen's work, but I think it's quite interesting that economics is not exactly a science either.