5 ms·

Have to disagree. Many places try to optimize for enjoyment so they can keep their employees. There is a time and place for everything. If you a working on a p

Have to disagree. Many places try to optimize for enjoyment so they can keep their employees. There is a time and place for everything. If you a working on a project that takes months it should be planned ahead but if it only takes a few days you might not need. Let us not forget why we got rid of waterfall model.

Udik 8y ago
> Let us not forget why we got rid of waterfall model. It's actually doubtful it ever existed: its first formal description, in the 1970s, is used as an example of a model that doesn't work. Let me formulate the Godwin-Udik's law: "As an online discussion on development practices grows longer, the probability of a mention of waterfall as a negative example approaches 1"
- DogLover_ 8y ago
  Interesting! Too young to have experienced waterfall model in a workplace. Are you saying it did not exists. If so what was the agile manifest a response to?
  - Udik 8y ago
    > what was the agile manifest a response to? Frankly I don't know. The Manifesto itself is not very clear about it. I've worked in agile and non-agile companies, but none used a waterfall model. If anything, agile adoption always meant more process (stories, standups, planning, retrospectives, etc.) rather than less. Before or without agile, the structuring of work has been mostly the same, albeit without the formal process defined by this or that agile methodology (to be fair, scrum is the only one I've ever seen).
- droussel 8y ago
  It was actually mandated for many government projects for a while. A good history of iterative development can be read here: http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf http://www.craiglarman.com/wiki/downloads/misc/history-of-it...
  - Udik 8y ago
    > It was actually mandated for many government projects for a while I have no clue about this, but I suspect that the government, rather than mandating a software development methodology, simply used to agree beforehand on what was to be delivered and expected to have it delivered at the end of the process. It's a constraint on how you sign contracts with external suppliers, not on how you write code- though I understand that the first influences the second.
    - droussel 8y ago
      In many industries as well as many government branches it still works just like that. They do not mandate a way of "writing the code", but software projects must pass gates and receive approvals at each stage before getting funding. They have to provide comprehensive analysis and architecture documentation that cover everything under the sun before a single line of code is written. And then, once a dev team starts coding, it has to go through the whole loop and if something specified doesn't make sense "on the real world". Or, more often, they just do the proper thing without telling anyone.
astazangasta 8y ago
Writing down what you intend to do and verifying with your team it is sensible is not "the waterfall model". This "I just want to code" attitude is a major disease of young programmers and a leading cause of shitty software. Think ahead. Write it down. You are not a lonesome dove.
- DogLover_ 8y ago
  Thats a fair point, but I did not say that there should be no communication about the work you do. We all work differently and I think it is sensible to let each employee have some form of independence of how they want to structure their own work. If the feature is a few days of work let me work on it like I prefer and then I can submit with a nice description and thought process. Let us also not forget about all the time wasted on getting your plan validated. Or how your validated plan is completely screwed only realized after you start implementing it. Pros and cons to each solution.
  - astazangasta 8y ago
    Again, there is no justification for just jumping in and writing code. Would you cut wood without measuring it first? Would you start soldering without laying out a circuit? Would you write an essay without an outline? You could do all of these things, but the results are guaranteed to be crap.

Udik 8y ago

> Let us not forget why we got rid of waterfall model. It's actually doubtful it ever existed: its first formal description, in the 1970s, is used as an example of a model that doesn't work. Let me formulate the Godwin-Udik's law: "As an online discussion on development practices grows longer, the probability of a mention of waterfall as a negative example approaches 1"

DogLover_ 8y ago
Interesting! Too young to have experienced waterfall model in a workplace. Are you saying it did not exists. If so what was the agile manifest a response to?
- Udik 8y ago
  > what was the agile manifest a response to? Frankly I don't know. The Manifesto itself is not very clear about it. I've worked in agile and non-agile companies, but none used a waterfall model. If anything, agile adoption always meant more process (stories, standups, planning, retrospectives, etc.) rather than less. Before or without agile, the structuring of work has been mostly the same, albeit without the formal process defined by this or that agile methodology (to be fair, scrum is the only one I've ever seen).
droussel 8y ago
It was actually mandated for many government projects for a while. A good history of iterative development can be read here: http://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf http://www.craiglarman.com/wiki/downloads/misc/history-of-it...
- Udik 8y ago
  > It was actually mandated for many government projects for a while I have no clue about this, but I suspect that the government, rather than mandating a software development methodology, simply used to agree beforehand on what was to be delivered and expected to have it delivered at the end of the process. It's a constraint on how you sign contracts with external suppliers, not on how you write code- though I understand that the first influences the second.
  - droussel 8y ago
    In many industries as well as many government branches it still works just like that. They do not mandate a way of "writing the code", but software projects must pass gates and receive approvals at each stage before getting funding. They have to provide comprehensive analysis and architecture documentation that cover everything under the sun before a single line of code is written. And then, once a dev team starts coding, it has to go through the whole loop and if something specified doesn't make sense "on the real world". Or, more often, they just do the proper thing without telling anyone.

astazangasta 8y ago

Writing down what you intend to do and verifying with your team it is sensible is not "the waterfall model". This "I just want to code" attitude is a major disease of young programmers and a leading cause of shitty software. Think ahead. Write it down. You are not a lonesome dove.

DogLover_ 8y ago
Thats a fair point, but I did not say that there should be no communication about the work you do. We all work differently and I think it is sensible to let each employee have some form of independence of how they want to structure their own work. If the feature is a few days of work let me work on it like I prefer and then I can submit with a nice description and thought process. Let us also not forget about all the time wasted on getting your plan validated. Or how your validated plan is completely screwed only realized after you start implementing it. Pros and cons to each solution.
- astazangasta 8y ago
  Again, there is no justification for just jumping in and writing code. Would you cut wood without measuring it first? Would you start soldering without laying out a circuit? Would you write an essay without an outline? You could do all of these things, but the results are guaranteed to be crap.