Live data from Hacker News

Agile Is Dead: The Angry Developer Version

rubiquity.com

31–40 of 75 posts

Re: Agile Is Dead: The Angry Developer Version

#31
post #11

In the trenches, methodologies don't get projects done. Dave Thomas's original description of agility seems an accurate description of how code actually gets made--and that description is deliberately not a description of a methodology. I ship working code every day, and my clients are happy, despite the fact that I'm not following any definable methodology. Coding is a messy process. Codebases evolve in many ways: T…

I absolutely agree that there is no silver bullet. But there are quite a few lead bullets that when aimed accurately can make a real difference. None of them are prescriptive methodologies, though. They are all things like incrementalism, automation, and high quality code.

Agreed 100%. I like your metaphor of lead bullets. There's no silver bullet that will win a war, but you sure aren't going to win without putting the lead bullets in the right places.

Re: Agile Is Dead: The Angry Developer Version

#32
post #11

In the trenches, methodologies don't get projects done. Dave Thomas's original description of agility seems an accurate description of how code actually gets made--and that description is deliberately not a description of a methodology. I ship working code every day, and my clients are happy, despite the fact that I'm not following any definable methodology. Coding is a messy process. Codebases evolve in many ways: T…

"a coding team's only salvation is smart coders" Smart coders who understand that they're part of a team . I've seen at least as many problems caused by people not working with those around them (whether they be other developers, users, testers or whoever) as caused by rank stupidity. That's not to say there needs to be a massively formalised way of working together, just the fact that other people are involved needs…

So true! A bunch of smart, arrogant lone wolves won't be very effective at software development.

Re: Agile Is Dead: The Angry Developer Version

#34
post #20
post #17

Earlier quoted context omitted.

What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that. 80% of agile can be summed up as: limit work in progress, and (almost as a necessary consequence of this) ensure any given piece of work can go from initial requirement to deployed to customer very quickly. My "in the trenches" experience is that whether or not a company fol…

> What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that. Good question. If you mean: "Why do you choose to ship code?" then I suppose it's my desire to please my clients and stay employed. If you mean: "How do you manage it?" then it's what I hinted at earlier: Good intuition, experience, a precise and logical mind, and thoughtf…

I thought you must be kidding about the "hammer-centric methodology": Do companies actually say they have a "tool-centric methodology"?

Then I remembered one I saw just the other day:

> We offer a highly configurable Agile and tools-based software development methodology

They also have an "execution-focused leadership team" and "offer a number of flexible outcome-oriented engagement models assuring the success of our projects"

The whole page is like that!

http://accionlabs.com/company/why-accion-labs/

Re: Agile Is Dead: The Angry Developer Version

#35
post #20

Earlier quoted context omitted.

> What is it that keeps you shipping working code every day? That's not the state of nature, you've clearly made some kind of decision to do that. Good question. If you mean: "Why do you choose to ship code?" then I suppose it's my desire to please my clients and stay employed. If you mean: "How do you manage it?" then it's what I hinted at earlier: Good intuition, experience, a precise and logical mind, and thoughtf…

I thought you must be kidding about the "hammer-centric methodology": Do companies actually say they have a "tool-centric methodology"? Then I remembered one I saw just the other day: > We offer a highly configurable Agile and tools-based software development methodology They also have an "execution-focused leadership team" and "offer a number of flexible outcome-oriented engagement models assuring the success of our…

Wow. I've always wondered: Is this kind of empty, buzzwordy writing effective? Does it sell?

So many companies write this way. I could believe they do so only because their staff never learned how to write good sales copy. Or is there some actual merit to it? Do they know something I don't--namely, that buzzwords sell?

Re: Agile Is Dead: The Angry Developer Version

#37
For me agile is a way of making bringing what's wrong with your development painful and front and center, forcing you to address it. As such many people don't like this and as a result agile tends to get warped into whatever process it is they had before, but now it's just called agile. And this is why almost everyone can say they are agile, even thogh they aren't.

Re: Agile Is Dead: The Angry Developer Version

#38
post #11

In the trenches, methodologies don't get projects done. Dave Thomas's original description of agility seems an accurate description of how code actually gets made--and that description is deliberately not a description of a methodology. I ship working code every day, and my clients are happy, despite the fact that I'm not following any definable methodology. Coding is a messy process. Codebases evolve in many ways: T…

I absolutely agree that there is no silver bullet. But there are quite a few lead bullets that when aimed accurately can make a real difference. None of them are prescriptive methodologies, though. They are all things like incrementalism, automation, and high quality code.

Incrementalism and automation may be "lead bullets", but "high quality code" is more the target you are shooting at.

Re: Agile Is Dead: The Angry Developer Version

#39

Earlier quoted context omitted.

I absolutely agree that there is no silver bullet. But there are quite a few lead bullets that when aimed accurately can make a real difference. None of them are prescriptive methodologies, though. They are all things like incrementalism, automation, and high quality code.

Incrementalism and automation may be "lead bullets", but "high quality code" is more the target you are shooting at.

I'd disagree here and replace that with "fufilling business needs" - the highest quality code is meaningless if it doesn't do what your customer wants in the way they want it done.

Good craftsmanship is usually correlated with a good end product, but craftsmanship for its own sake is a hobby, not a career.

Re: Agile Is Dead: The Angry Developer Version

#40
post #2

I've seen this cycle a few times. Let me handwave how it goes: * Agile Critisism: The snake oil is all over and getting worse! * Agilista: It's not done properly ! * Agile Criticism: No True Scotsman! I think the NTS is where things usually leave the line and end up in a lot of splutters and anecdotes. Sometimes I wonder if the great flamewars and their arguments should be canonized into standard textfiles and passed…

It doesn't have to be that way. Agile has a ton of advocacy, it just needs the right advocates that really understand it to help guide teams in the right direction. Agile has been entirely too driven by salesmen the last few years.

The Agile Manifesto is a great starting point, but beyond that I think Agile is too poorly defined; I think the values of the Agile Manifesto are best made concrete in terms of a high level meta-methodological framework in Lean methodologies with (under various names) the PDCA cycle wherein teams have ownership of their own specific processes, strictly follow the processes they define, have clear success metrics, propose process changes from within the team when there is an observed problem with the existing process in meeting desired results, and do empirical tests of the proposed changes using the success metrics.

Outside of this kind of concrete instantiation, "Agile" seems to diverge into, on the one side, a combination of empty buzzwords and arbitrary churn where no one knows who is responsible for what or what standards are because there is no process, or externally-defined prescriptive processes of exactly the sort that the Agile Manifesto was a reaction against.

People over processes has to mean processes are tools that serve the people on the team, not "no process" or "process taken as received wisdom because of respect for the person or institution originating it".

Post reply on HN