Isn't that what waterfall was? Replicating building a house? Gather requirements, design it, plan it, build it.
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.
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.
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.
May I suggest you look into this agile thing?
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.
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.
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.
How many years of expertise do you think architects of large buildings probably have? Engineers of critical bridges and other public infrastructure? One thing we need to do is stop aging out our best talent.
> 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?
Absolutely. I have a 100% success rate using these techniques with over 20 under my belt. Granted, I'm mainly a solo operator but I've used it for larger projects too on occasion.
> Well, every time you give concrete proposal about what to do in the face of uncertainty it sounds exactly like agile.
The difference is time frame and phasing. Consider deciding to enlarge a kitchen in the middle of building a custom house. Now compare that to an addition to an existing home. They are very different situations.
> 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.
The difference again is the time frame and the phasing. Messing with the scope/design every week I think is an anti-pattern and a contributor to project failure.