> Decent fit, in my opinion!
Why wouldn't running an Anderson–Darling test answer that question?
Why software projects take longer than you think: a statistical model (2019)
131–140 of 178 posts
Re: Why software projects take longer than you think: a statistical model (2019)
#132All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…
My last employer required us to do project-long estimates based on whatever they asked for up front. However, they then felt like changing everything on a daily basis, making the estimate pointless.
> making the estimate pointless
Did anyone tell them this?
Re: Why software projects take longer than you think: a statistical model (2019)
#133Earlier quoted context omitted.
> What I find ironic is that everyone in the industry knows that estimating is very hard, thus estimations are nearly useless, yet everyone insists on the importance of planning and on basing such planning on void estimates. Obviously, planning is critical. Planning means resource allocation. How is this not a critical aspect of any project? The mistake you're making is presuming that if estimates are not crisp then…
> Obviously, planning is critical. Considering it very often fails even for successful projects, obviously, it is not. > This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required Your line of reasoning is detached from reality. The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are req…
> > Obviously, planning is critical.
> Considering it very often fails even for successful projects, obviously, it is not.
This is not a relevant strawman (if it fails for some, it works for none?). Working without a plan isn't how humans work. You want to argue about scale, that's fine, but far from absolute.
> > This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required
> Your line of reasoning is detached from reality.
You provided nothing to indicate that the reasoning is detached from reality.
> The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are required, still they never get the right answer until the project is completed.
Any estimation I make for myself is not subject to it. My cofounders are not subject to some project leader who is trying to sabotage us. Simply put, this is another strawman to abdicate explaining the pros and cons (due to a lack opinion or thought?). It is not compelling.
Re: Why software projects take longer than you think: a statistical model (2019)
#134Earlier quoted context omitted.
> if you gave accurate estimates, you'd get reprimanded I like the cynicism, but this implies that you can give accurate estimate, which I also take exception to. To give an accurate estimate, you'd have to first have a complete specification, which I've never seen.
Pretty much correct, IMO. Really, the first build (and usually the only one, unfortunately) IS the process of estimating. I try to POC as much as possible to make sure I know where the landmines are. Just this week, I blew by one of my own recent estimates because I assumed I could pretty easily determine the output column names and data types for any arbitrary SQL Server stored procedure using a SQL query. Many impl…
> Really, the first build IS the process of estimating.
You hit the nail on the head.
Re: Why software projects take longer than you think: a statistical model (2019)
#135All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…
Indeed. Development should not begin until all requirements have been finalized.
Every project I've ever been on that had wildly wrong estimates was because management didn't actually plan jack shit either due to inexperience, laziness, malice, or all of the above. They then play the blame game to try to keep their job, and man it's so hilarious to witness the sheer carnage as everyone tears them a new asshole nowadays with the rise work from home (group chats/calls, DMs, etc.)
We seriously need to drain the swamp of inept management and nepotism within business ranks.
I've experienced better and it is absolutely possible to be off by less than ~25% of the total time estimated.
i.e. it took 6 days instead of 5, or it took 5 months instead of 4, which is way less depressing.
Re: Why software projects take longer than you think: a statistical model (2019)
#136Start from an empty file and write to an imaginary API or pseudocode what you actually want to do and coding is easy and fast! I think the high level imaginary API/pseudocode of any system is straightforward and fast when you start from scratch. (Because you're not focused on detail and just intent) But when you start from an existing codebase, existing infrastructure, existing APIs, it slows to molasses. You've got…
> way of saying that the behaviour is the product of every statement about the behaviour that is desired, not an explicit instruction of what to do next
I believe you'll enjoy reading "Notes on the Synthesis of Form" by Christopher Alexander [1]. There are many ideas in it, but at the later chapters the author proposes a system for solving design problems as a large graph of interacting requirements, where smaller sub-graphs are (hopefully reusable) components solving a smaller set of requirements.
Sounds similar to this idea of yours, just with a key difference in that the author sees it as a two-pass solution: first you "carve" out your solution by establishing a context boundary, and then do you "fill" it with an implementation - such that the solution is the minimal implementation that fits the context, and not anymore.
After reading the book, I have also adopted a similar approach (but with less formalism) to gather requirements for projects in the past.
I have thought about developing the ideas of the book further, if you find this subject interesting we can discuss (I can ping your profile's email). I'm certainly interested in hearing more of your own ideas, as it seems to intersect.
[1] Same author of "A Pattern Language", that inspired the design patterns concept in software
Re: Why software projects take longer than you think: a statistical model (2019)
#137Software engineering down to at most 60-lines per function goes a very long way to knocking down the fluctuations of project management by the most.
Largest I have done is a 120,000 code line project to within two months of missing its original project deadline; of course, you'd need some block time just to do the planning, architecturing, and with existing manpower.
Most fluctuations are geared toward the unit and integration tests coding and making it "work".
This is what I have been doing to nail any project planning to a promotional-level degree.
Re: Why software projects take longer than you think: a statistical model (2019)
#138This seems pretty reasonable to me. Maybe some of the details are wrong, I don't know.
But my big question from this article is... why isn't this a well known aspect of project planning, scheduling, and software engineering? It's not even specific to software really - I mean it's possible that software tasks have higher variance than others but I'd be surprised if task variance is irrelevant for scheduling non-software projects.
Is it really the case that no one has applied mathematical modelling to the problem of project planning, scheduling and estimation before? Do the ideas in this blog post represent the core of a new avenue of research? Seems unlikely. So how come this, or something like it, wasn't taught as a basic and critical part of project planning, in the same class that taught me the term "Gantt chart"?
Re: Why software projects take longer than you think: a statistical model (2019)
#139All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…
> if you gave accurate estimates, you'd get reprimanded I like the cynicism, but this implies that you can give accurate estimate, which I also take exception to. To give an accurate estimate, you'd have to first have a complete specification, which I've never seen.
If you are fully in charge of a project you can often create complete specs. When working with PMs, designers, other stakeholders, you can often not have complete specs because the requirements are constantly shifting. Because you're "lean" and "agile".
Re: Why software projects take longer than you think: a statistical model (2019)
#140I wonder why people are so focused om probability distributions that look like one peak sided by two tails.
There's another way to look at it.
For project estimations I've made people give up on the whole fiction of estimates by simply confronting them with the fact that maybe it's going to be very easy (eg, there's an API for it already, or there's a nice library), or maybe it'll be quite hard (eg, it may require writing a sqlite extension, or using multipath TCP, or something else you haven't done before).
That's a probability cost landscape with two peaks! And the number you get by interpolating between the peaks will be the most wrong.
Makes some people's heads explode, because they want to slot a single number into a field, and you're just not giving it.
Some others will see the light and leave you to your explorations, after which you'll sync with them on your findings and where to go from there.