191–200 of 221 posts
Earlier quoted context omitted.
This holds very true up to the architect level.
As learning curves generally flatten out, that is to be expected.
Earlier quoted context omitted.
So to clarify: what the top-level poster here is calling “non-trivial” you are calling “category 3”, and heuristically estimating that it will take 10x longer than anticipated. But this (a) is still quite optimistic, and (b) ignores variance. The potential time a new research project could take is unbounded.
Yup, padding estimates is akin to what you might do if you had a repeatable process but there was some predictable variance (e.g. illness, machinery maintenance, holidays) rather than a bunch of unknown and exploratory problem solving.
Estimating requires you already understand the very thing you're estimating. This is why plumbers, and electricians give you reasonable estimates. Heck when we hired movers after buying our first home they estimated two hours, and were done just a few minutes before the 2 hour mark on the spot.
The issue with programming is, your tools change, your approach changes with new iterations (usually for the better!) and you notice new problems, or sometimes you do one thing in 5 minutes, and your second run through using a similar approach is broken because it requires an edge case you didn't anticipate code wise.
Earlier quoted context omitted.
>Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial. It's always maddening to get into debates about this stuff with project managers who believe this nonsense. I know the Fibonacci point scale is supposed to address this by giving PMs something , but I've only ever seen it turn into time-estimates-by-proxy. These days, I only ever give estimates in terms of…
This 100% this. I run my teams via "Kanban" (I don't know how kanban it actually is, but that's what I call it). The only question I ask around prioritization is "Is it worth doing?" If the answer is yes, I ask the stakeholder if they care how long it takes. If they do, I ask for a range and give a best estimate if it's achievable. If the answer is no, I ask why they care how long it takes if it's the most important…
Ask them to prioritize the tickets. Maybe they want some rough estimate to decide between some of them, maybe not (which is, suprisingly, in most case). During the same meeting you can groom the tickets.
The developers then start working on those tasks, when they are ready you release them according to your company policy and calendar.
By then everyone have forgotten about Scrum, management is amazed you release so much stuff, you can probably put all that in a one hour max weekly team meeting and everyone is happy.
I'm pretty sure that's applicable in a lot of pure player tech teams and quite scalable (I managed up to a 15 devs team this way but PR validation etc overtook the management part a bit much).
Developer to self: "It'll take me about a week" Developer to development lead: "It'll take about two weeks" Development lead to project manager: "It'll take about 4 weeks" Project manager to self: "It'll take double that plus 2 weeks" Project manager to management: "It'll take 12 weeks" Management to client: "It'll take 8 weeks" Actual time taken: 16 weeks.
Isn't it common for sales people to intentionally give a longer time frame than management specifies? I believe they try to buffer 20%+ rounding, unless there is an exact public release date. Though, I'm not in sales so I could be completely wrong. In the consulting world there is the rule of three, where you multiply everything by three, not just how long it will take.
Earlier quoted context omitted.
>Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial. It's always maddening to get into debates about this stuff with project managers who believe this nonsense. I know the Fibonacci point scale is supposed to address this by giving PMs something , but I've only ever seen it turn into time-estimates-by-proxy. These days, I only ever give estimates in terms of…
This 100% this. I run my teams via "Kanban" (I don't know how kanban it actually is, but that's what I call it). The only question I ask around prioritization is "Is it worth doing?" If the answer is yes, I ask the stakeholder if they care how long it takes. If they do, I ask for a range and give a best estimate if it's achievable. If the answer is no, I ask why they care how long it takes if it's the most important…
"Why can't we better estimate these things?" Because when I give honest estimates I get threatened by my boss. Your process is not reality driven.
"Can we break this work down into smaller stories?" No, I can't break down the final integration of all the parts into a smaller story. Or more commonly, they told me we have "too many stories" and can't keep track of them all when we break them apart.
The best is when a Product Owner or other business type says "I'm not a technical person." Then why the hell are you working in a such technical business and calling the shots on stuff you don't even understand?
Earlier quoted context omitted.
Most maddening thing I've seen is PM translating agile points to man-hours because that's what upper management requests. Same people: you must complete assignments in the estimated time, or else, be prepared to work overtime including weekends. It drives me bonkers.
We have a great labor market. Don't be shy about quitting when things get cray-cray!
What is an MVP?
Earlier quoted context omitted.
The real short answer is: he doesn't, he could just use Github Pages or similar :-) I'm guessing he likes to tinker.
To be honest that's not it - as in my sibling comment it's just attaching the blog onto the site was the fastest way to go, given that I wanted to keep it on the same domain. The product just happens to be built on kubernetes already, use of kube is definitely not for the blog. I'm actually pretty surprised that nginx couldn't handle the traffic to be honest. Even with the fairly low resources I'd allocated it. It's…
How did you manage to constrain the time overrun to only 4x? As a mercenary engineer, I've had to answer the estimation question many times. Whenever I've given estimates, it has only ever shot me in the foot. Spolsky might have figured it out, but I haven't. So I try to avoid giving estimates as far as possible and instead focus on demonstrating velocity of a working system they can choose to stop funding at any tim…