Undoubtedly. Critical mass/network effect is nothing to sneeze at. People can use more than one social networking site though, so total lock-in is never really possible. It will be fun to see what happens.
Yeah, he did nothing with it. I think it was really just not worth anything. Their platform was half-assed and they were bound to get eaten by any of the other players. The guy definitely played it well.
G+ is less designed around getting everyone to join and more around actually communicating. You can put people in your circles that are just email contacts. They'll get invited of course, but you can happily post things to them. I get what you're saying though. FB is conceptually easier to wrap your head around in a sense.
They will both do grouping, the g+ version is just infinitely easier to deal with. I guess FB has been working on that, but honestly I only use it myself basically so I can actually see all the messages that people I know mysteriously seem to think that posting to FB will magically get to everyone. FB is OK, G+ is definitely nicer in most ways.
Of course MySpace REALLY just went noplace in terms of creating features. They piddled around but it was like everything was user interface nuclear disaster. It was the ugliest site in history. I guess FB COULD screw up that bad. I think they probably won't. They'll screw up a little bit, but so will Google.
Is this like some sort of Google ad? I dunno. I like G+ too, but it is a little hard to use in the ways that you can use FB when people just don't do a lot with it. Maybe they'll hit some sort of critical mass? I'd like that, but...
Sure, so the question is what process generally gives the overall best results for the people that are actually out there needing to get stuff done. We can all wish for hot shot developers and dream clients, but we won't get them.
IMHO Agile projects fail less, fail less dramatically, and carry lower risk than waterfall projects. They also can, if used properly, foster good habits, learning, and development. You may not be able to hire the best developers all the time, but if you can make the bad ones acceptable and the decent ones 90% as good as the natural at what you need them to do, then you're ahead of the curve and you'll beat the competition.
I don't know what you're trying to get at. If someone wants me to come in and set up a development team for whatever reason, then establishing a CI process is part of that and thus I might bill someone for that. However, setting up a CI process is not part of a specific project, in general. I might bill this kind of thing under G&A of a project. It won't be in the backlog of the project. Neither will doing CI because that's just something you do in the normal course. You don't put "set up text editor" in your backlog either.
And yes, you might NOT use a CI tool, or at least your process might not be quite in those terms. For instance the process we use internally for product development uses our own custom build tool We do use it for CI, but it happens in a more organic way, there's no specific tool that is the CI tool. The build tool we use can accomplish the things that CI requires, and has other functions as well. I'd say this is typical, there's no one mapping of process to tool that is universal.
Knowledge and commitment are wonderful things, and without tools and process they mean nothing. Clearly at some point tools and process have to be established. I just don't see what point you are trying to make by asking where it shows up on a project plan. IMHO by the time you get to doing the project you better already have that stuff done.
I don't know all the details of the processes that are used in every place and claimed to be 'Agile', there's all types out there and some are idiots or shysters. At least when you interact with MY process there will be some meetings with the client. The exact details of the product of that can depend on the scope and degree of definition of the project. A client that has its own processes in place and has generated formal requirements is going to be easier to deal with. One that has an itch that has to be scratched and a general basic idea of what they need will require more interaction. Either way we're going to break things down into user stories, probably supplemented by additional material where complex requirements are involved. In ALL cases the customer is going to help decide what each iteration delivers. While many people may THINK they know exactly what they want, it is a surety that some details change, some things haven't been considered, and possibilities for improvements, simplifications, etc will come to light during the process.
I mean, I've put software into space, on mission critical safety of flight level equipment. Even when working with Martin, Boeing, NASA, etc where they have comprehensive SDDs and SRDs written in highly formal language things are never 100% perfectly sorted out. You can have a 1000 page spec that goes into vast detail and will be translated into 6k lines of code, and even then there is ambiguity and need for interaction with the client. There's simply no such thing as cut and dried, ever.
I think the thing is that really good crackerjack developers are hard to keep around. There's very high demand and high prices. Many businesses cannot or will not pay what they need to pay to get them, and in fact a lot of businesses really aren't doing something sexy enough that someone who could work on cutting edge stuff is going to stick with, at least not unless they're handled quite well.
So, yeah, most teams are going to be made up of some mix of good, bad, and ugly. I agree that there's no silver bullet, etc. The thing is lots of places just don't have the choice of "get good developers working productively" because they might have one or two good developers and ten bad/ugly ones. You need to bring those up to usable status. Frankly my answer is get in a good process consultant, but it is also pretty hard to find one of those... lol.
Frankly software and humans don't mix well. I think we'll have bad software until we invent some AI to write it for us (but that AI will be bad human-written software...). lol. Best you can do is if something is REALLY important, like flight control software (or for instance the self-destruct device for a large commercial booster, which I once wrote some of the firmware for) then you can get pretty decent quality, but it is hugely expensive. That box had about 6k lines of code in it and the software cost was well into the millions...
Why would a Jenkins deployment be in the backlog? If you don't have a CI system, or can't put one together as part of your tooling, what makes you think you're qualified to be doing software development on anything but the smallest scale? Would you hire a plumber if he put a line item on his project estimate "buy tool box"???
The point stands, you don't do Agile by doing big-bang integration at the end. Clearly on a daily check-in basis you can have integration problems, just routine. You should always be no more than a day ahead of the last time you ran a full set of integration tests. If you're not doing that you're wasting time and money. The poster who talked about his problems with integrating at the end was thus AFAICT not doing Agile and thus his complaints about Agile are irrelevant. If he doesn't have a CI tool he's not even a professional at any level where talking about engineering process is meaningful.
Lets suppose you're a business and you want to build a manufacturing facility that will cost you say $500k. That's a pretty substantial investment. You're telling me you're just going to hand $500k to some GC and say "hey, build me an XYZ on this plot of land" and you expect to walk away and come back in 6 months and magically have something that exactly does what you want?
No, you're going to supervise, and inspect, and you're going to work with the GC and the architect, and the people installing the machinery, and the power company, and all those other people. You simply CANNOT expect a complex project to succeed without that level of constant interaction, cross checking, making sure that when the utility entrance can't be on the west side because the power company will only put the substation on the east side that things still work out. It just doesn't happen by magic.
If you think somehow that a software project isn't EVEN MORE this way than a conventional construction project then you're monumentally misinformed about how things work and frankly you should buy OTS software because anything beyond the most trivial projects WILL fail if you approach them this way. I've been doing this stuff for 30+ years, and I say this with the utmost certainty. In fact, since I have plenty of business from sensible customers, I wouldn't even do business with someone that demonstrated your attitude. You're not worth the trouble. You're a lawsuit or at least a broken project waiting to happen.
Right out of my mouth. You're NOT DOING AGILE if you have to integrate components at the end.
Also, the idea is not "we can just recode everything at the end", the idea is "only code now what you need right now", so yes, you will refactor, but that refactoring is an ongoing part of the process that is informed by 2 things, continuous integration and user acceptance testing.
IMHO one of the MAIN reasons why people will fail with Agile is that they ignore the requirement to have the customer/stake-holders right there in the process. If you actually PAY ATTENTION to the things that Agile is telling you to do (personally I find XP type process to be the most effective) then you can make it work. Everyone needs to understand the value of the parts, and as any Agile expert will tell you ALL the pieces are important. It is not at all interesting news for someone to tell me that if you fuck up and ignore half the pieces of the process that the other half don't magically just work.
No one development methodology is a panacea of course, but this report seems to be meaningless criticism based on not actually understanding how and why to use Agile.
Mars seems to me to be indeed "a planet too far" at this point. Give us 50 or so years of operational experience on the Moon, then it will be a lot more sensible plan.
This is so way super optimistic pie-in-the-sky it is not even funny. There's 50 or 100 years worth of engineering work blocked out here and a couple $100 billion in R&D, and they have 10 years and $6 billion... I guess it just shows you can convince yourself of almost anything if you try hard enough...
Space grade solar arrays are actually more in the 40% efficiency range. Toss another 10 years worth of R&D on that, so I think your numbers are fairly pessimistic. Not that I'm convinced you can grow food on Mars. You probably can. The chances of getting it right the first time around seem rather low though. Only a small number of things have to go wrong for it to fail, and then you're toast. Any unknown contaminant, a vital nutrient that fails to be recycled quite efficiently enough, unknown effects of low gravity, radiation, god knows what. It is the unknown unknowns that will probably kill you on this one, and we don't even have a clue how big those are.
The whole plan is beyond high risk. It seems almost bound to fail simply on the basis of piling up bad probabilities. Growing food might not be the Achilles heel of the whole thing, but it sure does seem like one of the most likely medium term failure modes.
I think you're right. The real long-term problem though is just general viability. You only have to be a little bit wrong in how things work on Mars and your colony is dead. With no manufacturing capability, very limited resources, accidents, stuff wearing out and breaking, etc even if you have a pretty good idea about how to do all this stuff you're VERY likely to fail, and probably for some stupid reason that nobody even thought of. Any such 'glitch' is going to be quite hard to recover from too considering that you've got to ship equipment from Earth.
The thing is, people aren't really considering the duration of this thing. You're going to send healthy, and probably fairly young people to Mars. They aren't going to be there for a couple years, or a decade, they're going to have to survive for what, 40 years? At least? Sure, in theory you send more stuff, but honestly nobody has a blinking clue what it takes to live on Mars for 40 years.
Beyond that, why? What is the real LONG TERM basis for a colony? It is surely going to take decades, maybe centuries for such a colony to become self-sufficient. Surely reality TV is not going to cut it on mission year 97. There's "science" up to a certain point, and there's "adventure" up to a certain point, but crud, a colony that far distant from Earth, on an utterly hostile and largely barren world? Its not like there are valuable resources on Mars that would EVER be worth shipping back to Earth. There's only so much Mars science that is worth the cost, etc.
Humanity's record in terms of supporting distant non-commercially-viable colonies ON EARTH is pretty dismal. Its hard to believe that any colony such as this, if you even managed to survive at all to start with, seems quite dim.
lol, yeah, no. You're correct that KE = m/2 v^2, but the proper consideration is momentum. If what you're saying were true then an object falling towards the surface of the Earth under the influence of gravity would accelerate more slowly the faster it went, which is plainly contrary to actual observation. The "kicking off" argument used below doesn't work either because this applies both to the train and the passenger AND TO THE EARTH. The same is true of an object freefalling. Not only does the object fall to Earth, but the Earth free falls in the object's gravity as well. There's ALWAYS action/reaction.
Yeah, definitely. It is a tough problem. I guess all we can do is keep our fingers crossed and keep electing people that see the problem and will continue a policy of nuclear arms reduction. I pretty much assume they're never going away (unless we invent something even scarier) but if we got to a point where the great powers have a handful of bombs each we might work it out. All agree to put them on low low readiness and some day perhaps we'll learn to settle differences without making threats. Kinda optimistic perhaps, but so it goes.
I think anyone would do it when looked at from a purely selfish point of view. The problem is that nuclear weapons are a prisoner's dilemma. There's no payoff better than long-term mutual annihilation that doesn't involve everyone giving up the sure payoff in the short term.
The ULTIMATE and fundamental problem with Waltz's analysis is the end result IS annihilation. While we don't know the exact risk of nuclear war per unit time we can deduce from first principles and observation that it is non-zero. We can deduce further that it increases as the number of nuclear states increases. Thus given enough time it will happen, and given more proliferation it will surely happen more swiftly.
And lets not kid ourselves, there are very few SURVIVABLE nuclear war scenarios. Even modeling of limited exchanges by regional powers like India and Pakistan show incredible damage, probably enough to collapse all of modern technological civilization. The odds of any of the people in this forum surviving such an occurrence, of ANYONE YOU KNOW surviving it, are poor to say the least. Even very optimistically you're looking at a death toll of something like 1 billion people in the immediate aftermath. That dwarfs all the wars we can even imagine, let alone any that Waltz can optimistically assume have been prevented.
Waltz is just wrong. Very wrong. The scary part is his argument is one that is a very convenient justification for the short term selfish behavior of the people who could decide to end the madness.
That comes with age. There's also a certain level of need to just get stuff done. At a certain point USING knowledge becomes the overriding concern, and you have so many tools in your toolbox that one more becomes less and less useful. You also begin to find that there's very little that is really new under the Sun in most fields. As a software engineer I see fads in languages, dev tools, databases, etc, and hear all about how some new guy is sure that it is a whole new revolutionary better way to do stuff. Often some new tool IS useful, but it is also often something that existed 30 years ago that everyone has just sort of forgotten about and it got renamed/reinvented and we long ago learned what its limitations were and moved on to other things (probably when we were 24 or so...).
There's also a certain factor of luck in terms of poking around at stuff. Yeah, you did debug something in a snap, which is good, congrats. OTOH I might look over your shoulder tomorrow and spot something you missed too. I don't know the guys you work with, but they probably managed before. Maybe they're bumblers, and maybe they just missed something. Ironically the more secure you become in your knowledge the easier it can be to miss some small detail that you 'know'. Today I was totally thwarted by some stupid piece of bad design in python that caused a webapp I was deploying to balk at reading a file. My associate figured it out, somehow. Python's split() function is just stupidly designed. Being an old Perl guy from way back I assumed NOBODY could be that stupid, but yes they can! He doesn't know perl from beans and thus less knowledge = solution. Ironic, but it goes that way sometimes.
One thing is for sure. I learned back around 26 not to be cocky, lol. That's a danger to avoid. Maybe I'm hot shit, but I never ever speak ill of anyone or brag about anything nowadays. It works. Only the VERY best of the best get away with the cocky routine for long...;) (not saying you're cocky, just remember not to get that way).
Slashdot Mirror
Undoubtedly. Critical mass/network effect is nothing to sneeze at. People can use more than one social networking site though, so total lock-in is never really possible. It will be fun to see what happens.
Yeah, you got me there. Geoshitties was pretty bad. I guess I'd wiped it from my brain...
Yeah, he did nothing with it. I think it was really just not worth anything. Their platform was half-assed and they were bound to get eaten by any of the other players. The guy definitely played it well.
G+ is less designed around getting everyone to join and more around actually communicating. You can put people in your circles that are just email contacts. They'll get invited of course, but you can happily post things to them. I get what you're saying though. FB is conceptually easier to wrap your head around in a sense.
They will both do grouping, the g+ version is just infinitely easier to deal with. I guess FB has been working on that, but honestly I only use it myself basically so I can actually see all the messages that people I know mysteriously seem to think that posting to FB will magically get to everyone. FB is OK, G+ is definitely nicer in most ways.
Of course MySpace REALLY just went noplace in terms of creating features. They piddled around but it was like everything was user interface nuclear disaster. It was the ugliest site in history. I guess FB COULD screw up that bad. I think they probably won't. They'll screw up a little bit, but so will Google.
Is this like some sort of Google ad? I dunno. I like G+ too, but it is a little hard to use in the ways that you can use FB when people just don't do a lot with it. Maybe they'll hit some sort of critical mass? I'd like that, but...
Sure, so the question is what process generally gives the overall best results for the people that are actually out there needing to get stuff done. We can all wish for hot shot developers and dream clients, but we won't get them.
IMHO Agile projects fail less, fail less dramatically, and carry lower risk than waterfall projects. They also can, if used properly, foster good habits, learning, and development. You may not be able to hire the best developers all the time, but if you can make the bad ones acceptable and the decent ones 90% as good as the natural at what you need them to do, then you're ahead of the curve and you'll beat the competition.
I don't know what you're trying to get at. If someone wants me to come in and set up a development team for whatever reason, then establishing a CI process is part of that and thus I might bill someone for that. However, setting up a CI process is not part of a specific project, in general. I might bill this kind of thing under G&A of a project. It won't be in the backlog of the project. Neither will doing CI because that's just something you do in the normal course. You don't put "set up text editor" in your backlog either.
And yes, you might NOT use a CI tool, or at least your process might not be quite in those terms. For instance the process we use internally for product development uses our own custom build tool We do use it for CI, but it happens in a more organic way, there's no specific tool that is the CI tool. The build tool we use can accomplish the things that CI requires, and has other functions as well. I'd say this is typical, there's no one mapping of process to tool that is universal.
Knowledge and commitment are wonderful things, and without tools and process they mean nothing. Clearly at some point tools and process have to be established. I just don't see what point you are trying to make by asking where it shows up on a project plan. IMHO by the time you get to doing the project you better already have that stuff done.
I don't know all the details of the processes that are used in every place and claimed to be 'Agile', there's all types out there and some are idiots or shysters. At least when you interact with MY process there will be some meetings with the client. The exact details of the product of that can depend on the scope and degree of definition of the project. A client that has its own processes in place and has generated formal requirements is going to be easier to deal with. One that has an itch that has to be scratched and a general basic idea of what they need will require more interaction. Either way we're going to break things down into user stories, probably supplemented by additional material where complex requirements are involved. In ALL cases the customer is going to help decide what each iteration delivers. While many people may THINK they know exactly what they want, it is a surety that some details change, some things haven't been considered, and possibilities for improvements, simplifications, etc will come to light during the process.
I mean, I've put software into space, on mission critical safety of flight level equipment. Even when working with Martin, Boeing, NASA, etc where they have comprehensive SDDs and SRDs written in highly formal language things are never 100% perfectly sorted out. You can have a 1000 page spec that goes into vast detail and will be translated into 6k lines of code, and even then there is ambiguity and need for interaction with the client. There's simply no such thing as cut and dried, ever.
I think the thing is that really good crackerjack developers are hard to keep around. There's very high demand and high prices. Many businesses cannot or will not pay what they need to pay to get them, and in fact a lot of businesses really aren't doing something sexy enough that someone who could work on cutting edge stuff is going to stick with, at least not unless they're handled quite well.
So, yeah, most teams are going to be made up of some mix of good, bad, and ugly. I agree that there's no silver bullet, etc. The thing is lots of places just don't have the choice of "get good developers working productively" because they might have one or two good developers and ten bad/ugly ones. You need to bring those up to usable status. Frankly my answer is get in a good process consultant, but it is also pretty hard to find one of those... lol.
Frankly software and humans don't mix well. I think we'll have bad software until we invent some AI to write it for us (but that AI will be bad human-written software...). lol. Best you can do is if something is REALLY important, like flight control software (or for instance the self-destruct device for a large commercial booster, which I once wrote some of the firmware for) then you can get pretty decent quality, but it is hugely expensive. That box had about 6k lines of code in it and the software cost was well into the millions...
Why would a Jenkins deployment be in the backlog? If you don't have a CI system, or can't put one together as part of your tooling, what makes you think you're qualified to be doing software development on anything but the smallest scale? Would you hire a plumber if he put a line item on his project estimate "buy tool box"???
The point stands, you don't do Agile by doing big-bang integration at the end. Clearly on a daily check-in basis you can have integration problems, just routine. You should always be no more than a day ahead of the last time you ran a full set of integration tests. If you're not doing that you're wasting time and money. The poster who talked about his problems with integrating at the end was thus AFAICT not doing Agile and thus his complaints about Agile are irrelevant. If he doesn't have a CI tool he's not even a professional at any level where talking about engineering process is meaningful.
Lets suppose you're a business and you want to build a manufacturing facility that will cost you say $500k. That's a pretty substantial investment. You're telling me you're just going to hand $500k to some GC and say "hey, build me an XYZ on this plot of land" and you expect to walk away and come back in 6 months and magically have something that exactly does what you want?
No, you're going to supervise, and inspect, and you're going to work with the GC and the architect, and the people installing the machinery, and the power company, and all those other people. You simply CANNOT expect a complex project to succeed without that level of constant interaction, cross checking, making sure that when the utility entrance can't be on the west side because the power company will only put the substation on the east side that things still work out. It just doesn't happen by magic.
If you think somehow that a software project isn't EVEN MORE this way than a conventional construction project then you're monumentally misinformed about how things work and frankly you should buy OTS software because anything beyond the most trivial projects WILL fail if you approach them this way. I've been doing this stuff for 30+ years, and I say this with the utmost certainty. In fact, since I have plenty of business from sensible customers, I wouldn't even do business with someone that demonstrated your attitude. You're not worth the trouble. You're a lawsuit or at least a broken project waiting to happen.
Ah, yes, well said.
Right out of my mouth. You're NOT DOING AGILE if you have to integrate components at the end.
Also, the idea is not "we can just recode everything at the end", the idea is "only code now what you need right now", so yes, you will refactor, but that refactoring is an ongoing part of the process that is informed by 2 things, continuous integration and user acceptance testing.
IMHO one of the MAIN reasons why people will fail with Agile is that they ignore the requirement to have the customer/stake-holders right there in the process. If you actually PAY ATTENTION to the things that Agile is telling you to do (personally I find XP type process to be the most effective) then you can make it work. Everyone needs to understand the value of the parts, and as any Agile expert will tell you ALL the pieces are important. It is not at all interesting news for someone to tell me that if you fuck up and ignore half the pieces of the process that the other half don't magically just work.
No one development methodology is a panacea of course, but this report seems to be meaningless criticism based on not actually understanding how and why to use Agile.
Mars seems to me to be indeed "a planet too far" at this point. Give us 50 or so years of operational experience on the Moon, then it will be a lot more sensible plan.
This is so way super optimistic pie-in-the-sky it is not even funny. There's 50 or 100 years worth of engineering work blocked out here and a couple $100 billion in R&D, and they have 10 years and $6 billion... I guess it just shows you can convince yourself of almost anything if you try hard enough...
Space grade solar arrays are actually more in the 40% efficiency range. Toss another 10 years worth of R&D on that, so I think your numbers are fairly pessimistic. Not that I'm convinced you can grow food on Mars. You probably can. The chances of getting it right the first time around seem rather low though. Only a small number of things have to go wrong for it to fail, and then you're toast. Any unknown contaminant, a vital nutrient that fails to be recycled quite efficiently enough, unknown effects of low gravity, radiation, god knows what. It is the unknown unknowns that will probably kill you on this one, and we don't even have a clue how big those are.
The whole plan is beyond high risk. It seems almost bound to fail simply on the basis of piling up bad probabilities. Growing food might not be the Achilles heel of the whole thing, but it sure does seem like one of the most likely medium term failure modes.
I think you're right. The real long-term problem though is just general viability. You only have to be a little bit wrong in how things work on Mars and your colony is dead. With no manufacturing capability, very limited resources, accidents, stuff wearing out and breaking, etc even if you have a pretty good idea about how to do all this stuff you're VERY likely to fail, and probably for some stupid reason that nobody even thought of. Any such 'glitch' is going to be quite hard to recover from too considering that you've got to ship equipment from Earth.
The thing is, people aren't really considering the duration of this thing. You're going to send healthy, and probably fairly young people to Mars. They aren't going to be there for a couple years, or a decade, they're going to have to survive for what, 40 years? At least? Sure, in theory you send more stuff, but honestly nobody has a blinking clue what it takes to live on Mars for 40 years.
Beyond that, why? What is the real LONG TERM basis for a colony? It is surely going to take decades, maybe centuries for such a colony to become self-sufficient. Surely reality TV is not going to cut it on mission year 97. There's "science" up to a certain point, and there's "adventure" up to a certain point, but crud, a colony that far distant from Earth, on an utterly hostile and largely barren world? Its not like there are valuable resources on Mars that would EVER be worth shipping back to Earth. There's only so much Mars science that is worth the cost, etc.
Humanity's record in terms of supporting distant non-commercially-viable colonies ON EARTH is pretty dismal. Its hard to believe that any colony such as this, if you even managed to survive at all to start with, seems quite dim.
lol, yeah, no. You're correct that KE = m/2 v^2, but the proper consideration is momentum. If what you're saying were true then an object falling towards the surface of the Earth under the influence of gravity would accelerate more slowly the faster it went, which is plainly contrary to actual observation. The "kicking off" argument used below doesn't work either because this applies both to the train and the passenger AND TO THE EARTH. The same is true of an object freefalling. Not only does the object fall to Earth, but the Earth free falls in the object's gravity as well. There's ALWAYS action/reaction.
lol, somehow I knew someone would come up with that ;)
Yeah, I was supposed to be "Giant Electronic Brain" but what can I say? lol.
Yeah, definitely. It is a tough problem. I guess all we can do is keep our fingers crossed and keep electing people that see the problem and will continue a policy of nuclear arms reduction. I pretty much assume they're never going away (unless we invent something even scarier) but if we got to a point where the great powers have a handful of bombs each we might work it out. All agree to put them on low low readiness and some day perhaps we'll learn to settle differences without making threats. Kinda optimistic perhaps, but so it goes.
I think anyone would do it when looked at from a purely selfish point of view. The problem is that nuclear weapons are a prisoner's dilemma. There's no payoff better than long-term mutual annihilation that doesn't involve everyone giving up the sure payoff in the short term.
The ULTIMATE and fundamental problem with Waltz's analysis is the end result IS annihilation. While we don't know the exact risk of nuclear war per unit time we can deduce from first principles and observation that it is non-zero. We can deduce further that it increases as the number of nuclear states increases. Thus given enough time it will happen, and given more proliferation it will surely happen more swiftly.
And lets not kid ourselves, there are very few SURVIVABLE nuclear war scenarios. Even modeling of limited exchanges by regional powers like India and Pakistan show incredible damage, probably enough to collapse all of modern technological civilization. The odds of any of the people in this forum surviving such an occurrence, of ANYONE YOU KNOW surviving it, are poor to say the least. Even very optimistically you're looking at a death toll of something like 1 billion people in the immediate aftermath. That dwarfs all the wars we can even imagine, let alone any that Waltz can optimistically assume have been prevented.
Waltz is just wrong. Very wrong. The scary part is his argument is one that is a very convenient justification for the short term selfish behavior of the people who could decide to end the madness.
That comes with age. There's also a certain level of need to just get stuff done. At a certain point USING knowledge becomes the overriding concern, and you have so many tools in your toolbox that one more becomes less and less useful. You also begin to find that there's very little that is really new under the Sun in most fields. As a software engineer I see fads in languages, dev tools, databases, etc, and hear all about how some new guy is sure that it is a whole new revolutionary better way to do stuff. Often some new tool IS useful, but it is also often something that existed 30 years ago that everyone has just sort of forgotten about and it got renamed/reinvented and we long ago learned what its limitations were and moved on to other things (probably when we were 24 or so...).
There's also a certain factor of luck in terms of poking around at stuff. Yeah, you did debug something in a snap, which is good, congrats. OTOH I might look over your shoulder tomorrow and spot something you missed too. I don't know the guys you work with, but they probably managed before. Maybe they're bumblers, and maybe they just missed something. Ironically the more secure you become in your knowledge the easier it can be to miss some small detail that you 'know'. Today I was totally thwarted by some stupid piece of bad design in python that caused a webapp I was deploying to balk at reading a file. My associate figured it out, somehow. Python's split() function is just stupidly designed. Being an old Perl guy from way back I assumed NOBODY could be that stupid, but yes they can! He doesn't know perl from beans and thus less knowledge = solution. Ironic, but it goes that way sometimes.
One thing is for sure. I learned back around 26 not to be cocky, lol. That's a danger to avoid. Maybe I'm hot shit, but I never ever speak ill of anyone or brag about anything nowadays. It works. Only the VERY best of the best get away with the cocky routine for long... ;) (not saying you're cocky, just remember not to get that way).