Comment by jdietrich | Hacker News Reader

Comment by jdietrich | Hacker News Reader

Parent Full thread

Yes, but there are relatively very few of these huge products. While there are lots of people working on these huge projects, there are few managing them and even fewer with the seniority to decide on methodology.

If software is anything like the broader business world, then the overwhelming majority of software shops will be small shops. It stands to reason therefore that the overwhelming majority of people managing a software project will be managing a very small number of developers.

My statement about bicycle mechanics learning from NASA stands - there just aren't many people managing big projects. Game development has practically no relevance to practically all managers. I certainly can't imagine that many people reading HN are managing the development of an operating system or a DBMS.

If you happen to be building the pyramids of Giza, linear development is a good approach. For the rest of us, iteration is the only rational way of doing it.

I feel like we're talking at right angles. Your central point seems to be that most people will never build software like this. That's totally true, no contest.

However, I think it's still an interesting topic, and a significant minority can learn something useful.

There should be room for both perspectives here.

I'd be more inclined to agree if the piece wasn't entitled "Games Development in a Post-Agile World". The central conceit of the article seems to be to debunk agile as a workable method. The article doesn't argue that agile is a hugely useful approach for most developers but a poor approach in some specific niches, it argues that agile is complete claptrap.

I will happily agree with you that there is room for a number of development methodologies.

> "it argues that agile is complete claptrap."

No it doesn't. It says that Agile proponents who claim it's a silver bullet are talking claptrap. If anything, it says that Agile is a tool and you need to pick the right tool for the job.

Based on the Agile manifesto, the author proposes a scale with "people" at one end and "process" at the other. Ostensibly waterfall is strongly "process" and Agile is a more "people", but he argues that Agile consists of a number of elements that exist at different points along that scale.

He says that the elements down at the "people" end of the spectrum require good, experienced, self-motivated people. If you have these then Agile is more efficient. If you have juniors or average coders (more likely on a large team) then the overhead of a process-based system may work better.

He also identifies the points within the product's development lifecycle where Agile-like approaches work best and when the more hierarchical methods work best.

Reply on news.ycombinator.com