4 ms·

I read this and it's just insane to me -- would be like arguing for svn to come back instead of all this 'git' nonsense. The battles were fought and svn lost.

• Shadowmist 3y ago
  Yeah, like construction is known for its ability to deliver on time.
• makeitdouble 3y ago
  On waterfall vs agile, both don't work without significant flexibility and fuzzying the game on the dev team's part. Waterfall as it was done in early 2000s was mostly a high level plan and smaller unofficial iterations on the ground. We knew we need to test, and sometimes partially release stuff in advance to have an idea of what's actually working and what's half baked. The same way successful agile projects are almost always done with unofficial rough planning and dependency graphing checked ahead, and smaller iterarion following the big picture from there. On both methodologies, religiously adhering to the mantra is suicidal, and I don't see agile being significantly better except if all you care about it getting paid iteratively -- which is a noble goal for a consultant. Perhaps the point that bears reiterating is very few shops actually followed hard line waterfall planning (nor agile, for that matter).
• frozenlettuce 3y ago
  For most developers, agile means being coached daily like in a sports team. Most folks just want to know what to do, work on it, deliver and repeat. Instead of empowering developers it allows managers to micromanage with a daily feedback loop.
  • darreninthenet 3y ago
    Which is not how agile is supposed to be done. Waterfall done badly is shit as well.
    • spentu 3y ago
      Not supposed, but is done like that.
• bluGill 3y ago
  Most commercial developers are using git as if it was svn with some local caching, and other small features that could be added to svn (at some cost). They call their svn central server github. Very few take advantage of what makes git different from svn. Svn lost, but the reasons were not always good (I never used svn so I cannot comment in detail, but the VCSs I used before git are still the same workflows most use with git)
  • fmajid 3y ago
    You seem to have forgotten how bad branching and merging was in Subversion. Trauma, repressed memories and so on, perfectly understandable.
    • bluGill 3y ago
      As I said, I never used SVN (several other version control systems yes, but not SVN). However it seems like those are fixable problems in SVN.
      • nrr 3y ago
        They are. You use git-svn as a tool to prepare patches for submission and branch in Subversion only for a release series. It works remarkably well.
• argiopetech 3y ago
  Agile (acknowledging the broadness of the category) doesn't account for poor estimation in any way. Agile methodologies simply refuse to answer "when will it be done"-related questions. Even with perfect estimators, it's an intractable problem when you can add new features of unknown complexity to the backlog at any time. Waterfall is suited for projects where the outcome is known (e.g., guidance software for fancy new jet, embedded software, etc.) where establishing a deadline is necessary and possible because the desired feature set is fixed (at least in theory) and changes are locked behind a (likely multi-year) requirements and design process with contacts and lawyers. Agile is better suited for exploration of a product space or implementation of projects where agility (surprise, surprise) to changing/unknown client needs is paramount. Clients don't know what they want till they see what they don't want, so agile is great for that type of build. The web-facing world loves agile, because the "end" goal is usually, "make money so we can hire more developers to build more website [whatever that means] to make more money to hire more developers...". There are means of mitigating bad estimation (e.g., Spolsky's "Painless Software Schedules" and particularly "Evidence-Based Scheduling".), but you can't account for a 50 hour feature added 19 weeks into a project. Agile (acknowledging the broadness of that category) alone doesn't do anything to mitigate either bad estimation or surprise features, it simply trades "known deadline, fixed features" for "unknown deadline, flexible features".
  • nrr 3y ago
    > Agile methodologies simply refuse to answer "when will it be done"-related questions. Even with perfect estimators, it's an intractable problem when you can add new features of unknown complexity to the backlog at any time. I'm unconvinced. If new features of unknown complexity are getting added to your product backlog with the expectation that estimations are done against them and not that exploratory work is planned and undertaken instead, that's a problem with the culture and not with the process. Scrum in particular (according to Coplien et al. at least) is meant to handle prioritization of work as a conversation between the people who want stuff built and the people actually doing the work to get stuff built. The only thing it recommends—not even prescribes—as it relates to estimation uncertainty is embracing the framework to chart a new course more easily when the facts change. A big pattern that is prescribed (though perhaps only implicitly via reiterating that the product backlog is strictly in delivery order when work starts) is that the product backlog is append-only when you don't want to trigger more planning and, as a direct consequence, draw up a new refined product backlog for everyone to work from. If you need to reorder your product backlog items to add something in the middle, that's a signal that the facts have changed, and the plan needs to be redone. That isn't prima facie all that different from a more traditional project management method. Agile only aims to make planning suck a little less to change by baking certain touch-points into the process so that someone can pull the proverbial andon cord unceremoniously. > Agile is better suited for exploration of a product space More apropos this, if you've ever heard of a spike solution, that's agile's attempt at controlling for uncertainty when it isn't exactly clear how to do something or how long something will take. It necessarily triggers additional planning, and the product backlog item for it is a clear display of the uncertainty inherent in delivering that helps determine where in the ordering that work should fall. Likewise, if you generally know what the roadmap looks like and have confidence that it won't change, the uncertainty is still in the humans doing the work. I've always put vacations and bereavements and on call shifts and other kinds of fixed-date "generally not available for product work" things into the product backlog, and having that visible to everyone with stake in the work is always valuable.
• harperlee 3y ago
  To the extent that a project involves implementation of existing code / modules / software and other activities that are not greenfield developments, though, the software-development-estimation-ability is not relevant as an argument against these methods, though. All training, activities, budgeting, hiring, etc. "knowable" activities around developing a project can also be managed in that way, and particularly if you're doing agile, you have a cadence against which you can do long-term planning of non-development activity.
• _a_a_a_ 3y ago
  git vs svn is just one tool vs another, for different situations, neither better nor worse unless by use.