23 ms·

Software Methodology: Why One Size Fits No One

211 points by bobm_kite9 8y ago

bobm_kite9 8y ago
Hi, Author here. This is a single page from the larger "Risk-First" project, about risk in software projects. I put the front page up a week or so ago and it was fairly well-received. Hopefully people will enjoy a festive second-helping. Feel free to ask anything.
- walterbell 8y ago
  Much needed effort, thanks. How do you see the ongoing relationship between the book and multi-contributor website? How did that influence the selection of an Apache 2 (intended for code) vs CC-BY (intended for content) license?
  - bobm_kite9 8y ago
    That's an excellent question, and one I'm currently struggling with. On the one hand, I would like to grow Risk-First as a community, and get other people authoring articles. With this in mind, I am trying to automate the process by which collaborators are added to the github organisation... it's manual at the moment which is already painful. On the other hand, I wanted to publish this work in order that it could be read off-line (in print form, should be ready end of Feb) or on a kindle (which is currently pre-order). This _probably_ won't generate much income as it essentially is content that is already for free on the website. Probably, the license is sufficiently permissive that other people could also publish the work as a book for their own means, so long as they retained attribution or copyright notices. I guess this is the usual quandary on making anything open-source. I expect you're right that the license _should be_ CC-BY. I need to investigate further on this. Do you have any further thoughts on this?
    - walterbell 8y ago
      CC licenses have been vetted by content publishing lawyers in many countries. CC-BY 4.0 enables commercial re-use. The Apache license was designed to manage software specific risks. For the book, you can have a few chapters which are proprietary, clearly marked as such in the book, with the CC chapters explicitly identified. That allows anyone to republish/derive the CC chapters, but not the proprietary chapters. There might be a natural separation between community-authored content and your analysis/perspective chapters. CC-BY 4.0 also allows derivatives of the community content to be proprietary, so the entire book can remain commercial. There are other CC licenses (share-alike) which have GPL-like qualities. It depends on which outcomes you want to incentivize, and how much effort you want to put into management of content origin, derivatives and/or issuing DMCA takedown notices to Amazon. For revenue models, look at softcover.io, which provides free-to-read content with upsells to paid ebook and video. It has generated several hundred $K for the Ruby on Rails tutorial. The author has previously posted about this on HN.
      - bobm_kite9 8y ago
        That's very helpful advice, thanks a lot.
- Ngunyan 8y ago
  I like the images. What was used to create that?
- zenogais 8y ago
  Initial thought. This reads largely like a recapitulation of Boehm's 2003 book "Balance Agility and Discipline" [1]. Have you read this and did this provide any inspiration for the article? [1]: https://www.amazon.com/Balancing-Agility-Discipline-Guide-Perplexed/dp/0321186125 https://www.amazon.com/Balancing-Agility-Discipline-Guide-Pe...
  - deleted 8y ago
    [deleted]
  - bobm_kite9 8y ago
    I haven’t read it but I’ll put it on my reading list, thanks.
- KineticLensman 8y ago
  I totally agree with the 'Risk-first' approach. This idea fits in very nicely with risk driven technical assurance, where the goal of project reviews (even including those covering pre-project activities such as bidding) is to quantify and mitigate the risk to the business. Such assurance provides an outer shell for engineering activities such as software development.
ll918 8y ago
Seems like bigger risk is people not following methodologies properly in the first place. At least that’s my experience
- GuB-42 8y ago
  Mine too. It can take the form of useless meetings. ex: Oh, stand up meetings sound good, but what are we going to talk about? Only keeping the cheap aspects. Ex: not doing formal test campaigns based on previously defined requirements but forgetting about things like pair programming in XP, up to date automated unit tests, etc...
  - chaosite 8y ago
    That problem is called cargo-culting. You copy the outwards appearances, not understanding the underlying motives, yet expect the same results.
- Pica_soO 8y ago
  That sounds very much, like a no-true-socialism fallacy played via the bank of the table. If your ideology/methodology cant be implemented with the people you got, maybe its badly designed?
- galangalalgol 8y ago
  When enough people misuse a methodology it is a comment against the methodology. Trying to use process to replace accountability usually fails.
  - Nasrudith 8y ago
    I don't see how that follows neccessary - the majority of people aren't able to perform calculus but that doesn't mean there is something wrong with it. Granted it is a matter of where it is expected to be applied and by who. Expecting an artillery gunner to do advanced math calculations from the back lines is fine if not ideal compared to computerization. Expecting a grunt under fire to do so to use his rifle is not no mattet how accurate it would wind up.
choonway 8y ago
Methodologies are just like Martial Arts Types - you have so many varieties to choose from Boxing, TKD, Judo, Muay Thai But in a real fight, you hit with whatever you can grab onto :)
- bobm_kite9 8y ago
  Haha nice, brings to mind the Mike Tyson quote: "Everyone has a plan 'till they get punched in the mouth."
  - keypusher 8y ago
    Extensive and rather interesting discussion on variations of the theme "No plan survives contact with the enemy" can be found in military writings going back centuries. An overview is linked below. https://bootcampmilitaryfitnessinstitute.com/military-and-outdoor-fitness-articles/no-plan-survives-contact-with-the-enemy/ https://bootcampmilitaryfitnessinstitute.com/military-and-ou...
  - chiefalchemist 8y ago
    Yeah. Great quote. The key it seems, is the team agreeing there's going to be a punch in the mouth, accept that, stick together (i.e., don't panic), find a solution and continue (til the next painful punch). The plan can change, the process for considering change should not. The arc of my point is that the methodology matters (kinda), but more importantly it's that everyone agrees to what the process is and sticks to it. Without such dedication and consistency the methodology doesn't matter, you're gonna come up short.
  - 725686 8y ago
    I'd rather go with Eisenhower's "... plans are useless but planning is indispensable".
- TheAceOfHearts 8y ago
  AFAIK, when they were all made to compete against each other in MMA it quickly became obvious that Brazilian jiu-jitsu was top dog. Although modern MMA definitely takes in the best techniques from each martial arts style. Is agile the Brazilian jiu-jitsu of software development?
lordnacho 8y ago
IMO the problem with software methodologies is leaky abstraction. There just isn't a general framework that tells you how to categorize and deal with every issue that you come up with. The main thing I get from the various methodologies is general philosophies. Things like "try to get feedback incorporated quickly". Or "Identify in advance the things that are expensive to change".
- aswanson 8y ago
  Software in the abstract problem solving against varying constraints. It stands to reason there would not be a single method that capture the best means of doing so.
- pytester 8y ago
  I kind of wish we applied "micro-methodologies" rather than methodologies. I think we should be doing "import retrospectives" rather than "import scrum" and sharing and experimenting with a diversity of approaches (e.g. various different ways to do retros). We're essentially treating "methodologies" as software that runs teams. Furthermore, if we are doing software we should follow the UNIX philosophy and the bazaar rather than the cathedral. Edit : I kind of want to make this a reality now. I've registered http://micromethodology.com http://micromethodology.com and will make it so micromethodology.com/standup can be a place to share "how we do [x variant] standups" via pull requests on https://github.com/hitchdev/micromethodology.com https://github.com/hitchdev/micromethodology.com
mml 8y ago
XP wasn't a set of practices, or methodology, it was a set of principles. "Value working software" etc. The "methodology" flows from there: only do the things that help support the principles, get rid of everything else you can (up to and including many of the scrum rituals/meetings).
commandlinefan 8y ago
Regardless of intent or documentation, I’ve never come across a methodology that didn’t devolve into the same practice as every other methodology. The root problem is that the people who are looking for a methodology/silver bullet are convinced — and no amount of reality will ever convince them otherwise — that software development can be done with 100% predictability, just like, say, adding a garage to a house. So even XP, that explicitly states up front that this is not possible in software, gets morphed into “agile” which is actually a great way to manage predictable development tasks, but a horrible way to manage software.
- blowski 8y ago
  XP is a type of agile anyway. Perhaps you meant it morphs into scrum?
- karmakaze 8y ago
  There is a move away from the capital 'A'gile processes in use with agile as an adjective to describe how you approach problems and the development process itself should be fluid.
  - ChrisSD 8y ago
    Which is what agile started as and was in fact the whole point. It's like we're forever going in methodology circles: One size doesn't fit all so we should make the development process more fluid. Hey what a great idea! Here are some fluid methodologies I just came up with. Woah this methodology is awesome; everybody should use it! One size doesn't fit all so...
    - karmakaze 8y ago
      So the answer seems to be use agile to find a fit, or if that doesn't fit other organizational requirements/abilities, then choose the least poorly fitting process.
  - dragonwriter 8y ago
    You mean, a move to exactly what the Agile Manifesto calls for. Well, that took long enough.
pmb 8y ago
"Characterizing People as First-Order, Non-Linear Components in Software Development" knew why in 1999.
karmakaze 8y ago
> Following a software methodology is therefore an act of trust That's the key point from my reading. After working with the same people on multiple products at a startup, I came to trust the product research and design steps preceding development and the marketing and customer success. Even if not wholly believing, I at least came to the conclusion that it was closer to an efficient process than I could come up with.
Anka33 8y ago
PDD is the best methodology. (Panic Driven Development/Design)
vertline3 8y ago
I like just programming.
- the_arun 8y ago
  +1
olooney 8y ago
Here is a (tongue-in-cheek) model I've developed. It's based on the observation that teams who were basically competent and had an overabundance of hard technical skills reliably delivered, while teams where hard skills were rather thin on the ground could not deliver. To avoid this degenerating into the tautology "only teams that can develop software can development software" let's develop the idea a little bit: Definition: A team member is "garage competent" if, when locked in a garage with a computer and an internet connection (but without help or advice from other team members,) he or she could deliver some working version of the product single handed, given sufficient time. The model's prediction is just this: if the number of garage competent team members is greater than the number of other team members, then the project will be delivered. Otherwise, the project will fail. (In this simple version of the model described above, simple majority serves as a proxy for control of the project. A more nuanced but harder to define model would define "control of a project" as a weighted sum over team members taking into account the leverage of different assigned role such as PM or architect.) I posit this is not just a highly predictive model, but in fact the causal mechanism project failure: Once people who are not "garage competent" are in control, they make reliably make decisions that will ultimately doom the project. Try it out yourself: think of a historical project where you know the outcomes and can estimate garage competence for each team member and see if it makes the correct prediction.
- avip 8y ago
  My methodology is something of a corollary: the secret of successfully delivering an (admittedly simple) sw product is to minimize the connectivity of the delivery network. The principle is simple: for small projects, the drag introduced by elements of broken communication outweighs the potential benefits of adding working nodes. So if we need to "build a web app", the ideal setup is to find someone who's an ok designer, ok coder, ok devops, and ok at asking customers what the hell they need the thing to do (PM?). If that fails, the next-ideal setup is 2 people working independently on aspects as far as possible from each other.
  - peterwwillis 8y ago
    Your methodology is to either lean on rock stars or have people not work together?
samirm 8y ago
gross misuse of the term "methodology"
oldpond 8y ago
"Software methodologies are all about handling risk." Not even close. Methodologies should about creating working software with a short feedback loop between customer and engineer. That old blue cool-aid about risk doesn't fly anymore.
peterwwillis 8y ago
This whole risk-world-view thing is depressing. Yes, technically the entirety of life on this planet is managing risk. I eat food and breathe air to manage the risk of dying from not doing so. The quality and amount of the food and the air determine the risk factor. Am I really going to choose the food I eat and the air I breathe based solely on risk? Or maybe, I dunno, eat the food that tastes good and breathe air that smells clean? Really, all of this is bullshit, because the reason we sometimes fail to deliver software projects is humans really suck ass at dealing with complexity. We can deal with one complex thing at a time, but once multiples of them are all being considered at once, we just screw up constantly. I think the way to pick any methodology is really deceptively simple: 1) look around and see if most of you are experienced at a given methodology, and then 2) use it. I think it's that second part that people screw up on.
- bobm_kite9 8y ago
  I agree, maybe it does _sound_ depressing. But the food you eat and air you breathe _are_ based on risk! Our bodies try to warn us about the bad air and food by making it smell/taste bad. You can go ahead and eat it if you want! I agree with you that it's nice that our bodies make things _nice_ to eat as well as recognising nasty stuff. I wonder if there is an evolutionary reason for that too... Sadly, there are still some things that _don't_ taste bad but will kill you... hidden risks of eating I guess. I talk about Complexity Risk here: https://github.com/risk-first/website/wiki/Complexity-Risk https://github.com/risk-first/website/wiki/Complexity-Risk Often, Complexity is fine, but then something bites you in the ass unexpectedly. Sounds like risk to me.
jmull 8y ago
> ... But Replace Judgement Well, that's not true. A software development methodology doesn't replace judgement. If you try to make one do so, you're probably going to end up with a mess regardless.

211 points by bobm_kite9 8y ago

Hi, Author here. This is a single page from the larger "Risk-First" project, about risk in software projects. I put the front page up a week or so ago and it was fairly well-received. Hopefully people will enjoy a festive second-helping. Feel free to ask anything.

walterbell 8y ago
Much needed effort, thanks. How do you see the ongoing relationship between the book and multi-contributor website? How did that influence the selection of an Apache 2 (intended for code) vs CC-BY (intended for content) license?
- bobm_kite9 8y ago
  That's an excellent question, and one I'm currently struggling with. On the one hand, I would like to grow Risk-First as a community, and get other people authoring articles. With this in mind, I am trying to automate the process by which collaborators are added to the github organisation... it's manual at the moment which is already painful. On the other hand, I wanted to publish this work in order that it could be read off-line (in print form, should be ready end of Feb) or on a kindle (which is currently pre-order). This _probably_ won't generate much income as it essentially is content that is already for free on the website. Probably, the license is sufficiently permissive that other people could also publish the work as a book for their own means, so long as they retained attribution or copyright notices. I guess this is the usual quandary on making anything open-source. I expect you're right that the license _should be_ CC-BY. I need to investigate further on this. Do you have any further thoughts on this?
  - walterbell 8y ago
    CC licenses have been vetted by content publishing lawyers in many countries. CC-BY 4.0 enables commercial re-use. The Apache license was designed to manage software specific risks. For the book, you can have a few chapters which are proprietary, clearly marked as such in the book, with the CC chapters explicitly identified. That allows anyone to republish/derive the CC chapters, but not the proprietary chapters. There might be a natural separation between community-authored content and your analysis/perspective chapters. CC-BY 4.0 also allows derivatives of the community content to be proprietary, so the entire book can remain commercial. There are other CC licenses (share-alike) which have GPL-like qualities. It depends on which outcomes you want to incentivize, and how much effort you want to put into management of content origin, derivatives and/or issuing DMCA takedown notices to Amazon. For revenue models, look at softcover.io, which provides free-to-read content with upsells to paid ebook and video. It has generated several hundred $K for the Ruby on Rails tutorial. The author has previously posted about this on HN.
    - bobm_kite9 8y ago
      That's very helpful advice, thanks a lot.
Ngunyan 8y ago
I like the images. What was used to create that?
zenogais 8y ago
Initial thought. This reads largely like a recapitulation of Boehm's 2003 book "Balance Agility and Discipline" [1]. Have you read this and did this provide any inspiration for the article? [1]: https://www.amazon.com/Balancing-Agility-Discipline-Guide-Perplexed/dp/0321186125 https://www.amazon.com/Balancing-Agility-Discipline-Guide-Pe...
- deleted 8y ago
  [deleted]
- bobm_kite9 8y ago
  I haven’t read it but I’ll put it on my reading list, thanks.
KineticLensman 8y ago
I totally agree with the 'Risk-first' approach. This idea fits in very nicely with risk driven technical assurance, where the goal of project reviews (even including those covering pre-project activities such as bidding) is to quantify and mitigate the risk to the business. Such assurance provides an outer shell for engineering activities such as software development.

ll918 8y ago

Seems like bigger risk is people not following methodologies properly in the first place. At least that’s my experience

GuB-42 8y ago
Mine too. It can take the form of useless meetings. ex: Oh, stand up meetings sound good, but what are we going to talk about? Only keeping the cheap aspects. Ex: not doing formal test campaigns based on previously defined requirements but forgetting about things like pair programming in XP, up to date automated unit tests, etc...
- chaosite 8y ago
  That problem is called cargo-culting. You copy the outwards appearances, not understanding the underlying motives, yet expect the same results.
Pica_soO 8y ago
That sounds very much, like a no-true-socialism fallacy played via the bank of the table. If your ideology/methodology cant be implemented with the people you got, maybe its badly designed?
galangalalgol 8y ago
When enough people misuse a methodology it is a comment against the methodology. Trying to use process to replace accountability usually fails.
- Nasrudith 8y ago
  I don't see how that follows neccessary - the majority of people aren't able to perform calculus but that doesn't mean there is something wrong with it. Granted it is a matter of where it is expected to be applied and by who. Expecting an artillery gunner to do advanced math calculations from the back lines is fine if not ideal compared to computerization. Expecting a grunt under fire to do so to use his rifle is not no mattet how accurate it would wind up.

choonway 8y ago

Methodologies are just like Martial Arts Types - you have so many varieties to choose from Boxing, TKD, Judo, Muay Thai But in a real fight, you hit with whatever you can grab onto :)

bobm_kite9 8y ago
Haha nice, brings to mind the Mike Tyson quote: "Everyone has a plan 'till they get punched in the mouth."
- keypusher 8y ago
  Extensive and rather interesting discussion on variations of the theme "No plan survives contact with the enemy" can be found in military writings going back centuries. An overview is linked below. https://bootcampmilitaryfitnessinstitute.com/military-and-outdoor-fitness-articles/no-plan-survives-contact-with-the-enemy/ https://bootcampmilitaryfitnessinstitute.com/military-and-ou...
- chiefalchemist 8y ago
  Yeah. Great quote. The key it seems, is the team agreeing there's going to be a punch in the mouth, accept that, stick together (i.e., don't panic), find a solution and continue (til the next painful punch). The plan can change, the process for considering change should not. The arc of my point is that the methodology matters (kinda), but more importantly it's that everyone agrees to what the process is and sticks to it. Without such dedication and consistency the methodology doesn't matter, you're gonna come up short.
- 725686 8y ago
  I'd rather go with Eisenhower's "... plans are useless but planning is indispensable".
TheAceOfHearts 8y ago
AFAIK, when they were all made to compete against each other in MMA it quickly became obvious that Brazilian jiu-jitsu was top dog. Although modern MMA definitely takes in the best techniques from each martial arts style. Is agile the Brazilian jiu-jitsu of software development?

lordnacho 8y ago

IMO the problem with software methodologies is leaky abstraction. There just isn't a general framework that tells you how to categorize and deal with every issue that you come up with. The main thing I get from the various methodologies is general philosophies. Things like "try to get feedback incorporated quickly". Or "Identify in advance the things that are expensive to change".

aswanson 8y ago
Software in the abstract problem solving against varying constraints. It stands to reason there would not be a single method that capture the best means of doing so.
pytester 8y ago
I kind of wish we applied "micro-methodologies" rather than methodologies. I think we should be doing "import retrospectives" rather than "import scrum" and sharing and experimenting with a diversity of approaches (e.g. various different ways to do retros). We're essentially treating "methodologies" as software that runs teams. Furthermore, if we are doing software we should follow the UNIX philosophy and the bazaar rather than the cathedral. Edit : I kind of want to make this a reality now. I've registered http://micromethodology.com http://micromethodology.com and will make it so micromethodology.com/standup can be a place to share "how we do [x variant] standups" via pull requests on https://github.com/hitchdev/micromethodology.com https://github.com/hitchdev/micromethodology.com

mml 8y ago

XP wasn't a set of practices, or methodology, it was a set of principles. "Value working software" etc. The "methodology" flows from there: only do the things that help support the principles, get rid of everything else you can (up to and including many of the scrum rituals/meetings).

commandlinefan 8y ago

Regardless of intent or documentation, I’ve never come across a methodology that didn’t devolve into the same practice as every other methodology. The root problem is that the people who are looking for a methodology/silver bullet are convinced — and no amount of reality will ever convince them otherwise — that software development can be done with 100% predictability, just like, say, adding a garage to a house. So even XP, that explicitly states up front that this is not possible in software, gets morphed into “agile” which is actually a great way to manage predictable development tasks, but a horrible way to manage software.

blowski 8y ago
XP is a type of agile anyway. Perhaps you meant it morphs into scrum?
karmakaze 8y ago
There is a move away from the capital 'A'gile processes in use with agile as an adjective to describe how you approach problems and the development process itself should be fluid.
- ChrisSD 8y ago
  Which is what agile started as and was in fact the whole point. It's like we're forever going in methodology circles: One size doesn't fit all so we should make the development process more fluid. Hey what a great idea! Here are some fluid methodologies I just came up with. Woah this methodology is awesome; everybody should use it! One size doesn't fit all so...
  - karmakaze 8y ago
    So the answer seems to be use agile to find a fit, or if that doesn't fit other organizational requirements/abilities, then choose the least poorly fitting process.
- dragonwriter 8y ago
  You mean, a move to exactly what the Agile Manifesto calls for. Well, that took long enough.

pmb 8y ago

"Characterizing People as First-Order, Non-Linear Components in Software Development" knew why in 1999.

karmakaze 8y ago

> Following a software methodology is therefore an act of trust That's the key point from my reading. After working with the same people on multiple products at a startup, I came to trust the product research and design steps preceding development and the marketing and customer success. Even if not wholly believing, I at least came to the conclusion that it was closer to an efficient process than I could come up with.

Anka33 8y ago

PDD is the best methodology. (Panic Driven Development/Design)

vertline3 8y ago

I like just programming.

the_arun 8y ago
+1

olooney 8y ago

Here is a (tongue-in-cheek) model I've developed. It's based on the observation that teams who were basically competent and had an overabundance of hard technical skills reliably delivered, while teams where hard skills were rather thin on the ground could not deliver. To avoid this degenerating into the tautology "only teams that can develop software can development software" let's develop the idea a little bit: Definition: A team member is "garage competent" if, when locked in a garage with a computer and an internet connection (but without help or advice from other team members,) he or she could deliver some working version of the product single handed, given sufficient time. The model's prediction is just this: if the number of garage competent team members is greater than the number of other team members, then the project will be delivered. Otherwise, the project will fail. (In this simple version of the model described above, simple majority serves as a proxy for control of the project. A more nuanced but harder to define model would define "control of a project" as a weighted sum over team members taking into account the leverage of different assigned role such as PM or architect.) I posit this is not just a highly predictive model, but in fact the causal mechanism project failure: Once people who are not "garage competent" are in control, they make reliably make decisions that will ultimately doom the project. Try it out yourself: think of a historical project where you know the outcomes and can estimate garage competence for each team member and see if it makes the correct prediction.

avip 8y ago
My methodology is something of a corollary: the secret of successfully delivering an (admittedly simple) sw product is to minimize the connectivity of the delivery network. The principle is simple: for small projects, the drag introduced by elements of broken communication outweighs the potential benefits of adding working nodes. So if we need to "build a web app", the ideal setup is to find someone who's an ok designer, ok coder, ok devops, and ok at asking customers what the hell they need the thing to do (PM?). If that fails, the next-ideal setup is 2 people working independently on aspects as far as possible from each other.
- peterwwillis 8y ago
  Your methodology is to either lean on rock stars or have people not work together?

samirm 8y ago

gross misuse of the term "methodology"

oldpond 8y ago

"Software methodologies are all about handling risk." Not even close. Methodologies should about creating working software with a short feedback loop between customer and engineer. That old blue cool-aid about risk doesn't fly anymore.

peterwwillis 8y ago

This whole risk-world-view thing is depressing. Yes, technically the entirety of life on this planet is managing risk. I eat food and breathe air to manage the risk of dying from not doing so. The quality and amount of the food and the air determine the risk factor. Am I really going to choose the food I eat and the air I breathe based solely on risk? Or maybe, I dunno, eat the food that tastes good and breathe air that smells clean? Really, all of this is bullshit, because the reason we sometimes fail to deliver software projects is humans really suck ass at dealing with complexity. We can deal with one complex thing at a time, but once multiples of them are all being considered at once, we just screw up constantly. I think the way to pick any methodology is really deceptively simple: 1) look around and see if most of you are experienced at a given methodology, and then 2) use it. I think it's that second part that people screw up on.

bobm_kite9 8y ago
I agree, maybe it does _sound_ depressing. But the food you eat and air you breathe _are_ based on risk! Our bodies try to warn us about the bad air and food by making it smell/taste bad. You can go ahead and eat it if you want! I agree with you that it's nice that our bodies make things _nice_ to eat as well as recognising nasty stuff. I wonder if there is an evolutionary reason for that too... Sadly, there are still some things that _don't_ taste bad but will kill you... hidden risks of eating I guess. I talk about Complexity Risk here: https://github.com/risk-first/website/wiki/Complexity-Risk https://github.com/risk-first/website/wiki/Complexity-Risk Often, Complexity is fine, but then something bites you in the ass unexpectedly. Sounds like risk to me.

jmull 8y ago

> ... But Replace Judgement Well, that's not true. A software development methodology doesn't replace judgement. If you try to make one do so, you're probably going to end up with a mess regardless.