4 ms·

So it's better than anarchy? Admittedly it's a low bar to clear, but what would you propose as better?

feoren 5y ago
A small team of smart people all working together with a shared goal, a clear vision, flexible roles, open communication with subject-matter experts, and a manager who acts as a shield against external forces (obsessive changes, design by committee) and as a provisioner of resources to the team?
- mmarq 5y ago
  Amen
cjfd 5y ago
Not much planning. Direct contact with the people who use the software. Good coding practices, preferably TDD. No time pressure. This is pretty much agile how it should be in theory but not in practice. Agile in theory is actually a very good development process. Agile in practice tends to be a bit worse. Waterfall always is the hell. My boyfriend is at the moment doing waterfall development. He hates it. So much useless paperwork.
- aaaaaaaaaaab 5y ago
  Yeah, that’s fine for developing the new landing page for the company website. Not so much for developing mission critical systems.
  - cjfd 5y ago
    I disagree. Among the things that I listed was TDD. If one practices that consistently one can create highly reliable software. In fact one might argue that using TDD for the new landing page for the company website might be overkill. Maybe you do need a bit more planning for your 'mission critical system' in order to perhaps attain performance goals. However, I will tell you here and now that if you just do TDD for your mission critical system and you do it well you will already be better than most programming going on for so-called missions critical systems in many, many places.
    - iratewizard 5y ago
      TDD is cargo cult.
      - cjfd 5y ago
        It really is not. TDD is for highly competent programmers.
        aaaaaaaaaaab 5y ago
        Lol, not really: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
      - dragonwriter 5y ago
        > TDD is cargo cult. No, but like any practice that becomes known of outside a narrow group of highly-competent, highly-motivated experts in the relevant area, TDD can be (and often is) cargo culted. It is thus often the case that people's only practical contact with “TDD” is with a cargo cult application of it.
        cjfd 5y ago
        This is true. The most important way in which TDD can turn into a cargo cult practice is to test every class and every method separately. This then turns into the testing of implementation details that are very much subject to change. It can also lead to the testing of trivialities, like 'can the standard library of my language still add elements to a container'. One should in most cases write tests about somewhat higher level properties of a system where the user might actually recognize the tests as being about stuff that they value. In most cases one would write tests about a small set of closely related classes. There should also be tests about somewhat larger clusters but there should be fewer of them because they tend to be more brittle and have worse performance.
        mbrodersen 5y ago
- yyyk 5y ago
  TDD is an implicit repudiation of Agile. One of the principals of the original Agile manifesto was "working software over comprehensive documentation". After all, a test is a form of documentation, albeit one that is more suited to a programmer's tastes. Agile places software and documentation at opposition - TDD tries to tie them together.
  - dragonwriter 5y ago
    > TDD is an implicit repudiation of Agile. TDD was developed in the 1990; Agile was articulated in 2001. Were they actually opposed, “Agile is a repudiation of TDD” would be more defensible. But your basic premise is wrong... > Agile places software and documentation at opposition No, the “X over Y” statements in the Manifesto aren't about opposition, they are about subordination. ”over” can be substituted with “should shape the use of” rather than “should exist instead of”
    - yyyk 5y ago
      You're right about the historical chronology, but TDD adoption IMHO came much later, after Agile exploded in popularity. Maybe it's just my neck of the woods, but I heard of TDD only much later. As for the "X over Y" statements, well, it's a rhetorical style which definitely creates an implicit opposition. Subordination makes no sense here. Our job and the business value is in working software, of course we want that most of all. Why mention it over something unless that something is in the way and we want to discourage it? Let's say I told people "Crossing the road over obsessively looking at both sides of the road"*, and kept referring to "obsessive looking" while barely mentioning people should look at all. As guidance this is horrible, for reasons I believe are obvious. If I said later "I only meant obsessive looking" and "you should adjust your crossing process so it suits you" it wouldn't make my advice right, would it now? * Documentation is of course much less necessary, I'm just taking an extreme example to show the rhetorical style.
      - Jtsummers 5y ago
        > That is, while there is value in the items on the right, we value the items on the left more. The value of the items on the right (per the manifesto, if you disagree on the relative values that part can be debated) is lower than the value of the items on the left, but it is not zero or negative.
iso1631 5y ago
> So it's better than anarchy? Sometimes, but in my experience anarchy (which adds some business value, in a non specific way) is often better than waterfall (which adds none and actually hinders by preventing small quick schemes that add value now for the promise of value in years to come)
Jtsummers 5y ago
Anything that has feedback loops and responds to differences between reality and the plan by favoring reality. I have watched too many Waterfall proponents lead projects to failure because they were too stupid to acknowledge that reality had diverged from expectations. For software systems, specifically, also anything that encourages early integration. Integrate early, integrate often. A failure to do so means that you've broken your feedback loops or extended them to an arbitrary time in the future so that they have little to no value. You cannot properly verify and validate a system without integrating the major subsystems. Independent of most of the named processes and the technical discipline, V&V. Verification and validation are critical, ongoing activities that must be part of your work. This largely pushes towards automated testing, formal specs where applicable, and customer collaboration (to get validation of the system at critical junctures). Waterfall doesn't do any of those things or isolates them (like V&V). It only works on large scale systems if reality matches expectations, which is rare. My preference is to look towards Lean Software, most of the Agile methods, and the classical methods like Iterative & Incremental and Evolutionary (which were agile before Agile). V-Model is Waterfall-ish but integrates feedback into the system and makes V&V an ongoing activity. I prefer it paired with I&I or Evolutionary for critical systems (my primary domain).

A small team of smart people all working together with a shared goal, a clear vision, flexible roles, open communication with subject-matter experts, and a manager who acts as a shield against external forces (obsessive changes, design by committee) and as a provisioner of resources to the team?

mmarq 5y ago
Amen

cjfd 5y ago

Not much planning. Direct contact with the people who use the software. Good coding practices, preferably TDD. No time pressure. This is pretty much agile how it should be in theory but not in practice. Agile in theory is actually a very good development process. Agile in practice tends to be a bit worse. Waterfall always is the hell. My boyfriend is at the moment doing waterfall development. He hates it. So much useless paperwork.

aaaaaaaaaaab 5y ago
Yeah, that’s fine for developing the new landing page for the company website. Not so much for developing mission critical systems.
- cjfd 5y ago
  I disagree. Among the things that I listed was TDD. If one practices that consistently one can create highly reliable software. In fact one might argue that using TDD for the new landing page for the company website might be overkill. Maybe you do need a bit more planning for your 'mission critical system' in order to perhaps attain performance goals. However, I will tell you here and now that if you just do TDD for your mission critical system and you do it well you will already be better than most programming going on for so-called missions critical systems in many, many places.
  - iratewizard 5y ago
    TDD is cargo cult.
    - cjfd 5y ago
      It really is not. TDD is for highly competent programmers.
      - aaaaaaaaaaab 5y ago
        Lol, not really: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
    - dragonwriter 5y ago
      > TDD is cargo cult. No, but like any practice that becomes known of outside a narrow group of highly-competent, highly-motivated experts in the relevant area, TDD can be (and often is) cargo culted. It is thus often the case that people's only practical contact with “TDD” is with a cargo cult application of it.
      - cjfd 5y ago
        This is true. The most important way in which TDD can turn into a cargo cult practice is to test every class and every method separately. This then turns into the testing of implementation details that are very much subject to change. It can also lead to the testing of trivialities, like 'can the standard library of my language still add elements to a container'. One should in most cases write tests about somewhat higher level properties of a system where the user might actually recognize the tests as being about stuff that they value. In most cases one would write tests about a small set of closely related classes. There should also be tests about somewhat larger clusters but there should be fewer of them because they tend to be more brittle and have worse performance.
        mbrodersen 5y ago
yyyk 5y ago
TDD is an implicit repudiation of Agile. One of the principals of the original Agile manifesto was "working software over comprehensive documentation". After all, a test is a form of documentation, albeit one that is more suited to a programmer's tastes. Agile places software and documentation at opposition - TDD tries to tie them together.
- dragonwriter 5y ago
  > TDD is an implicit repudiation of Agile. TDD was developed in the 1990; Agile was articulated in 2001. Were they actually opposed, “Agile is a repudiation of TDD” would be more defensible. But your basic premise is wrong... > Agile places software and documentation at opposition No, the “X over Y” statements in the Manifesto aren't about opposition, they are about subordination. ”over” can be substituted with “should shape the use of” rather than “should exist instead of”
  - yyyk 5y ago
    You're right about the historical chronology, but TDD adoption IMHO came much later, after Agile exploded in popularity. Maybe it's just my neck of the woods, but I heard of TDD only much later. As for the "X over Y" statements, well, it's a rhetorical style which definitely creates an implicit opposition. Subordination makes no sense here. Our job and the business value is in working software, of course we want that most of all. Why mention it over something unless that something is in the way and we want to discourage it? Let's say I told people "Crossing the road over obsessively looking at both sides of the road"*, and kept referring to "obsessive looking" while barely mentioning people should look at all. As guidance this is horrible, for reasons I believe are obvious. If I said later "I only meant obsessive looking" and "you should adjust your crossing process so it suits you" it wouldn't make my advice right, would it now? * Documentation is of course much less necessary, I'm just taking an extreme example to show the rhetorical style.
    - Jtsummers 5y ago
      > That is, while there is value in the items on the right, we value the items on the left more. The value of the items on the right (per the manifesto, if you disagree on the relative values that part can be debated) is lower than the value of the items on the left, but it is not zero or negative.

iso1631 5y ago

> So it's better than anarchy? Sometimes, but in my experience anarchy (which adds some business value, in a non specific way) is often better than waterfall (which adds none and actually hinders by preventing small quick schemes that add value now for the promise of value in years to come)

Jtsummers 5y ago

Anything that has feedback loops and responds to differences between reality and the plan by favoring reality. I have watched too many Waterfall proponents lead projects to failure because they were too stupid to acknowledge that reality had diverged from expectations. For software systems, specifically, also anything that encourages early integration. Integrate early, integrate often. A failure to do so means that you've broken your feedback loops or extended them to an arbitrary time in the future so that they have little to no value. You cannot properly verify and validate a system without integrating the major subsystems. Independent of most of the named processes and the technical discipline, V&V. Verification and validation are critical, ongoing activities that must be part of your work. This largely pushes towards automated testing, formal specs where applicable, and customer collaboration (to get validation of the system at critical junctures). Waterfall doesn't do any of those things or isolates them (like V&V). It only works on large scale systems if reality matches expectations, which is rare. My preference is to look towards Lean Software, most of the Agile methods, and the classical methods like Iterative & Incremental and Evolutionary (which were agile before Agile). V-Model is Waterfall-ish but integrates feedback into the system and makes V&V an ongoing activity. I prefer it paired with I&I or Evolutionary for critical systems (my primary domain).