3 ms·

Partially. But I think waterfall has (at least) two major weaknesses. The requirements are textual. They should be visual like a blueprint. A real custom home

Partially. But I think waterfall has (at least) two major weaknesses. The requirements are textual. They should be visual like a blueprint. A real custom home is typically visited and inspected regularly by the future home owner during construction. An improvement for waterfall would be a periodic delivery to the user of intermediate builds of the product – no matter how incomplete.

davidkhess 8y ago
In other words, waterfall didn't go far enough. Instead of discarding it, we should have continued to improve it.
balfirevic 8y ago
> A real custom home is typically visited and inspected regularly by the future home owner during construction. An improvement for waterfall would be a periodic delivery to the user of intermediate builds of the product – no matter how incomplete. May I suggest you look into this agile thing?
- davidkhess 8y ago
  I don’t think developing a solid and complete blueprint at the beginning of the process qualifies as agile.
  - balfirevic 8y ago
    With the intention of following the blueprint all the way to the end, user wishes be damned? No, that would not qualify. But it would qualify if you actually delivered partially built product in iterations and incorporate the changes that the client requests as they inspect it, even if you preceded it with extensive blueprinting. Only in that case, it has been found that developing such detailed blueprint is very time consuming and at the same time not very useful. So we don't do it for most kinds of software projects, but not because it's against any agile principles. The original agile principles (I was just getting into software development when they were articulated) really prohibit very few things, if anything at all. But they do emphasize valuing working, useful software over following strict plan. Use planning to the exact extent that it helps you do create such software.
    - davidkhess 8y ago
      The only part of the agile approach I like is iterative delivery. First, I believe software blueprints should be put together by people with 15 to 30 years of expertise. Secondly, blueprints for a custom home are completely indispensable and are referred to regularly during construction. I believe one of the reasons why is because they are visual, not textual. I believe software requirements should be the same and then they would be easier to adjust and would retain their value. Custom homes can be adjusted in mid-build. But it is a big deal and you have to get the architect involved and potentially have your plans revetted by inspectors and the city. It's a process that has a high cost. And it should because good blueprints like good software designs are highly dependent internally. I believe every change risks degrading their quality. If you are in a project where there are large numbers of unknowns about the functionality of the project, I highly recommend shrinking the scope to what you know and actually understand. Build that, and then learn from it. Then come back around and start a new "dave's custom home waterfall" (for lack of a better name) process to implement the next set of functionality. Constantly course correcting is a recipe for never finishing and weakening quality. There should be natural impediments to course correction and scope reduction should be used until the unknowns have been reduced to a reasonable risk level.
      - balfirevic 8y ago
        > First, I believe software blueprints should be put together by people with 15 to 30 years of expertise. Well, that is for one simply completely impractical, those people are few compared to the amount of software the world needs and also very expensive. But it's only one of many reasons why there are better approaches so let's move on. > Secondly, blueprints for a custom home are completely indispensable and are referred to regularly during construction. I believe one of the reasons why is because they are visual, not textual. I believe software requirements should be the same and then they would be easier to adjust and would retain their value. Many detailed requirements have, as matter of fact, been very visual, with detailed user interface mockups, process diagrams etc. When they are large in scope, they have been found not to be useful compared to the effort required to create them. When they are small in scope, they are actually used in real world agile software projects. And, I have to ask something about this process where extremely experienced people create detailed visual blueprints for the entire scope of the project and then deviate very little from it. Is it something you've actually seen produce good results (repeatedly) for your run-of-the-mill software projects? > If you are in a project where there are large numbers of unknowns about the functionality of the project ... that would be vast majority of them. > I highly recommend shrinking the scope to what you know and actually understand. Build that, and then learn from it. Then come back around and start a new "dave's custom home waterfall" (for lack of a better name) process to implement the next set of functionality. Well, every time you give concrete proposal about what to do in the face of uncertainty it sounds exactly like agile. > scope reduction should be used until the unknowns have been reduced to a reasonable risk level. That would, again, be agile. And I say that as someone who is not even particularly fond of of most standardized agile processes, such as scrum.
wink 8y ago
I think this falls flat in terms of imagination. Look at a building shell, even if you have zero clue about houses you can see if they used rotten wood. It looks like it will become a house. The more it progresses.. well, you can easily tell "that door shouldn't be where it is" and so on. Now look at the code generated by $framework via "$tool new project $name". To a non-coder (or even just not using that language) it's not really discernible from a 90% finished product. Your house doesn't turn invisible because looked at it from the back. Also house construction follows certain "easy" patterns a 5 year old can grasp - you need to start at the bottom, you can't put the paint on before the walls are in, etc.pp - give a coder of 10 years a project in another language without documentation and you won't hear anything in the direction of "it's more 10% or 80%" unless spending days. I'm not saying people building houses have an easier job - but it's palpable.
- davidkhess 8y ago
  To the first concern - that’s why I recommend you deliver (ideally) weekly intermediate builds of the product to the end user. Typically an underlying issue will begin to surface pretty rapidly. To the second concern, first, let’s get on the same page. When I use the home analogy it’s in regards to a custom home - not a from-plan/spec home. To your point, I believe well developed software should also have strong and obvious patterns that are reused in many if not all other projects.
- TheCoelacanth 8y ago
  It is not remotely that simple to tell if a house is a bad one. That is why people almost always get a professional inspection before they buy one.

davidkhess 8y ago

In other words, waterfall didn't go far enough. Instead of discarding it, we should have continued to improve it.

balfirevic 8y ago

> A real custom home is typically visited and inspected regularly by the future home owner during construction. An improvement for waterfall would be a periodic delivery to the user of intermediate builds of the product – no matter how incomplete. May I suggest you look into this agile thing?

davidkhess 8y ago
I don’t think developing a solid and complete blueprint at the beginning of the process qualifies as agile.
- balfirevic 8y ago
  With the intention of following the blueprint all the way to the end, user wishes be damned? No, that would not qualify. But it would qualify if you actually delivered partially built product in iterations and incorporate the changes that the client requests as they inspect it, even if you preceded it with extensive blueprinting. Only in that case, it has been found that developing such detailed blueprint is very time consuming and at the same time not very useful. So we don't do it for most kinds of software projects, but not because it's against any agile principles. The original agile principles (I was just getting into software development when they were articulated) really prohibit very few things, if anything at all. But they do emphasize valuing working, useful software over following strict plan. Use planning to the exact extent that it helps you do create such software.
  - davidkhess 8y ago
    The only part of the agile approach I like is iterative delivery. First, I believe software blueprints should be put together by people with 15 to 30 years of expertise. Secondly, blueprints for a custom home are completely indispensable and are referred to regularly during construction. I believe one of the reasons why is because they are visual, not textual. I believe software requirements should be the same and then they would be easier to adjust and would retain their value. Custom homes can be adjusted in mid-build. But it is a big deal and you have to get the architect involved and potentially have your plans revetted by inspectors and the city. It's a process that has a high cost. And it should because good blueprints like good software designs are highly dependent internally. I believe every change risks degrading their quality. If you are in a project where there are large numbers of unknowns about the functionality of the project, I highly recommend shrinking the scope to what you know and actually understand. Build that, and then learn from it. Then come back around and start a new "dave's custom home waterfall" (for lack of a better name) process to implement the next set of functionality. Constantly course correcting is a recipe for never finishing and weakening quality. There should be natural impediments to course correction and scope reduction should be used until the unknowns have been reduced to a reasonable risk level.
    - balfirevic 8y ago
      > First, I believe software blueprints should be put together by people with 15 to 30 years of expertise. Well, that is for one simply completely impractical, those people are few compared to the amount of software the world needs and also very expensive. But it's only one of many reasons why there are better approaches so let's move on. > Secondly, blueprints for a custom home are completely indispensable and are referred to regularly during construction. I believe one of the reasons why is because they are visual, not textual. I believe software requirements should be the same and then they would be easier to adjust and would retain their value. Many detailed requirements have, as matter of fact, been very visual, with detailed user interface mockups, process diagrams etc. When they are large in scope, they have been found not to be useful compared to the effort required to create them. When they are small in scope, they are actually used in real world agile software projects. And, I have to ask something about this process where extremely experienced people create detailed visual blueprints for the entire scope of the project and then deviate very little from it. Is it something you've actually seen produce good results (repeatedly) for your run-of-the-mill software projects? > If you are in a project where there are large numbers of unknowns about the functionality of the project ... that would be vast majority of them. > I highly recommend shrinking the scope to what you know and actually understand. Build that, and then learn from it. Then come back around and start a new "dave's custom home waterfall" (for lack of a better name) process to implement the next set of functionality. Well, every time you give concrete proposal about what to do in the face of uncertainty it sounds exactly like agile. > scope reduction should be used until the unknowns have been reduced to a reasonable risk level. That would, again, be agile. And I say that as someone who is not even particularly fond of of most standardized agile processes, such as scrum.

wink 8y ago

I think this falls flat in terms of imagination. Look at a building shell, even if you have zero clue about houses you can see if they used rotten wood. It looks like it will become a house. The more it progresses.. well, you can easily tell "that door shouldn't be where it is" and so on. Now look at the code generated by $framework via "$tool new project $name". To a non-coder (or even just not using that language) it's not really discernible from a 90% finished product. Your house doesn't turn invisible because looked at it from the back. Also house construction follows certain "easy" patterns a 5 year old can grasp - you need to start at the bottom, you can't put the paint on before the walls are in, etc.pp - give a coder of 10 years a project in another language without documentation and you won't hear anything in the direction of "it's more 10% or 80%" unless spending days. I'm not saying people building houses have an easier job - but it's palpable.

davidkhess 8y ago
To the first concern - that’s why I recommend you deliver (ideally) weekly intermediate builds of the product to the end user. Typically an underlying issue will begin to surface pretty rapidly. To the second concern, first, let’s get on the same page. When I use the home analogy it’s in regards to a custom home - not a from-plan/spec home. To your point, I believe well developed software should also have strong and obvious patterns that are reused in many if not all other projects.
TheCoelacanth 8y ago
It is not remotely that simple to tell if a house is a bad one. That is why people almost always get a professional inspection before they buy one.