5 ms·

The manifesto emphasises the importance of sharing the values of a method, before actually applying the method. It's the difference between wisdom and dogma. Ta

The manifesto emphasises the importance of sharing the values of a method, before actually applying the method. It's the difference between wisdom and dogma. Take tests for example: blindly going for coverage metrics will be much less effective compared to having a deep, shared understanding of the pro's and con's of testing. To know that your co-workers have a similar understanding of the methodologies, makes the methodology itself of lesser (or no) importance. Personally, I am of the opinion that a strong emphasis on test-driven development in the long run will cause waterfall-style development. Tests are all about risk-prevention, instead of risk-mitigation. Prevention eventually becomes exceedingly expensive, whereas mitigation is all about building robustness into the running system. Due to that, the scalability of mitigation systems, such as true micro-services or actor-systems, are inherently more dynamic and cause less latency in development. I don't understand your last statement. It seems to confirm my position: "... anybody who sits down is shouted at ... ". The process (standing up, not sitting down) is less important than good team dynamics (not getting shouted at). (edit: down-voters, please share why you down-vote! I'd like to know. Also, please don't down-vote based on opinion, but on weakness of argumentation instead.)

tome 9y ago
> edit: down-voters, please share why you down-vote! The one thing that I religiously downvote on HN is complaints about down votes.
- edejong 9y ago
  Well, at least I now know why you down-voted :) Sometimes I ask because I feel a comment was properly written, non-offensive and with reasonable argumentation. I put time and effort into finding the right words and thought through my argumentation multiple times before writing it down. Since English is not my mother-tongue, I'd like to know if i caused a possible misunderstanding. Hopefully others share my belief that down-voting should be reserved to punish abusive behaviour.
  - tome 9y ago
    I understand the desire for an explanation but more often than not in my experience a comment that has quickly been downvoted to in a fit of follow-the-leader will soon be voted back up into positive territory. You just have to be patient :)
- jrs235 9y ago
  I usually only down vote people who begin or include 'i know I'm going to get down voted...' in their original post. If someone edits asking for explanation I usually give them leeway... It tells me they are monitoring the conversation and willing to engage thoughtfully.
jrs235 9y ago
I think you are getting down voted for questioning TDD. TDD seems to be another religion. You're insulting a sacred cow for some. Anyways, I would really like the avenue of thought you've planted in me to flesh out: risk prevention vs mitigation and how it applies to software development.
crdoconnor 9y ago
>Take tests for example: blindly going for coverage metrics will be much less effective... I agree. However, this is about tools and processes, so it's not really relevant to my argument, which is that you shouldn't explicitly deprioritize tools and processes. >I don't understand your last statement. I'm making fun of people who cargo cult 'agile'. Actually standing up is the least important feature of stand ups. Sitting down during a stand up and seeing people's reactions is is a good litmus test. It highlights those people who put a great emphasis on non-functional rituals.
- jrs235 9y ago
  > you shouldn't explicitly deprioritize tools and processes Is it fairly safe to say that the goal of most [software] companies isn't to just make good software or to develop [good] software fast but to find a repeatable process to make good software quickly? And this is why tools and processes are still needed.
- edejong 9y ago
  I was trying to convey that fostering an environment within which tools and methodologies can be understood for their specific merits is more important than the tools and methodologies themselves. Or: a tool shouldn't be a crutch, but a training aid. At least, that's how I interpret it. Obviously, the true spirit of the agile manifesto is the non-prescriptive, ambiguous wording. Unfortunately, 'scrum' has come to be known as 'agile', which I think is an unfortunate consequence of all the cargo-culting going on. Rituals are fine, as long as they have any depth and identity to them. The Scrum rituals are shallow, simplistic and feeble. Without identity it is no wonder many participant want them to be over as soon as possible...
  - crdoconnor 9y ago
    I'll agree that the manifesto is vague enough that you could reinterpret it your way. However, its inimical vagueness is hardly a point in its favor, since all that means is that people project whatever meaning that they really want on to it. Meaning that it has very little meaning. But it still strongly implies that tools basically don't matter, and I've worked on teams where people did choose to interpret it that way, which ironically led to waterfalling...

tome 9y ago

> edit: down-voters, please share why you down-vote! The one thing that I religiously downvote on HN is complaints about down votes.

edejong 9y ago
Well, at least I now know why you down-voted :) Sometimes I ask because I feel a comment was properly written, non-offensive and with reasonable argumentation. I put time and effort into finding the right words and thought through my argumentation multiple times before writing it down. Since English is not my mother-tongue, I'd like to know if i caused a possible misunderstanding. Hopefully others share my belief that down-voting should be reserved to punish abusive behaviour.
- tome 9y ago
  I understand the desire for an explanation but more often than not in my experience a comment that has quickly been downvoted to in a fit of follow-the-leader will soon be voted back up into positive territory. You just have to be patient :)
jrs235 9y ago
I usually only down vote people who begin or include 'i know I'm going to get down voted...' in their original post. If someone edits asking for explanation I usually give them leeway... It tells me they are monitoring the conversation and willing to engage thoughtfully.

jrs235 9y ago

I think you are getting down voted for questioning TDD. TDD seems to be another religion. You're insulting a sacred cow for some. Anyways, I would really like the avenue of thought you've planted in me to flesh out: risk prevention vs mitigation and how it applies to software development.

crdoconnor 9y ago

>Take tests for example: blindly going for coverage metrics will be much less effective... I agree. However, this is about tools and processes, so it's not really relevant to my argument, which is that you shouldn't explicitly deprioritize tools and processes. >I don't understand your last statement. I'm making fun of people who cargo cult 'agile'. Actually standing up is the least important feature of stand ups. Sitting down during a stand up and seeing people's reactions is is a good litmus test. It highlights those people who put a great emphasis on non-functional rituals.

jrs235 9y ago
> you shouldn't explicitly deprioritize tools and processes Is it fairly safe to say that the goal of most [software] companies isn't to just make good software or to develop [good] software fast but to find a repeatable process to make good software quickly? And this is why tools and processes are still needed.
edejong 9y ago
I was trying to convey that fostering an environment within which tools and methodologies can be understood for their specific merits is more important than the tools and methodologies themselves. Or: a tool shouldn't be a crutch, but a training aid. At least, that's how I interpret it. Obviously, the true spirit of the agile manifesto is the non-prescriptive, ambiguous wording. Unfortunately, 'scrum' has come to be known as 'agile', which I think is an unfortunate consequence of all the cargo-culting going on. Rituals are fine, as long as they have any depth and identity to them. The Scrum rituals are shallow, simplistic and feeble. Without identity it is no wonder many participant want them to be over as soon as possible...
- crdoconnor 9y ago
  I'll agree that the manifesto is vague enough that you could reinterpret it your way. However, its inimical vagueness is hardly a point in its favor, since all that means is that people project whatever meaning that they really want on to it. Meaning that it has very little meaning. But it still strongly implies that tools basically don't matter, and I've worked on teams where people did choose to interpret it that way, which ironically led to waterfalling...