Hacker News Reader

Comment by vannevar | Hacker News Reader

This is a poor argument. The first three "myths" in the article are all straw-men. First, Agile isn't a design process, it's an implementation process. How you arrive at those user stories is up to you, and nothing in Agile proscribes using OOD, SOLID, patterns, or any other software design process your heart desires. And please show me the Agile article that says that you should constantly refactor working code, or that technical debt should be accumulated freely because it can always be repaid. Myth #4 might make the basis of a good article (and has), but it hardly means the end of agile to suggest that just blindly following agile rituals doesn't guarantee agility.

View on HN

Show me where in the agile manifesto ANY process is recommended: http://agilemanifesto.org/

This is the entirety of the issue. Once one refers to it as a process their entire argument is flawed.

I may be misinterpreting where you're coming from, but I'll give it a shot:

"Individuals and interactions over processes and tools"

...

"...there is value in the items on the right..."

I think that's a recommendation of process.

IMO the decade of Agile has been a cluster, mostly because individuals pushing for it (IME, as a generalization) ignore the all important "there is value". Because it's not as fun/convenient/appealing/whatever (early on I was definitely one of those people).

I prioritize time with my kids over doing the dishes. That doesn't mean I shouldn't do the dishes.

Agile recommends you value people and try not to put barriers in front of communication, but that doesn't mean you shouldn't have a plan, scope of work, estimate, etc. Nothing in the manifesto at least says that. If you're doing fixed scope (yes, everything changes, but within reason it's generally easy to differentiate), fixed bid projects, then not having a plan is a guaranteed way to generate re-work, burnout and budget overruns for any project beyond the trivial.

Planning happens, wether it happens ahead of time or just-in-time, it happens. Trying to do the inevitable rework while it's still just paper is better for developers, your company, your clients, anyone.

I dunno, it seems like common sense to me. I get a contractor to bid a job in my house. The worst possible thing to happen is it takes longer than he thought and costs more. He can tell me all he wants about YAGNI and evolving understanding. My question to him is why he didn't anticipate this wall might have studs every 16" when I asked him to bid on the installation of in-wall speakers. If he'd planned it, thought through the process of performing the task each step of the way during the bid, then stupid stuff like this wouldn't happen.

IMO the Software Development world is a lot like Contracting. Mostly capable people (and some brilliant), but more often than not it's hard to find a contractor who can plan their way out of a wet paper bag. Sometimes there are good reasons for needing to change a plan. But not having one in the first place is not such a reason.

You want to thrill clients? Do what you say you will, for the price you say you will, when you say you will.

/end-rambling-rant

You click the 'twelve principles' link and go to http://agilemanifesto.org/principles.html

For instance: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Oh hey! It's a process! Heck, it's like a meta-process, even. THE meta-process.

Heinz von Foerster has spoken about the interaction between properties of the observer and the observed. In the quote below, one could replace "obscene" with "agile" -- each is impervious to objective measurement.

http://faculty.stevenson.edu/jlombardi/pdf's/cybernetics/cyb...

"There is at aperiodic intervals a ritual performed by the supreme judges of this land in which they attempt to establish once and for all a list of all the properties that define an obscene object or act. Since obscenity is not a property residing within things (for if we show Mr. X a painting and he calls it obscene, we know a lot about Mr. X but very little about the painting), when our lawmakers will finally come up with their imaginary list we shall know a lot about them but their laws will be dangerous nonsense."

That appears to be the only point in that page that resembles a process. And really it's self-reflection as a principle. But really a process is more mechanical. The manifesto says "Hey! Reflect regularly." That is not the same thing as saying "We must have a retrospective every 2 weeks using the force direction exercise..."

Your calling it a "meta-process" implies to me that you also get that distinction.

'Your calling it a "meta-process" implies to me that you also get that distinction.'

I interpreted "meta-process" as simply a remark that the process (presuming it is one, but that seemed to be the orientation of the author) addressed processes.

So? I really don’t see the problem with this. Sounds like you’re trying to make common sense into a bad thing ;-)

“Process” seems to be used as a stick for both sides to beat their opponent with… you are either doing too much or too little.

To me, a process is just an agreed way of doing things between a group of people. When it becomes a problem is when circumstances and experience tell you that this now isn’t the best way to proceed any more, but you still have to do it that way (and anyone who has worked for a large organisation will know what I mean)

Processes ought to change with time, and a lot of problems arise when they don’t… and so regularly checking whether your way of doing things is working is just sensible.

Sounds like the premise for a good article. Not, however, this article unfortunately. This article instead throws out a handful of straw-men and chiefly complains that agile doesn't help you with software design, something it's never claimed to do.

Reply on news.ycombinator.com