6 ms·

> Going through the entire development workflow (idea, design, prototype, beta release, delivery, and iteration). That sounds like what I was taught in school.

> Going through the entire development workflow (idea, design, prototype, beta release, delivery, and iteration). That sounds like what I was taught in school. Never used it. I'm just glad the waterfall model is dying. It is kind of funny, me and all of my peers were required to do the whole requirements, design, implement, verification, etc thing. But nobody did, nobody. Everyone did the same thing: Requirements for one small part, implement, verify, and then write the design document at the end to match the implementation. Repeat. I'm really glad things like agile are here, not because they're magical solutions to all of life's problems, but because they're inherently compatible with how people ALREADY WORKED. Waterfall felt like a boat anchor, causing teams to get indefinitely stuck in the design phase (or to lie a bunch to effectively skip it entirely). Agile allows you to go away, get it 90% down, and then iterate, iterate, iterate until everyone is happy. To be honest waterfall always felt like a programming methodology created by people who never programmed. It was like they took the method for building a bridge or a skyscraper, and applied it to software blindly. Agile methods feel like something designed by people who have actually programmed and know how they like to do it.

mbesto 11y ago
> I'm just glad the waterfall model is dying To be fair, it's not. > To be honest waterfall always felt like a programming methodology created by people who never programmed. And agile was created by people who don't understand that most organizations need specific software developed on a specific budget. A majority of companies that I see that say they are doing agile are still doing waterfall. PS - I'm a huge proponent of agile and the agile manifesto, but it's not a one size fits all methodology.
- jpatokal 11y ago
  > And agile was created by people who don't understand that most organizations need specific software developed on a specific budget. That's an odd criticism of agile. The whole point of agile is to prioritize so that the important stuff gets done first and does what it's supposed to, so when the money runs out you've got the most important bits working the way they should. If you've got a fixed budget, you're waterfalling and the money runs out, odds are very high that the software is going to do what the requirements said it should do, but it will be near-useless in real life.
  - mbesto 11y ago
    Any notion of "money runs out" is rendered useless when you have no idea what a starting budget should be.
  - vonmoltke 11y ago
    It isn't an odd criticism of Agile. In fact, I think the criticism is that Agile views all projects as things that go on until the money runs out, at which point the user gets whatever the team managed to finish. This ignores the world of projects that have hard requirements and hard deadlines. It also ignores the world of projects where the team needs to coordinate with other software and non-software development teams. I have not seen a variation of Agile that works well for these situations. The closest I have seen was referred to as "iterative development", where the project laid out a multi-year series of vague milestones and performed three-month mini-waterfall iterations to reach them in series.
- ebiester 11y ago
  You're living in a different world than I am. In my world, most organizations don't know the software they need until they figure out what they don't need in UAT. The exception to the rule is when they're replacing an existing system (or consolidating multiple systems.) Then, they think they know exactly what they need, but then they won't figure out what they need until UAT when the real users finally see the system and point out the business rules that were considered unimportant. So, why not iterate quickly, developing the software in one of two orders: * If one portion of the system can be used independently and generate value, why not build that first and get everyone using that? * If the system cannot provide value independently, build the MVP of the first screen they will use in the workflow and a view-only portion of the second screen? Then get real world users to tell you what they absolutely need before calling it done. Once the first screen is done to their approval, then you take stock of the budget. You tell them there is a balancing act between cost and scope, and everything flows from there. (Or, you find that the value can't be realized and bail to another project.)
  - mbesto 11y ago
    Hopefully this doesn't come off as patronizing, but given you're a programmer (had a look at your profile), then yes we definitely live in different worlds. I work with a variety of people who have very little empathy for developers, but effectively hold the purse strings on technology decisions. These people (which largely outnumber programmers btw) see the world in black and white -- things either work or they don't. Software development to them is a black box. > The exception to the rule is when they're replacing an existing system (or consolidating multiple systems.) This is pretty much 90% of the software systems and projects that exist today. Don't let the headlines of TechCrunch fool you. The world outside SV doesn't sit in Google, it sits in terminal screens and mainframes. All that money SAP, IBM and Oracle is making is all made by replacing existing systems (whether software or pen and paper). The people making the decisions don't care about MVPs or what screens look like. They want to increase efficiencies aligned with the objections of their role and not get fired for doing it. When I tell a trader at an asset management company they can't enter in incorrect values for a stock trade because we'll need to fix the data quality issue on our backend, they tell me "f--- off" because they'll simply pay their way out of that discrepancy. So I hear you, but what you're suggesting exists in very few organizations (globally) or in a vacuum.
- pjmlp 11y ago
  > A majority of companies that I see that say they are doing agile are still doing waterfall. Actually 3 week long mini-waterfalls. :)
- hvidgaard 11y ago
  > most organizations need specific software developed on a specific budget And that is perfectly fine. It doesn't mean you cannot be agile. Agile is a matter of breaking it down, choosing what to work on, and verify progress. If your constrain is 4 dev team and 6 months, you plan after that. If you cannot make a somewhat realistic roadmap, you either reconsider the constraints, or are forced to move forward. In any case, with agile you know your progress compared to the overall roadmap every 1-4 weeks depending on your resolution, but it's infinitely better than the waterfall where the mangers throw the spec over the wall to the dev team, and climb over to ask why it's delayed after the deadline.
dasil003 11y ago
It's a methodology from when you had to schedule time for your program to run and at a minimum 24-72 hour turnaround on the smallest change. In that case it's worth taking extra time to verify things on paper and institute heavy practices to ensure correctness. Then you can just type "exec" in a terminal that completely changes the equation.

mbesto 11y ago

> I'm just glad the waterfall model is dying To be fair, it's not. > To be honest waterfall always felt like a programming methodology created by people who never programmed. And agile was created by people who don't understand that most organizations need specific software developed on a specific budget. A majority of companies that I see that say they are doing agile are still doing waterfall. PS - I'm a huge proponent of agile and the agile manifesto, but it's not a one size fits all methodology.

jpatokal 11y ago
> And agile was created by people who don't understand that most organizations need specific software developed on a specific budget. That's an odd criticism of agile. The whole point of agile is to prioritize so that the important stuff gets done first and does what it's supposed to, so when the money runs out you've got the most important bits working the way they should. If you've got a fixed budget, you're waterfalling and the money runs out, odds are very high that the software is going to do what the requirements said it should do, but it will be near-useless in real life.
- mbesto 11y ago
  Any notion of "money runs out" is rendered useless when you have no idea what a starting budget should be.
- vonmoltke 11y ago
  It isn't an odd criticism of Agile. In fact, I think the criticism is that Agile views all projects as things that go on until the money runs out, at which point the user gets whatever the team managed to finish. This ignores the world of projects that have hard requirements and hard deadlines. It also ignores the world of projects where the team needs to coordinate with other software and non-software development teams. I have not seen a variation of Agile that works well for these situations. The closest I have seen was referred to as "iterative development", where the project laid out a multi-year series of vague milestones and performed three-month mini-waterfall iterations to reach them in series.
ebiester 11y ago
You're living in a different world than I am. In my world, most organizations don't know the software they need until they figure out what they don't need in UAT. The exception to the rule is when they're replacing an existing system (or consolidating multiple systems.) Then, they think they know exactly what they need, but then they won't figure out what they need until UAT when the real users finally see the system and point out the business rules that were considered unimportant. So, why not iterate quickly, developing the software in one of two orders: * If one portion of the system can be used independently and generate value, why not build that first and get everyone using that? * If the system cannot provide value independently, build the MVP of the first screen they will use in the workflow and a view-only portion of the second screen? Then get real world users to tell you what they absolutely need before calling it done. Once the first screen is done to their approval, then you take stock of the budget. You tell them there is a balancing act between cost and scope, and everything flows from there. (Or, you find that the value can't be realized and bail to another project.)
- mbesto 11y ago
  Hopefully this doesn't come off as patronizing, but given you're a programmer (had a look at your profile), then yes we definitely live in different worlds. I work with a variety of people who have very little empathy for developers, but effectively hold the purse strings on technology decisions. These people (which largely outnumber programmers btw) see the world in black and white -- things either work or they don't. Software development to them is a black box. > The exception to the rule is when they're replacing an existing system (or consolidating multiple systems.) This is pretty much 90% of the software systems and projects that exist today. Don't let the headlines of TechCrunch fool you. The world outside SV doesn't sit in Google, it sits in terminal screens and mainframes. All that money SAP, IBM and Oracle is making is all made by replacing existing systems (whether software or pen and paper). The people making the decisions don't care about MVPs or what screens look like. They want to increase efficiencies aligned with the objections of their role and not get fired for doing it. When I tell a trader at an asset management company they can't enter in incorrect values for a stock trade because we'll need to fix the data quality issue on our backend, they tell me "f--- off" because they'll simply pay their way out of that discrepancy. So I hear you, but what you're suggesting exists in very few organizations (globally) or in a vacuum.
pjmlp 11y ago
> A majority of companies that I see that say they are doing agile are still doing waterfall. Actually 3 week long mini-waterfalls. :)
hvidgaard 11y ago
> most organizations need specific software developed on a specific budget And that is perfectly fine. It doesn't mean you cannot be agile. Agile is a matter of breaking it down, choosing what to work on, and verify progress. If your constrain is 4 dev team and 6 months, you plan after that. If you cannot make a somewhat realistic roadmap, you either reconsider the constraints, or are forced to move forward. In any case, with agile you know your progress compared to the overall roadmap every 1-4 weeks depending on your resolution, but it's infinitely better than the waterfall where the mangers throw the spec over the wall to the dev team, and climb over to ask why it's delayed after the deadline.

dasil003 11y ago

It's a methodology from when you had to schedule time for your program to run and at a minimum 24-72 hour turnaround on the smallest change. In that case it's worth taking extra time to verify things on paper and institute heavy practices to ensure correctness. Then you can just type "exec" in a terminal that completely changes the equation.