"the guy is a JOURNALIST not a scientist. (He may have a science degree but he acts as a journalist).
If a scientist had done this they would be losing their job any minute. Any of the following would be enough to disgrace a practicing scientist (I am one) [...] What it does reveal is that people cannot rely on popular press stories about science as journalist pay no attention to the important details of publications"
Have you paid attention to the references, you mister scientist?
At least one of the points of this Slashdot entry is that: a) You *can* have a scientist career breaking all the nice points you cite. b) It is not that people can't rely on popular press for science but that they can't rely on (open-access) scientific press either.
See an example:
"good news arrived in the inbox of Ocorrafoo Cobange, a biologist at the Wassee Institute of Medicine in Asmara. It was the official letter of acceptance for a paper he had submitted 2 months earlier to the Journal of Natural Pharmaceuticals" followed by " the Journal of Natural Pharmaceuticals. It describes itself as "a peer reviewed journal aiming to communicate high quality research articles, short communications, and reviews in the field of natural products with desired pharmacological activities." The editors and advisory board members are pharmaceutical science professors at universities around the world." and "In fact, it should have been promptly rejected [...] I know because I wrote the paper. Ocorrafoo Cobange does not exist, nor does the Wassee Institute of Medicine [...] More than half of the journals accepted the paper"
"Mostly not 'songs' though. A Mozart opera might be a couple of hours long, but the majority of the individual arias are probably under 5 minutes"
Yes, an arbitrary under-5-minutes cut of a longer composition, be it an opera, a sonate or a symphonic concert lasts, well uh, under 5 minutes.
The point is that when you think "opera", you are thinking "two hours"; when you think "concert", you are thinking "forty minutes"; when you think "sonate", you are thinking "twenty minutes"... heck, even if you think "lied" you go for good ten minutes.
And then, when you think "pop music", you think 2'40'' and it is because of technology.
" Characterizing them as pushing the "omg Terminator" line is just lowering the level of discourse here. That is clearly NOT what they are doing."
Are you sure?
"they are pointing out, rightfully so, that any entity much more intelligent than us, and with a goal set alien to us (like maximization of the number of paperclips in its collection) might as well be out to exterminate humanity"
'AI' means "Artificial Intelligence". The "Artificial" part means it's built by us, human beings, so there it goes the "alien goal". But, oh, you could tell that this AI, being selfconcious and autoevolutive, can develop its own goals... Tell me how that is *not* "omg Terminator" when we are today as far from artificial selfconciousness as we were back in Eliza's day.
And then, the "Intelligence" part means, well, it's not clear what it means but, in the end, it surely doesn't necessarily mean "MORE intelligent THAN US". And even then, one thing is planning for something, quite a different one achieving the intended goal. You see, we are to be considered more intelligent than cockroaches or mosquitoes and we certainly have gone the path of exterminating them (that it would be such a good idea is a different issue), but they are still there.
"because it will do so through simple outcompetition"
Yes, the Secret Council Of Mosquitoes And Cockroaches' fearmongering members also used that argument. But, letting aside the SCOMAC, it is not enough to have the intelligence to, and the goal of, eradicating humankind (both quite unplausible things as of now), you also need a viable interface to the real world, you know, these Terminators were real things, not just ones and zeroes, and that's why they can go overthere killing people.
In the end, we don't need to resort to an AI that it is as of now lightyears of being possible when we have true and tested nuclear arsenals that could achieve the same goal in a very humanly way.
So, yes, everything basically goes down to "omg Terminator".
"Not to mention the fact that he is funding MIRI. If you were giving millions of dollars to a research institute devoted to mitigating existential risk from AI, you would probably become pretty knowledgeable on the subject too."
Or you just demonstrated yourself to be gullible enough to give your money to a certain kind of snake-oil sellers after watching Terminator one time too many.
Remember that being outstanding in some fields doesn't preclude you to be stupid in others (specially when your previous success makes you think about yourself like some kind of infallible demi-god).
"This, of course, means we can use them in the same way you use a canary in a coal mine. If they all mysteriously end up dead at or around the same time, we know to be on the lookout for a murderous rogue AI bent on eliminating dissent."
Quite rite.
And, just for the record, I for one welcome our superior AI overlords.
"You know, if AI research suddenly gets heavily regulated or even banned, their jobs might fly away."
You know, if their jobs weren't heavily regulated they'd soon discover you (the repetitive Anonymous Coward going with the same boring arguments again and again in these comments) are nothing more than a trolling AI, and a lame attempt at it, and would return you to the dirty pits you belong.
"IBM's PC strategy from the mid '80s to mid '90s could be summed up as using their influence to prevent networking, multi-tasking and file permissions from happening on the same platform at the same time."
Of course yes.
That explains why in the mid '80s to mid 90's IBM was busy in a joint venture with Microsoft first and alone afterwards... to produce a PC system with networking, multi-tasking and file permissions and even 32 bits (OS/2).
"An ELE shows up about every 60 million years. If it kills 6 billion people, then that is on average 100 people per year, which is small, but still much larger than they imply."
It would directly kill those 6 billion but then, it would stop humanity from growing at least 25x that number (provided it takes 25 generations to rise back to 6 billions and that 6 billions is more or less the max capacity of the Earth). This would mean -as per your numbers, about 2500 people/year, and that is without taking into account the life standars for the survivors or if it doesn't manage to extinguish the species altogether.
Again a case of "methodology X" failing at delivering the expected but shinning at surfacing your company's misfunctions.
Agile, being about "Individuals and interactions over processes and tools" is specially good at that. The paradox is that sane companies would react at all that revealed insanity and would take the chance to correct themselves, which the only thing it's impossible to be done in the companies that show this kind of insanity.
"By definition, if can't fit into a single Sprint, then you cannot do it"
That's right.
But it works both ways: if there are things that cannot be fitted into a sprint, your sprints are too short.
Nobody is telling that a sprint have to be two weeks long. Sprints should be as long or short as to be able to accomodate a significant result. Sometimes this means one week, sometimes three months, sometimes this needs to change from sprint to sprint or at least to product-livecycle phase to phase. The only requirement is for the sprint's duration to be fixed beforehand.
"The report is required to be done by Dec 1"
That's an OK bussiness need -at least, when it really is a bussiness need and not just a date to add pressure to your team, but one that some if not most of agile *methodologies* (no a problem with agilism by itself) can cope with.
This only means that most probably this single request needs to be handed in a custom way: if the feature set is clear and fixed (and it probably is) even the charicaturesque version of waterfall-as-an-antipattern can perfectly work: you get the requirements, design the solution, asign a team for the expected time, test and deliver. I don't see what the problem can be with that -except, maybe, that the team needs to come from somewhere, probably the same team doing everything else, which would mean, say, no sprints for the next month, or a negotiation to push forward stories that don't requiere to be delivered by the people now reassigned to the report and if that's really the problem you are again failing on agilism, since one of its tenets is "Customer collaboration over contract negotiation": obviously, putting people to do "this" makes it impossible for that people doing "that" at the same time, so the customer needs to make up his priorities, or the team to be expanded at the risk of falling in "the mithycal man-month" trap.
"Our board has directed that we are required to do Agile, and the certified scrum master they hired wouldn't let us start on the report."
You see, "scrum" is not "agile" but an "agile methodology". Your "scrum master" looks to me more of a "scumbag master" than anything else, since he failed twofold: 1) Within scrum, "The Scrum Master serves as a facilitator for both the Product Owner and the team", which he obviously failed to be. 2) In the overall context of agilism: being scrum an *agile* methodology is naturally driven by agilism first, and that means "Working software" as well as "Responding to change" and he failed in both fields.
"Oh, don't let the devs add their own bugs or issues. Otherwise it will turn out that they have only been working on the tasks that they created internally."
Agree on that. At the very least, a developer-opened task would have to be agreed first with the customer or even created by the customer himself upon the developer's request.
"I came back 6 months later once only to find out..."
Your fail. If you had come back two weeks later instead of 6 months, you would have found much earlier. You know, "agile" is a burden for the customer as much as for the developer. You can't have "agile" without both of them.
You yourself say it afterwards: just call it "the issue tracker system" and you are done.
And, yes, it probably would work better than the average "agile in the forms, old school everywhere else" because, since most of the problems about agile come from people and culture clashes than anything else, having a simple and easily understandable means to produce a queue and track its evolution makes for a perfect start point that it is certainly fully aligned with the "agile manifesto".
Taking the first day's morning to explain the customer what "agile" entails, specially for him -and agree with him on doing it that way (or not, but then you are fred to go waterfall or anything else that better suits the scenario), and the evening to explain both customer and the internal team what DONE means, and a Redmine site for tracking customer-opened issues and the internal team-produced documentation should be more than enough on most cases.
But this is just too cheap and logical to gain traction.
"I end up being unable to do the tasks (stories) assigned during the development period (sprint)"
Bzzzt! Error!
Stories are not *assigned* to the sprint, they are *queued* for the sprint. It might look like splitting hairs, but it's far from that.
Part of the reason d'etre of agilims is that you don't have a crystal ball to see the future. Maybe your team's velocity is not well stablished, maybe you missed the complexity of the task... when planning a sprint you are not *commiting* to complete, say, these five stories, but agreing with your customer that these 1, 2, 3, 4, 5, 6, 7... stories are the most interesting right now and in that order, and that given your current knowledge about yours and your team's abilities and the complexity of the stories at hand you *probably* will be able to fulfill 1,2,3,4 and 5 of them by the end of current sprint.
Once again, the old problem: agile "processes" put on top of the old mentality -like trying those new dancing steps from charleston over the same old waltz. Funny results guaranteed!
"The real truth is that there are developers of different skills, and there are some that excel in specific areas while the rest plod along, and they are not interchangeable like Agile states"
Wait... what!?
You obviously don't know what you are talking about.
Why do you think "velocity" is not interchangeable and it is instead tied to a given group if people were interchangeable? Why do you think "velocity" evolution needs to be referenced just to a given team's history if it could be stated in advance?
"Individuals and interactions over processes and tools" is the first basic tenet of agilism. Why do you think "individuals" is the very first word of it if people were interchangeable and, thus, out of consideration?
"See? None of these involves requirement changing. How you can do waterfall in large projects worth millions is beyond my imagination..."
I see your point but I can't see its relationship with anything agile vs waterfall here. Nothing you talk is about your application's functional requirements so it doesn't even enter the agile realm.
"There is nothing about waterfall that requires you to make ironclad decisions at the very start"
Of course there is. Once the requirements phase is closed, it is closed. You can have iterative waterfall, but you need to wait for next iteration to alter requirements. You can have overlapping waterfall, but overlapping shouldn't make more than 10-20% of your gantt, and even then, at the cost of increasing at least on the same proportion your allowed cost/deadlines variances. In fact, the only guarantee for deliverability on waterfall comes from the fact that when a phase is closed, it's closed and you can't go back to it, which would add uncertainty to the process.
"The difference that I've seen in practice is that it's incredibly hard to implement Agile correctly"
It is, but that's the case because of the way companies are organized since Ford days: hierarchies, functional and responsability clear niches and boundaries, processes and bureaucracy, while agilism is about team playing, empowering people, planitude and results over processes and paper trails.
Agilism looks hard for too many companies the same way chess looks hard when you try to play it on a tennis field and with tennis rules.
"You are basically just saying that agile is more *fr*agile than waterfall"
It is, but then you need to add context to see what that really means.
Agile was always about empowering people over process and bureaucracy. If you are process and paper trail centered you are not doing agile. Full stop. Please, take your time to rumiate this.
Now let's imagine you really are embracing agile and let's think about your team's members (not only developers but management and even customers): is it really advantageous to empower them? Or is it like giving a loaded gun to a monkey? For one obvious thing, taken right from the agile manifesto "Customer collaboration over contract negotiation", will your customer abide to collaborate or will he want a full contract with all things strongly tied -costs, deadlines, features... by day one? Because if it's the latter, you can forget about agile right on the starting line, you see...
Now, on waterfall: of course it is more solid and efficient than agile... provided the customer (be it internal or external) perfectly understands his needs, is perfectly able to transmit them, their needs are perfectly understood and expressed formally on paper, they are agreed back by customer and you have an experienced enough team all across without a hidden agenda.
Failing anything in the list above, waterfall not only tends to quickly fall apart, but doing so in very expensive and notorious ways that agile mentality (in any of its incarnations) provide checks and balances against (but first you need to take the time to understand what is all this stuff about).
Now that I reread what I wrote, find it similar to the republic ideal: it works because its checks and balances, but obviously they only add more moving parts (thus fragility) and unefficiencies... if only everything worked as hoped.
No, it isn't. Adding functionality to a new environment is not support.
"While I understand that perpetual support for older devices is not viable"
And then, wrong again. Given support for what it is, the ability to substitute broken parts and correct what was not working from the very begining should be supported basically forever, much more so for software, since software doesn't have wearing parts.
Heck, I have no problem finding parts for my 15 y.o. car but still my printer can't be the same?
Slashdot Mirror
"the guy is a JOURNALIST not a scientist. (He may have a science degree but he acts as a journalist).
If a scientist had done this they would be losing their job any minute. Any of the following would be enough to disgrace a practicing scientist (I am one)
[...]
What it does reveal is that people cannot rely on popular press stories about science as journalist pay no attention to the important details of publications"
Have you paid attention to the references, you mister scientist?
At least one of the points of this Slashdot entry is that:
a) You *can* have a scientist career breaking all the nice points you cite.
b) It is not that people can't rely on popular press for science but that they can't rely on (open-access) scientific press either.
See an example:
"good news arrived in the inbox of Ocorrafoo Cobange, a biologist at the Wassee Institute of Medicine in Asmara. It was the official letter of acceptance for a paper he had submitted 2 months earlier to the Journal of Natural Pharmaceuticals" followed by " the Journal of Natural Pharmaceuticals. It describes itself as "a peer reviewed journal aiming to communicate high quality research articles, short communications, and reviews in the field of natural products with desired pharmacological activities." The editors and advisory board members are pharmaceutical science professors at universities around the world." and "In fact, it should have been promptly rejected [...] I know because I wrote the paper. Ocorrafoo Cobange does not exist, nor does the Wassee Institute of Medicine [...] More than half of the journals accepted the paper"
"It has long been established that mainstream media will publish anything, I don't think anybody with an IQ above 100 was not aware."
So you thing that about half the people is not aware? That's still a lot of people.
"Mostly not 'songs' though. A Mozart opera might be a couple of hours long, but the majority of the individual arias are probably under 5 minutes"
Yes, an arbitrary under-5-minutes cut of a longer composition, be it an opera, a sonate or a symphonic concert lasts, well uh, under 5 minutes.
The point is that when you think "opera", you are thinking "two hours"; when you think "concert", you are thinking "forty minutes"; when you think "sonate", you are thinking "twenty minutes"... heck, even if you think "lied" you go for good ten minutes.
And then, when you think "pop music", you think 2'40'' and it is because of technology.
" Characterizing them as pushing the "omg Terminator" line is just lowering the level of discourse here. That is clearly NOT what they are doing."
Are you sure?
"they are pointing out, rightfully so, that any entity much more intelligent than us, and with a goal set alien to us (like maximization of the number of paperclips in its collection) might as well be out to exterminate humanity"
'AI' means "Artificial Intelligence". The "Artificial" part means it's built by us, human beings, so there it goes the "alien goal". But, oh, you could tell that this AI, being selfconcious and autoevolutive, can develop its own goals... Tell me how that is *not* "omg Terminator" when we are today as far from artificial selfconciousness as we were back in Eliza's day.
And then, the "Intelligence" part means, well, it's not clear what it means but, in the end, it surely doesn't necessarily mean "MORE intelligent THAN US". And even then, one thing is planning for something, quite a different one achieving the intended goal. You see, we are to be considered more intelligent than cockroaches or mosquitoes and we certainly have gone the path of exterminating them (that it would be such a good idea is a different issue), but they are still there.
"because it will do so through simple outcompetition"
Yes, the Secret Council Of Mosquitoes And Cockroaches' fearmongering members also used that argument. But, letting aside the SCOMAC, it is not enough to have the intelligence to, and the goal of, eradicating humankind (both quite unplausible things as of now), you also need a viable interface to the real world, you know, these Terminators were real things, not just ones and zeroes, and that's why they can go overthere killing people.
In the end, we don't need to resort to an AI that it is as of now lightyears of being possible when we have true and tested nuclear arsenals that could achieve the same goal in a very humanly way.
So, yes, everything basically goes down to "omg Terminator".
"Why do you assume that the comments against AI must come from the same person?"
Because I'm a HI. Being good at assumptions is a quite successful evolutionary trait in our species.
I'm, of course, not saying that all AC comments come from the very same person but that an obvious subset of them do.
"Not to mention the fact that he is funding MIRI. If you were giving millions of dollars to a research institute devoted to mitigating existential risk from AI, you would probably become pretty knowledgeable on the subject too."
Or you just demonstrated yourself to be gullible enough to give your money to a certain kind of snake-oil sellers after watching Terminator one time too many.
Remember that being outstanding in some fields doesn't preclude you to be stupid in others (specially when your previous success makes you think about yourself like some kind of infallible demi-god).
"This, of course, means we can use them in the same way you use a canary in a coal mine. If they all mysteriously end up dead at or around the same time, we know to be on the lookout for a murderous rogue AI bent on eliminating dissent."
Quite rite.
And, just for the record, I for one welcome our superior AI overlords.
"You know, if AI research suddenly gets heavily regulated or even banned, their jobs might fly away."
You know, if their jobs weren't heavily regulated they'd soon discover you (the repetitive Anonymous Coward going with the same boring arguments again and again in these comments) are nothing more than a trolling AI, and a lame attempt at it, and would return you to the dirty pits you belong.
"IBM's PC strategy from the mid '80s to mid '90s could be summed up as using their influence to prevent networking, multi-tasking and file permissions from happening on the same platform at the same time."
Of course yes.
That explains why in the mid '80s to mid 90's IBM was busy in a joint venture with Microsoft first and alone afterwards... to produce a PC system with networking, multi-tasking and file permissions and even 32 bits (OS/2).
Or maybe you are wrong.
"An ELE shows up about every 60 million years. If it kills 6 billion people, then that is on average 100 people per year, which is small, but still much larger than they imply."
It would directly kill those 6 billion but then, it would stop humanity from growing at least 25x that number (provided it takes 25 generations to rise back to 6 billions and that 6 billions is more or less the max capacity of the Earth). This would mean -as per your numbers, about 2500 people/year, and that is without taking into account the life standars for the survivors or if it doesn't manage to extinguish the species altogether.
"It's good to have a healthy fear of asterisks -- there's a big difference between "rm -rf *.tmp" and "rm -rf * .tmp"
But surely the space is the villain there."
No, no... it is the asterisk coming from the spaces.
Yes.
Again a case of "methodology X" failing at delivering the expected but shinning at surfacing your company's misfunctions.
Agile, being about "Individuals and interactions over processes and tools" is specially good at that.
The paradox is that sane companies would react at all that revealed insanity and would take the chance to correct themselves, which the only thing it's impossible to be done in the companies that show this kind of insanity.
"Because it sounds good?"
No. Because it is about individuals, not unfaced meatballs.
"By definition, if can't fit into a single Sprint, then you cannot do it"
That's right.
But it works both ways: if there are things that cannot be fitted into a sprint, your sprints are too short.
Nobody is telling that a sprint have to be two weeks long. Sprints should be as long or short as to be able to accomodate a significant result. Sometimes this means one week, sometimes three months, sometimes this needs to change from sprint to sprint or at least to product-livecycle phase to phase. The only requirement is for the sprint's duration to be fixed beforehand.
"The report is required to be done by Dec 1"
That's an OK bussiness need -at least, when it really is a bussiness need and not just a date to add pressure to your team, but one that some if not most of agile *methodologies* (no a problem with agilism by itself) can cope with.
This only means that most probably this single request needs to be handed in a custom way: if the feature set is clear and fixed (and it probably is) even the charicaturesque version of waterfall-as-an-antipattern can perfectly work: you get the requirements, design the solution, asign a team for the expected time, test and deliver. I don't see what the problem can be with that -except, maybe, that the team needs to come from somewhere, probably the same team doing everything else, which would mean, say, no sprints for the next month, or a negotiation to push forward stories that don't requiere to be delivered by the people now reassigned to the report and if that's really the problem you are again failing on agilism, since one of its tenets is "Customer collaboration over contract negotiation": obviously, putting people to do "this" makes it impossible for that people doing "that" at the same time, so the customer needs to make up his priorities, or the team to be expanded at the risk of falling in "the mithycal man-month" trap.
"Our board has directed that we are required to do Agile, and the certified scrum master they hired wouldn't let us start on the report."
You see, "scrum" is not "agile" but an "agile methodology". Your "scrum master" looks to me more of a "scumbag master" than anything else, since he failed twofold:
1) Within scrum, "The Scrum Master serves as a facilitator for both the Product Owner and the team", which he obviously failed to be.
2) In the overall context of agilism: being scrum an *agile* methodology is naturally driven by agilism first, and that means "Working software" as well as "Responding to change" and he failed in both fields.
"Oh, don't let the devs add their own bugs or issues. Otherwise it will turn out that they have only been working on the tasks that they created internally."
Agree on that. At the very least, a developer-opened task would have to be agreed first with the customer or even created by the customer himself upon the developer's request.
"I came back 6 months later once only to find out..."
Your fail. If you had come back two weeks later instead of 6 months, you would have found much earlier. You know, "agile" is a burden for the customer as much as for the developer. You can't have "agile" without both of them.
"the bugtracker agile system."
You yourself say it afterwards: just call it "the issue tracker system" and you are done.
And, yes, it probably would work better than the average "agile in the forms, old school everywhere else" because, since most of the problems about agile come from people and culture clashes than anything else, having a simple and easily understandable means to produce a queue and track its evolution makes for a perfect start point that it is certainly fully aligned with the "agile manifesto".
Taking the first day's morning to explain the customer what "agile" entails, specially for him -and agree with him on doing it that way (or not, but then you are fred to go waterfall or anything else that better suits the scenario), and the evening to explain both customer and the internal team what DONE means, and a Redmine site for tracking customer-opened issues and the internal team-produced documentation should be more than enough on most cases.
But this is just too cheap and logical to gain traction.
"I end up being unable to do the tasks (stories) assigned during the development period (sprint)"
Bzzzt! Error!
Stories are not *assigned* to the sprint, they are *queued* for the sprint. It might look like splitting hairs, but it's far from that.
Part of the reason d'etre of agilims is that you don't have a crystal ball to see the future. Maybe your team's velocity is not well stablished, maybe you missed the complexity of the task... when planning a sprint you are not *commiting* to complete, say, these five stories, but agreing with your customer that these 1, 2, 3, 4, 5, 6, 7... stories are the most interesting right now and in that order, and that given your current knowledge about yours and your team's abilities and the complexity of the stories at hand you *probably* will be able to fulfill 1,2,3,4 and 5 of them by the end of current sprint.
Once again, the old problem: agile "processes" put on top of the old mentality -like trying those new dancing steps from charleston over the same old waltz. Funny results guaranteed!
"The real truth is that there are developers of different skills, and there are some that excel in specific areas while the rest plod along, and they are not interchangeable like Agile states"
Wait... what!?
You obviously don't know what you are talking about.
Why do you think "velocity" is not interchangeable and it is instead tied to a given group if people were interchangeable? Why do you think "velocity" evolution needs to be referenced just to a given team's history if it could be stated in advance?
"Individuals and interactions over processes and tools" is the first basic tenet of agilism. Why do you think "individuals" is the very first word of it if people were interchangeable and, thus, out of consideration?
"See? None of these involves requirement changing. How you can do waterfall in large projects worth millions is beyond my imagination..."
I see your point but I can't see its relationship with anything agile vs waterfall here. Nothing you talk is about your application's functional requirements so it doesn't even enter the agile realm.
"There is nothing about waterfall that requires you to make ironclad decisions at the very start"
Of course there is. Once the requirements phase is closed, it is closed. You can have iterative waterfall, but you need to wait for next iteration to alter requirements. You can have overlapping waterfall, but overlapping shouldn't make more than 10-20% of your gantt, and even then, at the cost of increasing at least on the same proportion your allowed cost/deadlines variances. In fact, the only guarantee for deliverability on waterfall comes from the fact that when a phase is closed, it's closed and you can't go back to it, which would add uncertainty to the process.
"The difference that I've seen in practice is that it's incredibly hard to implement Agile correctly"
It is, but that's the case because of the way companies are organized since Ford days: hierarchies, functional and responsability clear niches and boundaries, processes and bureaucracy, while agilism is about team playing, empowering people, planitude and results over processes and paper trails.
Agilism looks hard for too many companies the same way chess looks hard when you try to play it on a tennis field and with tennis rules.
"You are basically just saying that agile is more *fr*agile than waterfall"
It is, but then you need to add context to see what that really means.
Agile was always about empowering people over process and bureaucracy. If you are process and paper trail centered you are not doing agile. Full stop. Please, take your time to rumiate this.
Now let's imagine you really are embracing agile and let's think about your team's members (not only developers but management and even customers): is it really advantageous to empower them? Or is it like giving a loaded gun to a monkey? For one obvious thing, taken right from the agile manifesto "Customer collaboration over contract negotiation", will your customer abide to collaborate or will he want a full contract with all things strongly tied -costs, deadlines, features... by day one? Because if it's the latter, you can forget about agile right on the starting line, you see...
Now, on waterfall: of course it is more solid and efficient than agile... provided the customer (be it internal or external) perfectly understands his needs, is perfectly able to transmit them, their needs are perfectly understood and expressed formally on paper, they are agreed back by customer and you have an experienced enough team all across without a hidden agenda.
Failing anything in the list above, waterfall not only tends to quickly fall apart, but doing so in very expensive and notorious ways that agile mentality (in any of its incarnations) provide checks and balances against (but first you need to take the time to understand what is all this stuff about).
Now that I reread what I wrote, find it similar to the republic ideal: it works because its checks and balances, but obviously they only add more moving parts (thus fragility) and unefficiencies... if only everything worked as hoped.
"I've been learning to appreciate older stuff as I've gotten older"
Good. By the day you get retired you might reach master Monteverdi.
"still most music is base on repeating over and over again."
I know what you mean: Wagner -> Mahler -> Bruckner
"Of course, we're not going to do anything about the problem. Of course not."
[ironic]
Well, I used to be a denialist that thought there were nothing needed to do, because there was no problem.
But now, I'm convinced: there is a climate change and it is pushed forward by humankind.
Unfortunately, it's too late to avoid it, so I'll do nothing either.
[/ironic]
"It is called support service"
No, it isn't. Adding functionality to a new environment is not support.
"While I understand that perpetual support for older devices is not viable"
And then, wrong again. Given support for what it is, the ability to substitute broken parts and correct what was not working from the very begining should be supported basically forever, much more so for software, since software doesn't have wearing parts.
Heck, I have no problem finding parts for my 15 y.o. car but still my printer can't be the same?