Comment by parasubvert | Hacker News Reader

Comment by parasubvert | Hacker News Reader

Parent Full thread

"Agile works for web services, for small apps, but that’s it. Anything larger, or more complex, needs planning, thought, and design. And often needs refactoring."

I hope you discover the flaw in this logic sooner in your career than later.

I'll start with a hint: You are misreading the Agile manifesto. All successful teams and companies - Agile or not - do planning, thought, design. And the Agile community (which came out of the Smalltalk community) also invented refactoring (in the disciplined sense, along with the first Refactoring IDE).

Here's another hint: very few actively run systems in financial markets/brokerages were written with a waterfall method since the mid 90s. Not all were developed with great agile either, but let's just say they were "incremental and iterative". These are complex systems. They're not designed for 8 months on paper.

"And in any serious development, where your code is going to run critical systems for decades, you can’t just work agile."

This is somewhat true, assuming you have stable requirements. But almost no software, even for complex systems, runs for decades without an update. It just doesn't happen anymore except in the most constrained environments (space exploration, signal/control systems in dark territory, etc.)

If your career trajectory is working for the military building weapons guidance systems, or an FDA manufacturer building blood pressure monitors, you also may come close to this ideal.

But note even companies in mission critical healthcare, like Philips, are adopting cloud, open source, and agile in their next-generation health management systems that integrate with their MRIs and CT scanners.

And I can tell you that even some cloud software, like the Elektronische Gesundheitskarte was developed with Waterfall.

Often you have to design software interacting with dozens of other entities, all who are going to write software interacting with your system.

And your system is supposed to be able to run for years or decades with minimal maintenance.

Agile is far more suited for web apps, or small mobile apps, which can be constantly updated.

Healthcare.gov was also a healthcare application developed waterfall style and was an enormous failure on launch day because of it's interactions with 3rd party systems.

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

And then imagine how every insurance would complain and how, after 2 or 3 months, everyone depending on healthcare.gov would have stopped supporting it because after the third rewrite of the parts of their software interacting with healthcare.gov’s API they’ve gone mad.

Every time you interact with third parties you have to provide stable interfaces.

> 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.

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.

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

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.

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.

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.

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

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

> 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.

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

This is not required by any Agile method that I have experienced. You can create a stable API and stick with it forever. If you know what you want/need.

"Every time you interact with third parties you have to provide stable interfaces."

Yes. Case in point, the Cloud Foundry APIs at http://apidocs.cloudfoundry.org are backwards compatible and stable behind a dozen or more agile projects. Changes are made continually on the codebase, but the API remains stable, so that interoperability is not broken as new features are added.

It's not required, but the average Agile project ends up with update support like Android, and with a complexity like the Facebook Android App (which had to rewrite dalvik at runtime because they didn't plan about the limits of the VM they were working on).

Having a plan is the first step to perfection, they say.

Agile has never said you don't plan, you just don't fully trust plans made without all the information. You make your plan, and its great as far as up front plans go, but it WILL be wrong in some ways, and you will update it.

Who ever said you don't plan in agile and scrum? Where does the magical backlog you start the project with come from?

The point is not to pretend you know things that you don't. You have a severly flawed interpretation of what agile means.

Agiles definition seems to get redefined every time a discussion like this appears on HN.

you seem to be mistaken about what Agile actually is.

i suggest reading the Agile manifesto [1] to get an understanding.

[1] http://www.agilemanifesto.org/principles.html

I commented on it before in a sibling comment.

Also, please link the actual manifesto, not the intention behind it.

And that can be paraphrased as "People over tools", "Documentation doesn’t matter as long as it works", "Who needs a contract? Just collaborate with the customer!", "Plans? Why? Just follow the latest trends!"

And I have to disagree with them in every single point.

Documentation > Working Software (as others then can write their software interacting with yours before you are done),

Contracts > collaboration (if you want me to stay longer to do something, expand the contract and pay me extra),

Plans > change (if you just follow trends without ever structuring your design, you’ll end up with lots of code and no single person understanding all of it)

http://www.agilemanifesto.org/

That is not Documentation that is Specification. How do you Document something that isn't built yet unless you have perfect foresight? Last I checked humans could not yet perfectly predict the future. Thus, the value of Working Software that can be interrogated and probed vs "Comprehensive Documentation" that may or may not be based on wishful prospection.

The Manifesto values Collaboration over "Contract Negotiation" leaving off the Negotiation part is a straw-man argument.

Similarly, "Responding to Change" it is not the Change that the Manifesto values it is "Responding to Change". What it values "Responding to Change" over is "Following a Plan" not making a plan or doing any planning.

Usually, you can decide on structure of code before implementing it. You can even have tests up and running before implementing it.

And in many cases this actually works.

You can do agile test first too.

"hey here's a feature we're pretty sure we need:

As a foo, I need to bar, So that baz

okay, write the test, make the test pass, refactor"

What about that isn't possible in agile?

Actually that is incorrect. The Elektronische Gesundheitskarte was developed with "V-Modell". V-Modell, now V-Modell XT is the mandatory process for projects run by the german government.

Which is an expansion of Waterfall. https://upload.wikimedia.org/wikipedia/commons/e/e8/Systems_...

If you read the description of v-modell carefully, you would have realized that v-modell isnt a strict process and does not define in which order certain steps have to be made.

Before tailoring (which can be used to create an agile process as much as waterfall btw) it just tells you WHAT has to be done and not HOW it has to be done. The order and iterations of each step is defined during the tailoring step.

Reply on news.ycombinator.com