3 ms·

I think the fundamental misunderstanding is that we aren’t building a product. We are doing research and development. We are figuring out how to build something

I think the fundamental misunderstanding is that we aren’t building a product. We are doing research and development. We are figuring out how to build something novel, otherwise the customer could just go out and buy it already. Once we’re done with discovery, the computer builds it. So, the customer is like any other who is paying for research and development. It’s not a blank check, but they should go into it without the expectation that something new will be discovered on some accurate schedule.

z3ugma 3y ago
This is hubris of the field of software engineering. The no-code market and the existence of tools as old as MS Access prove that there are software projects for which a better analogy is not R&D, but construction. I do note that construction projects are also not good at estimating, but it's folly to suggest that at some level we are not _manufacturing_ rather than _developing_ a widget.
- sokka_h2otribe 3y ago
  Construction is a bespoke non-factory manufacturing process. If you extend the metaphor: Estimating large projects is a big construction projects. Those tend to be large buildings and relatively on schedule. Estimating small projects with small teams is bespoke. And more likely to go off schedule when the plumbers can't time well with the electrical services, i.e, you have a dependency on another teams API or something, similarly to how software struggles in small team open ended scope projects with unknowns. But a tightly scoped single-trade software project won't struggle just like construction. In end, I agree with you that construction is a decent metaphor. But construction is very far from manufacturing a widget, as it's a bespoke manufacturing process with ample site specific constraints
- ptrhvns 3y ago
  If we're going to talk about construction as the metaphor, then it's done by the computer (e.g. compilation), and it's so cheap or trivial on many projects that developers will ask the computer to build the software hundreds or thousands a times a day (e.g. via test-driven development). In this metaphor, I think the developer would be more akin to a designer or architect, but where the building in question is at least partially novel. If it's not novel in product, people, process, etc., then the client could just go out and buy or use one that has already been produced. The developer wouldn't be necessary.
RunSet 3y ago
> We are figuring out how to build something novel Is it possible to estimate the duration of a process that has never before occurred (e.g. the construction of something novel) with any expectation of accuracy?

z3ugma 3y ago

This is hubris of the field of software engineering. The no-code market and the existence of tools as old as MS Access prove that there are software projects for which a better analogy is not R&D, but construction. I do note that construction projects are also not good at estimating, but it's folly to suggest that at some level we are not _manufacturing_ rather than _developing_ a widget.

sokka_h2otribe 3y ago
Construction is a bespoke non-factory manufacturing process. If you extend the metaphor: Estimating large projects is a big construction projects. Those tend to be large buildings and relatively on schedule. Estimating small projects with small teams is bespoke. And more likely to go off schedule when the plumbers can't time well with the electrical services, i.e, you have a dependency on another teams API or something, similarly to how software struggles in small team open ended scope projects with unknowns. But a tightly scoped single-trade software project won't struggle just like construction. In end, I agree with you that construction is a decent metaphor. But construction is very far from manufacturing a widget, as it's a bespoke manufacturing process with ample site specific constraints
ptrhvns 3y ago
If we're going to talk about construction as the metaphor, then it's done by the computer (e.g. compilation), and it's so cheap or trivial on many projects that developers will ask the computer to build the software hundreds or thousands a times a day (e.g. via test-driven development). In this metaphor, I think the developer would be more akin to a designer or architect, but where the building in question is at least partially novel. If it's not novel in product, people, process, etc., then the client could just go out and buy or use one that has already been produced. The developer wouldn't be necessary.

RunSet 3y ago

> We are figuring out how to build something novel Is it possible to estimate the duration of a process that has never before occurred (e.g. the construction of something novel) with any expectation of accuracy?