191–200 of 319 posts
Earlier quoted context omitted.
This is just "communism can never fail, it can only be failed" but for Waterfall.
Inasmuch as software development and communism are both social services , yes. Bad software fails to deliver on the social promise. As does any particularly bad political philosophy.
I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…
You can't - Get Certified in Waterfall. - Claim to be a Waterfall Master. - Waterfall Standup sounds like a song.
TLC actually did record a (correct) song about it:
In my few years working as a dev, I am absolutely convinced that scrum and agile are the worst possible development practices you can have from the perspective of a developer, even though they are sold as 'developer centric' or that seems to be the impression a lot of people have at least. It makes no sense at all to me to constantly have work interrupted with customer meetings that produce NO concrete specifications…
It makes a lot of sense, which is why a lot of people follow it. Your comment is implying that somehow 1000s of people around the world don't realise they are doing something stupid. You are portraying a poorly run implementation of agile as the only way and then destroying it. We call it a straw-man. * My development team are rarely interuppted with customer meetings * The meetings we have will always have outcomes,…
I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…
If you break that natural process down and apply it to subcomponents and have releases every few months, you're doing something like either the classical Iterative & Incremental or Evolutionary models which are longer cycle versions of what Scrum aims for (which as a target tries to get you under one month, maybe down to 1-2 week cycles). I&I and Evolutionary tend to operate with cycles from 3-6 months.
Is is often forgotten that the efficiency of the individual is not the same thing as the efficiency of the team. Understand this and the case for waterfall is weakened, perhaps fatally.
Earlier quoted context omitted.
Read the original paper [1]. By definition, treating the steps as iterative is a recommended practice. [1] http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...
I don't get the point of Figure 4 in the .pdf, I see htat and I hear process process process, don't skip process even when it makes no sense. You can actually tell that the methodology was developed for a different time period, when you would have to schedule time in order to run your program on the mainframe, instead of just hitting build on your machine.
Ex: Testing reveals a corner-case that was never accounted for in the design. You can't just re-code, you have to go back up and redesign, then code the new design, then retest.
Royce's recommendations to minimize these problems are a) more and better design, and b) more and better documentation
In contrast, the Agile approach is to try to slice the work into finer and finer tasks, so these same activities can span a few sprints. It works in the small, but loses the forest for the trees.
In my few years working as a dev, I am absolutely convinced that scrum and agile are the worst possible development practices you can have from the perspective of a developer, even though they are sold as 'developer centric' or that seems to be the impression a lot of people have at least. It makes no sense at all to me to constantly have work interrupted with customer meetings that produce NO concrete specifications…
It makes a lot of sense, which is why a lot of people follow it. Your comment is implying that somehow 1000s of people around the world don't realise they are doing something stupid. You are portraying a poorly run implementation of agile as the only way and then destroying it. We call it a straw-man. * My development team are rarely interuppted with customer meetings * The meetings we have will always have outcomes,…
I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these ste…
I always saw agile as essentially breaking waterfall into mini waterfalls.
Agile&scrum are internally inconsistent methodologies which means that a bad faith actor (be it a smart but asshole engineer or clueless boss) can always point out you are doing something wrong (against the theory), regardless of the flavour/school you are using.
Earlier quoted context omitted.
> > You cannot analyse how users will empirically interact with a product that does not yet exist. You can certainly refine the software over time (A/B testing, if you will) to more closely attain the ideal, which you may not have well defined at the beginning of the project if you don't perform an adequate review of the needs of the user. But you can certainly also complete a user analysis that produces requirements…
Wait a minute, you're a proponent of iterative approaches? In modern parlance most people put under the heading "waterfall". Can you specify which book/process/document(s) you are using in your day-to-day? This could be very interesting in future discussions with clients, to say the least!