6 ms·

"Software estimation is such a mess in part because it has trouble recognizing that, at least, just-in-time learning is at least non-normally distributed. Every

"Software estimation is such a mess in part because it has trouble recognizing that, at least, just-in-time learning is at least non-normally distributed. Everything we know about traditional project management, from Waterfall to Gantt charts to estimation practices, are on some level based around the idea that each individual step in the chain is bell-shaped: [..]" From experience I 100% agree with this, but it always caused a certain cognitive dissonance when thinking about project management approaches. A project is by definition a time bound one time endeavor. It is something where the crucial parts have never been done before. The unknown is the defining characteristic. Learning should be a defining characteristic as well, yet many approaches pretend it's a small part at best. My working theory is that the majority of "projects" that are typically used as comparison with IT projects (like construction) are not real projects at all. Real projects are rare (e.g. Burj Khalifa). In IT the ratio is the opposite. The real projects dominate and the "construction sites" are still the minority. But we can expect this to change. Thinking this to the end would mean that we could see a resurgence of waterfall in IT - likely under a different name.

deleted 2y ago
[deleted]
Normal_gaussian 2y ago
Whilst waterfall-like may be the approach, at least some (often the largest) steps are tough to estimate. The problem waterfall has is that it attracts deadlines like roadkill attracts flies. Presenting as following "agile" gives a strong body of literature to fight this - and actually do something else. We've all seen the criticisms that nobody does agile right - and for many, thats deliberate.
- weinzierl 2y ago
  Deadlines are good. The world operates on deadlines and IT is the exception. We can build bridges on time and budget most of the time because we've built millions of them in modern times and have been doing it for more than 3000 years. In software we are not there but I have no doubt that we will, and hopefully it won't take us that long.
  - tempaccount420 2y ago
    Oh man, software development will be so boring when we get to that point.
    - danielbln 2y ago
      "GPT, I need this thing built to spec." "Sure thing boss, come back in 25 minutes."
- cameldrv 2y ago
  IMO a waterfall like process can work for a lot of projects, but you need a lot of time for estimation/derisking, and this work is hard, so often developers don't want to do it, and management/customers often don't want to pay for it. Some of the most successful projects I've worked on have started with an estimate that had only a few items with more than 4 hours attached to them. If you get estimates down to that level, that means that most of the significant technical decisions have already been made, and you've determined that your technical approach should work. If you do that, and then add a calibrated amount of padding for mistakes, you can very often hit estimates pretty much dead on (+-10%). How much time it takes to prepare the estimate depends a lot on the nature of the work though. If there's something pretty similar the team has done multiple times, and you have access to estimates/tickets/timesheets, you can often get it done in about 5-10% of the total project time. However, for example, if it's an ML project, there may be a lot of unknowns that have to be clarified first. For example, data quality is almost always not what it is claimed to be at the outset, so this needs to be resolved before the estimate is generated.
yarbas89 2y ago
The project is the project side of the construction project and not construction side of the construction project =D Typically, in construction projects, 90%[1] of the challenges are encountered and resolved in the design office by a multi-disciplinary, multi-organisation design team effort across multiple years... [1] - Anecdotal evidence drawn from my experience as a structural engineer.
- weinzierl 2y ago
  My point is that the "project" side is not really a "temporary endeavor undertaken to create a unique product" [1] in the majority of cases. Sure the environment, circumstances and result differs for every construction project, but the variance doesn't justify to call it a project in most cases in my opinion. We've built millions of modern bridges that are in operation and we've been doing it for more than 3000 years. The number of environments, configurations and requirements we've not already encountered is very limited and these are the real construction projects that - no doubt - do exist. Now, contrast this with the number of CRUD apps we've built and for how long we've been doing it. There is still a lot to learn there. That's the reason why more bridges are on time and budget than CRUD apps, in my opinion. [1] https://www.pmi.org/about/what-is-a-project https://www.pmi.org/about/what-is-a-project
  - yarbas89 2y ago
    I sort of understand what you're saying but I'm struggling to agree with your examples in the comparison. Even if you're working on a "project" comprising hundreds of near identical houses, there could be massive differences in the project constraints and their solutions for adjacent plots for any given selection of houses. There could for example be a large tree with root protection zones on site where you would have to carefully design the foundations to account for this and their future effects such as heave due to volume change potential of the underlying soil. My point is that there are many "hidden" problems solved by the design team during the project / design phase even for seemingly insignificant or simpler "projects". In my experience of analysing and designing hundreds of buildings for over a decade every project was unique and as such treated like a "project".
0x000xca0xfe 2y ago
"Construction site" projects in IT would be Wordpress sites/small business eCommerce etc. and there are millions of successful projects of this type out there. Building them might be messy, but rarely fails from a technical point of view.
- weinzierl 2y ago
  "there are millions of successful projects of this type out there." I wish and believe we are getting there but I don't see it today. Just as an example: I traveled a lot after COVID and almost every tourist attraction has a photographer or photo site and they upsell by offering you pictures. I have yet to encounter two attractions that use the same system, they are all different and terrible in different ways. They all do basically the same thing, so there is no reason not to have a standard solution. I have no doubt one will replace the existing solutions sooner than later. So, millions of them but I would hardly call them successful. Them being messy is the collective learning process that has been mostly completed for real construction projects, but is still in full swing for IT projects.
  - rolisz 2y ago
    I think you two agree: there are millions of successful projects out there, but they are not standardized. But the guy who made 1000 of them knows exactly how long it will take him to build the 1001th
  - 0x000xca0xfe 2y ago
    "they are all different and terrible in different ways. They all do basically the same thing, so there is no reason not to have a standard solution" Sounds exactly like small construction projects. I have heard this sentence almost word by word from somebody who owns multiple small rental objects.

deleted 2y ago

[deleted]

Normal_gaussian 2y ago

Whilst waterfall-like may be the approach, at least some (often the largest) steps are tough to estimate. The problem waterfall has is that it attracts deadlines like roadkill attracts flies. Presenting as following "agile" gives a strong body of literature to fight this - and actually do something else. We've all seen the criticisms that nobody does agile right - and for many, thats deliberate.

weinzierl 2y ago
Deadlines are good. The world operates on deadlines and IT is the exception. We can build bridges on time and budget most of the time because we've built millions of them in modern times and have been doing it for more than 3000 years. In software we are not there but I have no doubt that we will, and hopefully it won't take us that long.
- tempaccount420 2y ago
  Oh man, software development will be so boring when we get to that point.
  - danielbln 2y ago
    "GPT, I need this thing built to spec." "Sure thing boss, come back in 25 minutes."
cameldrv 2y ago
IMO a waterfall like process can work for a lot of projects, but you need a lot of time for estimation/derisking, and this work is hard, so often developers don't want to do it, and management/customers often don't want to pay for it. Some of the most successful projects I've worked on have started with an estimate that had only a few items with more than 4 hours attached to them. If you get estimates down to that level, that means that most of the significant technical decisions have already been made, and you've determined that your technical approach should work. If you do that, and then add a calibrated amount of padding for mistakes, you can very often hit estimates pretty much dead on (+-10%). How much time it takes to prepare the estimate depends a lot on the nature of the work though. If there's something pretty similar the team has done multiple times, and you have access to estimates/tickets/timesheets, you can often get it done in about 5-10% of the total project time. However, for example, if it's an ML project, there may be a lot of unknowns that have to be clarified first. For example, data quality is almost always not what it is claimed to be at the outset, so this needs to be resolved before the estimate is generated.

yarbas89 2y ago

The project is the project side of the construction project and not construction side of the construction project =D Typically, in construction projects, 90%[1] of the challenges are encountered and resolved in the design office by a multi-disciplinary, multi-organisation design team effort across multiple years... [1] - Anecdotal evidence drawn from my experience as a structural engineer.

weinzierl 2y ago
My point is that the "project" side is not really a "temporary endeavor undertaken to create a unique product" [1] in the majority of cases. Sure the environment, circumstances and result differs for every construction project, but the variance doesn't justify to call it a project in most cases in my opinion. We've built millions of modern bridges that are in operation and we've been doing it for more than 3000 years. The number of environments, configurations and requirements we've not already encountered is very limited and these are the real construction projects that - no doubt - do exist. Now, contrast this with the number of CRUD apps we've built and for how long we've been doing it. There is still a lot to learn there. That's the reason why more bridges are on time and budget than CRUD apps, in my opinion. [1] https://www.pmi.org/about/what-is-a-project https://www.pmi.org/about/what-is-a-project
- yarbas89 2y ago
  I sort of understand what you're saying but I'm struggling to agree with your examples in the comparison. Even if you're working on a "project" comprising hundreds of near identical houses, there could be massive differences in the project constraints and their solutions for adjacent plots for any given selection of houses. There could for example be a large tree with root protection zones on site where you would have to carefully design the foundations to account for this and their future effects such as heave due to volume change potential of the underlying soil. My point is that there are many "hidden" problems solved by the design team during the project / design phase even for seemingly insignificant or simpler "projects". In my experience of analysing and designing hundreds of buildings for over a decade every project was unique and as such treated like a "project".

0x000xca0xfe 2y ago

"Construction site" projects in IT would be Wordpress sites/small business eCommerce etc. and there are millions of successful projects of this type out there. Building them might be messy, but rarely fails from a technical point of view.

weinzierl 2y ago
"there are millions of successful projects of this type out there." I wish and believe we are getting there but I don't see it today. Just as an example: I traveled a lot after COVID and almost every tourist attraction has a photographer or photo site and they upsell by offering you pictures. I have yet to encounter two attractions that use the same system, they are all different and terrible in different ways. They all do basically the same thing, so there is no reason not to have a standard solution. I have no doubt one will replace the existing solutions sooner than later. So, millions of them but I would hardly call them successful. Them being messy is the collective learning process that has been mostly completed for real construction projects, but is still in full swing for IT projects.
- rolisz 2y ago
  I think you two agree: there are millions of successful projects out there, but they are not standardized. But the guy who made 1000 of them knows exactly how long it will take him to build the 1001th
- 0x000xca0xfe 2y ago
  "they are all different and terrible in different ways. They all do basically the same thing, so there is no reason not to have a standard solution" Sounds exactly like small construction projects. I have heard this sentence almost word by word from somebody who owns multiple small rental objects.