5 ms·

Us old people hate Agile too.

• dblohm7 12y ago
  Word!
• jay_kyburz 12y ago
  Would you rather spend the first half of every project planning and scheduling every little feature, then spend the second half of the project missing deadlines and implementing features that are not right for the product?
  • Nursie 12y ago
    This seems to me a false dichotomy. Sometimes requirements actually are set in stone and it's good to do this - I worked on an embedded device last year, with fixed interfaces and fixed security requirements. That project would have gone a lot faster if there had been an effort to explore and document these at the beginning. --edit-- oh, and of course, agile projects never, ever miss deadlines...
  • MichaelGG 12y ago
    This is an incorrect comparison. But I'd also not like to work on a project where someone delivers a feature branch only to find out the feature's been redesigned completely for the 4th time. Or where there is no spec for features at all, just wireframes that change daily and developers are supposed to reverse engineer what the latest UI means into a feature set. But wait, daily standup so it's Agile. A lot of projects would do good to have a light approach at spec writing, to get faced with problems before they're in code. I'm unconvinced that a dev process is going to supersede dysfunctional technical management, no matter what we call it.
    • bottled_poe 12y ago
      Precisely. A team of decent engineers and competent managers will typically produce good software. And guess what - it will barely matter which methodology you choose to adopt.
      • JoeAltmaier 12y ago
        A better dichotomy is: would you rather have a better process, or hire better engineers? I choose better engineers.
        • s73v3r 12y ago
          Better engineers are expensive, and I can't crack the whip on them like I can disposable engineers. /phb
  • amyjess 12y ago
    I've worked on way too many projects where things went "Hey, you just delivered the big load to QA? Well, we think the customer wants features X, Y, and Z on top of what you've already written, but we're not budging on the release date, so you better pull the load from QA and start working 16-hour-days and coming in on weekends. Oh, and if it breaks after being delivered to the customer, we'll throw QA under the bus because QA failed to do proper soak testing, and we'll have QA throw you under the bus because you didn't give them time to soak since we're making you develop right up to the night before launch." to trust any process where features can be added after development begins.