Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile Is Dead, Long Live Continuous Delivery

gradle.org

Post reply on HN
Print view View original

91–100 of 157 posts

Re: Agile Is Dead, Long Live Continuous Delivery

#91

Post by Karunamon »

jacques_chester wrote: post #55
scolfax wrote: post #22

Earlier quoted context omitted.

Agreed. But feel compelled to add: Agile is only a problem when teams pretend to follow it but actually don't.

I'm an XP fan, but I'm always wary of saying "they didn't do real agile". It can descend into "No True Agile" pretty quickly, with a dash of victim-blaming. Agile is actually hard to get to grips with. It requires lots of discipline. So did the pre-agile methods that worked best. And it gets half-done for the same reason that the pre-agile methods got half-done. It's hard. Hard to do, hard to learn, tempting to stop.

Perhaps, but one problem often seen in large orgs (I've been there personally twice, and heard many more stories from close colleagues) is that they adopt the agile methodology (sprints, stories, etc), without adopting the culture shift (shit does not get added into the middle of a sprint, ever) necessary to make it work.

Agile process without agile culture objectively isn't True Agile. It's worse than everything it sets out to solve with the alternatives.

Re: Agile Is Dead, Long Live Continuous Delivery

#92

Post by bandushrew »

ternaryoperator wrote: post #81
gnaritas wrote: post #70

Earlier quoted context omitted.

> Pure waterfall as it's depicted by Agile consultants was never a thing. Yes it was. > Think about it, how could you possibly code an entire app and only then debug it? Which is why programmers hate waterfall so much, but you're absolutely wrong to think this isn't exactly what was being attempted. Time and time again, management in an attempt to cut the cost of programming time, thought the way to do it was to firs…

"Pure waterfall as it's depitected by Agile consultants was never a thing." This is correct. The first paper to describe a stepwise model was by Royce in 1970 [1]. The model he is describing is hypothetical and does not use the term Waterfall. The first use of the word "waterfall" (including the quotation marks) is from 1976 [2] and specifically refers to [1], the hypothetical model. In [2], the writers specifically…

The term "Waterfall" was not applied.

but it absolutely was very common to use the process that it implies.

many man-years of gathering requirements, building lists of features, interrogating stakeholders.

people knew they would never get a second chance to get what they wanted, so they would throw every feature in that they could think of.

Then the developers would build it. more man years building. mostly they tested as they went along, but....different features and areas of the app were often build in isolation, so the most you could say was that you had tested what you had built.

the stakeholders were consulted with screenshots, and sometimes the app, but the Big Fear was new features and additional requirements (which would cause massive contractual headaches) so any contact was VERY carefully controlled.

Also it was assumed every project was massively valuable IP, so detailed designs and features were held very close to the chest..again, any contact was VERY carefully controlled.

Eventually, after months or years of effort the various parts of the app would be "merged". omg the cluster fuck that would occur, the compromises, and arguments, the agonizing...

..then more testing..

Once that was completed the brilliant new creation would be seriously unveiled to the users to cheers and relief.

Finally, the contractual battles would begin as the paying company realised they had asked for entirely the wrong thing, and the development company tried desperately to cover their ass and make a profit.

The single biggest problem that Agile fixes isn't the testing, its the disconnect between what the client wanted and what the developers actually deliver.

Re: Agile Is Dead, Long Live Continuous Delivery

#93

Post by morgante »

I stopped reading at "Agile had a great run in it’s youth by taking on some obviously bad practices such as 'Waterfall' software development."

Nothing about waterfall is obviously bad. It's how most engineering projects are done. Heck, it's how most projects generally in the world are done.

There's a reason it took a long time to move away from waterfall. It solves obvious problems and meshes with how the rest of corporations typically operate. In fact, with software delivery methods which were dominant back then, agile probably would have completely failed.

---

In the end, I ended up reading the full piece. One doesn't get much more oblivious and buzzwordy than this:

> We are now more squarely in the age of Microservices, Mobile first, Polyglot, post-Java JVM languages, GitHub, Docker and the emergence of a world being eaten by Software.

How is this piece on the top of Hacker News? This piece reads like it was written by a marketing consultant with no idea what these terms actually mean or how software is actually built.

Re: Agile Is Dead, Long Live Continuous Delivery

#94

Post by timv »

jheriko wrote: post #48
jcrites wrote: post #47

Earlier quoted context omitted.

> The agile manifesto has plenty of problems that should be obvious with some thinking. Some of the statements are outright ludicrous and naive as much as others are valuable insights Are we talking about the same document? What are the problems and harmful aspects that you're referring to? (Please quote the relevant part) This comment feels either a bit like a content-free middlebrow dismissal, or we're referring to…

http://agilemanifesto.org/ http://agilemanifesto.org/principles.html From the very first. > Individuals and interactions over processes and tools Have you seen this in practice and experienced how people work day-to-day? Leave them to their own devices and it varies a lot by personality. Some people need micro-management for instance... there is also thing that process is very important, and this point is self contra…

I think one's assessment of the manifesto is largely dependent on how generously you read it.

> Individuals and interactions over processes and tools

needs to be read in conjunction with:

> while there is value in the items on the right, we value the items on the left more

Which means I can interpret it a way that is true, but not that interesting.

That is, I believe that a great developer with crappy tools will produce better software than a crappy developer with great tools

But I'm not sure what that really tells me other than "hire great people".

I guess, to some extent, it means "if the process says I should do X, but the team thinks it's a bad idea, then I should listen to them", but even that's is not a necessary conclusion from the statement. In the non-software world, you only need to spend a little bit of time looking at workplace deaths to see that many of them are caused by teams that decided to ignore safety protocols.

Ultimately the only thing I really take from the agile manifesto is that doing the exact opposite is bad, but so what?

I don't want to ever work in development team that:

- Thinks that "following a process" trumps "investing in good people"

- Prioritizes writing documentation for software rather than making it work

- Has watertight contracts but ultimately disappoints the customer

- Sticks to "the plan" even when it's obvious that the circumstances have changed.

But I didn't need a manifesto to tell me that.

Re: Agile Is Dead, Long Live Continuous Delivery

#95

Post by morgante »

spriggan3 wrote: post #45
jheriko wrote: post #6

buzzword filled click-bait. :/ just use your brain. agile is only a problem when people follow it religiously instead of intelligently imo. its just one tool in the box, not the ultimate methodology.

Well it's working, it's on top of HN. The problem is the people clicking in the end. I didn't, cause I know with a title like that this gona be some cheap clickbait.

No, the problem is the 140+ people who apparently thought this buzzword-filled fluff was worth upvoting.

Re: Agile Is Dead, Long Live Continuous Delivery

#99

Post by mschuster91 »

> If you’re unable to keep pace with the rate of change of the open source components you depend on, you will be frozen and stuck and unable to ship software properly, a state we at Gradle call “Build Hell”.

Or do it like anyone who wants to build a business that lasts longer than 2 years: use stable, battle-proven software only and don't run after every hipster trend (remember EmberJS and friends). Before you use any software component, evaluate its support lifecycles and how well it is being maintained - especially with the trend of "modularization", where stuff like a string pad function is a separate module, every additional dependency you pull is a potential security issue.

Oh, and don't make the cardinal error of putting your node_modules/vendor folders into .gitignore. THAT is build hell once someone unpublishes a popular module...

Post reply on HN