[dragonwriter]

> And now imagine Healthcare.gov was Agile and its API would change every month completely.

Most methods that get the "agile" label attached to them focus on managing change by organizing work in such a way that, outside of externally driven changes that the organization can't control (which have the same effect regardless of development method) the parts that are done don't change much after they are released, to avoid widespread breaking changes.

So I don't see the point here, or how it connects to Agile.

[kuschku]

If the parts that are done don’t change much, it’s not Agile.

Agile is if no piece of your software can ever be called "done" because you are constantly changing things to be able to react to the market, as the market always changes.

If your software has clear requirements, has a point when it is done, and only requires minimum maintenance after that, you aren’t writing agile.

[dragonwriter]

> If the parts that are done don’t change much, it’s not Agile.

Most agile methods focus on prioritizing the parts that are both most certain and highest value for the cost as a way of managing requirements uncertainty.

> Agile is if no piece of your software can ever be called "done" because you are constantly changing things to be able to react to the market, as the market always changes.

One of the aspects of uncertainty many agile methods address is change in market, sure; that doesn't mean that every piece of the software is changing all the time, it means that those methods focus on having mechanisms available that are intended so that when market changes create a need for changes in the software, that change can be implemented on a timely, efficient basis.

[arclyte]

"You keep using that word. I do not think it means what you think it means." - Inigo Montoya, The Princess Bride

[kuschku]

I am using the definition from agilemanifesto.org, which argues that "change" is more important than planning what you actually want to do. Or that "it works" is more important than documenting it.

[arclyte]

I think you're taking Agile as defined in the manifesto out of context a bit too much and making it sound more like a religion (which, if you did, you would probably not be alone in doing).

Agile only makes complete sense when you take it in its historical context as a reaction to other methods, not as a standalone methodology with no history that sprang wholesale from the ground. It's not "this sounds good, let's try this", it's "we tried the other way and it did not work, we need to do something different".

Saying that you have something that works (an MVP, for instance) is _more important than_ documentation. That doesn't mean you shouldn't have documentation. Documentation will always lag behind actual code unless someone is full time updating documentation, which I have yet to see happen anywhere.

And even if you have documentation - it is an agreed communication of intent. The problem is, not everyone is necessarily reading it in the same way, or communicating their intent very well, or realizing inconsistencies and hurdles in what they've communicated. So when you actually have to write the software - you find you can't do it the way it was proposed, the way it was proposed is less efficient or fault tolerant, conflicts with other parts of the design, or is just ambiguous in a way that causes the developer to code up something other than was intended.

In a waterfall design, you wouldn't find out about the ambiguous bits until you present it to the client - at the end of the cycle when it's quite possibly already too late. In an iterative development cycle you can get constant feedback and more easily react to change. That's what agile is really all about.

Change is inevitable - agile attempts to recognize this fact and work as quickly as possible to create a product and immediately and incrementally improve upon it, keeping things moving forward, rather than spending huge amounts of time fussing over details that maybe won't make it into the final product while missing huge discrepancies or 'unknown unknowns' that aren't well understood until something is actually written.

[arclyte]

http://www.computerworld.co.nz/article/457007/agile_great_do...

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/2012001...

[mixmastamyk]

The problem that you argue is not a problem in reality.

When breaking changes are made to an API, the version number is simply incremented. It is up to requirements to decide how long older APIs will be supported.