4 ms·

Waterfall is natural law. All technology goes through the process: Analysis - Requirements - Specification - Design - Implementation - Qualification - Testing

Waterfall is natural law. All technology goes through the process: Analysis - Requirements - Specification - Design - Implementation - Qualification - Testing - Release. You literally cannot have good technology without enforcing this workflow and properly completing each step. Its a function of the nature of the way the mind works to solve a problem and encode that solution into a workable technology. This natural law is resisted by those who do not have experience with it, and who also attempt to make their mark on the universe by either re-inventing this natural law, and slapping their own brand on it, or attempting to ignore key parts they don't like, and in which they are not competent, refactoring it over time only to discover .. as it is a natural law - that they end up re-inventing it, as well. And then slap their brand on it. But I can say with great confidence after 40 years of developing technology, that the more you resist this natural law, the worse your product will be. All failed technology can be evaluated on the basis of how well this workflow was manifested by those involved. Scrum is just New-Age Waterfall. Agile is just 'officious scrum'. 10x developers are merely individuals who have stopped resisting this natural law, and in so doing have worked out how to apply it productively in almost everything they do .. Another factor is that Waterfall is iterative. You can do it in grandiose fashion, and you can do it on a granular, microcosm-level. The more you iterate, the more water flows, and the better things get - but people tend to resist revising themselves. The inclination to check oneself before one wrecks oneself is either bred out, culturally, or reinforced through the gauntlet of fire that is the modern industry. The better you get at iterating over the waterfall, the higher quality your product.

psd1 3y ago
I'm glad you brought up iteration in the context of waterfall. I do agree that the elements of analysis/reqs/spec etc are all vital. What isn't obviously necessary is that they happen in a rigid linear sequence. The point of MVP is to get from implementation back to analysis & requirements. By iterating through the steps in a non-linear way, you get better results for each step. I'd argue that requirements gathering is the hardest to get right and the part that most frequently fails, probably because workers are not consulted and, even if they are, they don't speak the same language as the analysts. So I believe that waterfall is still a good methodology, but (in most cases) only if it is done as a directed cyclic graph rather than a strict linear sequence, such that blocks of steps can be repeated. This breaks estimation, but estimation is broken anyway. It offers that each step is, finally, done right, but recognising that the first attempt at each step is bound to be wrong and must be iterated on. Does this match your view?
- boffinAudio 3y ago
  Well .. yes .. to an extent your point of view does match my view - because I feel that when you reach a step in the workflow that is weak, it indicates a prior step that is also weak. Which is why sometimes you get to Qualification of a feature, for example, and find that it doesn't match expectations - because the Requirements didn't fulfill the conclusions of the Analysis, say. Or because, indeed, of a weak Analysis or crap Implementation. However, there is a subtlety to this: >So I believe that waterfall is still a good methodology, but (in most cases) only if it is done as a directed cyclic graph rather than a strict linear sequence, such that blocks of steps can be repeated. Its both! You go through linearly, and if you're lucky, you ship! But if you don't ship, you go back to the prior weak step until it is strong enough to allow you to continue the linear path - and yes, it is always best done linearly from that point, in my opinion. Don't skip forward steps if you've done review and found a weakness, usually in Qualifications, but also very often in weak Specifications or Requirements - which always indicate a failure to properly Analyse. Instead, go back to the prior incomplete/inaccurate step, and redress the issue - and continue forward with the next step from there. No skipping! Skipping makes the whole thing weak again, polluting the stream. Rigorous linearity holds the order. For this reason, I have added 'gatekeeper' steps to my workflow, which I didn't want to include in my original comment, because I knew someone would then say "but thats not waterfall!" .. Waterfall needs review steps - navel-gazing - imho, which is why I always include: Analysis - Requirements - Specification - Design - [INTAKE] - Implementation - Qualification - Testing - [REVIEW] - Release. [INTAKE] is there to protect Developer sanity. If they intake the Design and find it wanting, that is the point where they can kick it back to the team (or internally, personally) to the prior, weak missing step. Same with [REVIEW] which is there more for managers so that they have an opportunity to indicate the weak/missing steps, prior to Release ... Without these two review steps, Developers and Managers will rip each other to pieces trying to assign blame/responsibility - but with these review steps, there is an opportunity for everyone to get along. Devs can kick things back if they feel things are weak, and nobody gets offended, because at the end of the line, prior to Release, managers can do it too .. Note that [INTAKE] allows Developers to protect themselves from issues that will negatively impact their ability to Implement, and [REVIEW] gives Managers a means to allow other factors (market conditions, business cases, etc.) to impact Development, and respond appropriately. These tow actions, done iteratively by well-coordinated Developer/Manager roles, produce great technology. Estimation: the more rigorous you are about the workflow, the better you get at Estimation, as a Developer and as a Manager. Also, the less rigorous you are about the linearity of the workflow, the worse your estimates - because there will be weak/missing steps which hide costs, time and energy.

psd1 3y ago

I'm glad you brought up iteration in the context of waterfall. I do agree that the elements of analysis/reqs/spec etc are all vital. What isn't obviously necessary is that they happen in a rigid linear sequence. The point of MVP is to get from implementation back to analysis & requirements. By iterating through the steps in a non-linear way, you get better results for each step. I'd argue that requirements gathering is the hardest to get right and the part that most frequently fails, probably because workers are not consulted and, even if they are, they don't speak the same language as the analysts. So I believe that waterfall is still a good methodology, but (in most cases) only if it is done as a directed cyclic graph rather than a strict linear sequence, such that blocks of steps can be repeated. This breaks estimation, but estimation is broken anyway. It offers that each step is, finally, done right, but recognising that the first attempt at each step is bound to be wrong and must be iterated on. Does this match your view?

boffinAudio 3y ago
Well .. yes .. to an extent your point of view does match my view - because I feel that when you reach a step in the workflow that is weak, it indicates a prior step that is also weak. Which is why sometimes you get to Qualification of a feature, for example, and find that it doesn't match expectations - because the Requirements didn't fulfill the conclusions of the Analysis, say. Or because, indeed, of a weak Analysis or crap Implementation. However, there is a subtlety to this: >So I believe that waterfall is still a good methodology, but (in most cases) only if it is done as a directed cyclic graph rather than a strict linear sequence, such that blocks of steps can be repeated. Its both! You go through linearly, and if you're lucky, you ship! But if you don't ship, you go back to the prior weak step until it is strong enough to allow you to continue the linear path - and yes, it is always best done linearly from that point, in my opinion. Don't skip forward steps if you've done review and found a weakness, usually in Qualifications, but also very often in weak Specifications or Requirements - which always indicate a failure to properly Analyse. Instead, go back to the prior incomplete/inaccurate step, and redress the issue - and continue forward with the next step from there. No skipping! Skipping makes the whole thing weak again, polluting the stream. Rigorous linearity holds the order. For this reason, I have added 'gatekeeper' steps to my workflow, which I didn't want to include in my original comment, because I knew someone would then say "but thats not waterfall!" .. Waterfall needs review steps - navel-gazing - imho, which is why I always include: Analysis - Requirements - Specification - Design - [INTAKE] - Implementation - Qualification - Testing - [REVIEW] - Release. [INTAKE] is there to protect Developer sanity. If they intake the Design and find it wanting, that is the point where they can kick it back to the team (or internally, personally) to the prior, weak missing step. Same with [REVIEW] which is there more for managers so that they have an opportunity to indicate the weak/missing steps, prior to Release ... Without these two review steps, Developers and Managers will rip each other to pieces trying to assign blame/responsibility - but with these review steps, there is an opportunity for everyone to get along. Devs can kick things back if they feel things are weak, and nobody gets offended, because at the end of the line, prior to Release, managers can do it too .. Note that [INTAKE] allows Developers to protect themselves from issues that will negatively impact their ability to Implement, and [REVIEW] gives Managers a means to allow other factors (market conditions, business cases, etc.) to impact Development, and respond appropriately. These tow actions, done iteratively by well-coordinated Developer/Manager roles, produce great technology. Estimation: the more rigorous you are about the workflow, the better you get at Estimation, as a Developer and as a Manager. Also, the less rigorous you are about the linearity of the workflow, the worse your estimates - because there will be weak/missing steps which hide costs, time and energy.