Hacker News Reader

Comment by commandlinefan | Hacker News Reader

> Asking a methodology to always meet requirements on time and within budget

I'm not quite sure what you're getting at here, because that's absolutely, positively 100% what the people who are recommending methodologies insist they're for and absolutely, positively 100% what the people who adopt them want them for. The ENTIRETY of software developer management is focused - beginning and ending - on meeting requirements on time and within budget. That's the ONLY thing they care about and their ONLY purpose for existing.

View on HN

I mean I don't know what to tell you, but you're just completely wrong.

Sure, that's what management would wish in an ideal world. But obviously that's not what these methodologies are even marketed as -- e.g. the entire purpose of agile/scrum is to break into sprints that have deliverables as goals but not as guarantees, in order to de-risk larger failures by exposing smaller failures earlier, to be able to then adjust requirements/timeline as you go. Heck, it's so important that they insist on estimating tasks in terms of abstract points instead of units of time.

Methodologies attempt to give more accurate, less wishful-thinking, estimates of timelines/resources. And they're often quite successful at that with things like planning poker etc. But all they do is improve, they don't give guarantees.

You're totally right, but the main issue is that people don't even learn what the goal of agile / extreme programming is (it's a methology for engineers for giving data to managers to be able to take early decisions / manage the project while it's cheaper).

It has taken over by managers to just be used for pressuring software engineers, that's why the name had to change so much.

Yeah, no. I wrote one of the more popular books about Agile development (The Art of Agile Development) and it says right in the first chapter that "meeting requirements on time and within budget" is not the goal.

"Agile teams define success as delivering value, not conforming to a plan. In fact, truly Agile teams look for opportunities to increase value by changing their plans." (p.7)

So there's at least one person recommending methodologies who absolutely, positively, 100% does not agree with you.

The whole chapter is free online if you want to get out of your bubble: https://www.jamesshore.com/v2/books/aoad2/what_is_agile

In my experience working with a well-known consultancy that uses strict XP, agile, TDD, the whole 9 yards - this isn’t the case at all.

They talk about a triangle of (scope, quality, cost) where you can only pick 2. As a business you can choose what trade off you want to make, but no one’s promising that you can have a rocket ship by next week with 2 engineers if you just organize your tickets correctly.

Methodologies should help projects meet requirements on time and within budget, but expecting 100% success regardless of the project, experience of the team complexity of estimate and what not is completely unrealistic.

Reply on news.ycombinator.com