You've nailed it. Your statement though, is giving a positive take on their behavior. My experience has been more aligned with the uproar over the sunset of google+ - google simply does not honor its commitments. To them, change to support inexorable demand that progress be made, outweighs the cost of broken promises. The internet public may be ok with that, but businesses aren't. I've seen this happen with business services that they provide. This, IMHO, is why GCP will never be a serious contender for AWS or Azure. They simply can't be trusted.
Couldn't have said it better. Instruments fail all the time. Knowing how to navigate by first principles is needed if one is to survive. Besides which, situations are unpredictable. Your ship may sink, or your aircraft may crash in the middle of nowhere, and take your navigational automation with it.
This is only true for certain types of work. If there is a substantial stream of work that can be transferred offshore_in its entirety_ including the subject matter expertise, then all that work can be performed remotely. For anything else, a local presence is required. Either to accept the iterative knowledge transfer from the local SMEs, or so that the work can be performed locally under supervision. If this isn't done, then delays, misunderstanding, and other screwups will contribute to a greatly increased failure rate.
Sigh. I hear this argument often, but its not true. You don't need a separate person as an architect when your project is small. Do you need an architect for putting together the barn behind your house? No. But its not because an architect isn't needed. Rather its because, building the barn is such a small problem that the builder (programmer) can perform the trivial architecture piece all by themselves (in most cases, in their head, without needing to formally declare it on paper).
It takes a while before college graduates deal with the big problems. Until one understands that big problems come with challenges that require a different approach, its hard to understand why an architect is needed. To go back to the example of the parent post: the architect isn't specifying how exactly one needs to implement the code. It is a false argument to say that they are taking away anyone's flexibility in that area; this viewpoint makes it clear that the poster doesn't know what an architect does. To go back to the building analogy: suppose the customer comes to the builders and say that they want an office building. Who gets to make the decisions on what it should look like, how tall it should be, how many entrances and exits, where does the supporting infrastructure (pumps, networking and telephony equipment, etc) go? Its not the builder or the electrician, or the brick layer or what ever the trade is. They are not laying down the vision of what to build. The architect - whether it is civil engineering or software engineering - is describing what it is that you need to implement - not how. An architect is NOT a lead developer. If you have to blame someone for taking away your flexibility in programming style, blame the lead developer.
Its an age old question, who watches the watchers? You want to give the government more power to control its population but yet you fail to see how such things are how you give nefarious actors the power to take control of the government and thus the population.
I'm not failing to see any such thing. I know what the consequences are, and I still am making the choice to say "no" to anonymity. There are solutions other than anonymity that deal with the issues of government overreach. And they are all meat space solution. I'm perfectly fine with those being options. What are the options? Here I'll be a little flippant: https://en.wikipedia.org/wiki/Four_boxes_of_liberty , but that is the general direction in which I'm thinking.
Thank you. There is a lot of anger directed against the police in the US - much of it coming from their heavy handed tactics in law-enforcement. However, the key differentiator here is that their tactics aren't politically motivated. Comparing the police forces to that of more brutal regimes is not just a matter of degree (of oppression) - its also a bad comparison in terms of the rationale for the behavior.
Back on topic, I agree with the "accountability is the only thing" idea. Well....perhaps not the only thing, but in this case, its the thing thats needed to put out this fire before it consumes everything in its path. Anonymity is not a fundamental human right. It has value in certain contexts (like protecting dissent), but it also has downsides (as you can see in slashdot comments on this page itself - where there are many trolls as anonymous cowards who try to drag the rest of the posters down just because they can). Its a balance that someone has to strike, and in the absence of a specific law, one has to look at which causes the greater problem. In the short term, accountability will help a lot. It may even help with more problems than just lynchings - for example, what if the US military could now track down terrorists better because the messages they send are now traceable? In the long term, anonymity against law enforcement over the internet takes a big hit. I can live with that, because its something that was invented quite recently, and I'm not losing anything by it going away.
Another point to keep in mind is that privacy and some forms of anonymity already existed pre-internet, and they were carefully weighed and considered within the legal system. Reporters can keep their sources private. Doctors have doctor-patient confidentiality. Religious confidentiality is honored. But there are exceptions to all these, that the court system has deliberately breached with the public interest in mind. And the world hasn't ended.
This is being misunderstood, because the traditional purchasing model is not the way they government wants to purchase software any more - at least within the DOD. DISA - the IT arm of the Dept. of Defense, has bought into the cloud movement wholesale. One of the benefits that the cloud brings to them is that software - once sold as SaaS, becomes opex, instead of capex. This means that when they put out requirements for software, they will ask for the entire SaaS stack - down to the compute, storage, and networking, to be provided as part of the bid. The only caveat is that quite often, all of this has to run on DOD premises, or DOD accredited premises. Both Amazon, and IBM have the ability to run a private cloud on premise, and could respond to RFPs like this. Microsoft was missing out on multi-million dollar bids because they didn't have a private cloud offering till now.
Given that the DOD _wants_ a local hosted solution, there is nothing net new about the expense of it being hosted locally. With a cloud / SaaS model though, the DOD can now walk away from a vendor if they chose to, at will. So, the hosting cost will be baked into the price of the service, but the depreciation will be owned by the Cloud Provider. The DOD wins because it can be nimble ("oh - you want to add 5000 more users as users of service X? No problem, we just provision more users in the system. It will be ready in two days"), scaleable ("Oh there is a war breaking out? No problem, our cloud platform can scale up and meet the additional load"), and modern (because the software will have to be maintained _by the vendor_ in an evergreen state). And the SaaS / Cloud provider wins because they get $$$$ from the government.
1. Yes, no system is unbreakable. But the barrier of entry needs to be raised to rule out the halfway intelligent. 2. No question reform is needed, but as has been pointed out by many posters in this story, the police lacked the intent to do harm. Its just like a gun / weapon. The gun lacks intent / motive. The person wielding the weapon has the far bigger share of the blame. Taking away the weapon will just cause the person with intent to reach for a different weapon. 3. Threat of punishment may not deter all idiots. But (a) its a numbers game - it should deter enough that occurrences of these should reduce greatly. (b) actual punishment takes them out of the system where they could cause more incidents like this.
The problem with this is that the LED off state could tell the user that there is a blood sugar problem when there really isn't one. And for diabetics, fixing a problem which isn't there can result in a condition that is just as dangerous / life-threatening. So, this isn't fail-safe by any means.
I agree with you, that two states can't distinguish between three conditions. But until the device fixes that problem, the chosen approach is just as bad as the one the OP was advocating (and me too). In that case, why not choose the more user-friendly one?
It doesn't seem like the chosen approach can distinguish between the two either. I'm with the OP. If there is a reason why this approach was chosen, it would be good to know.
So there is probably a lot of truth in the reporting, but the shock value of the story comes from the numbers. 95% you say! Oh my! We cannot have any Indians write code! The details, in this case, matter a great deal, so lets take a look at some of the unanswered questions that may impact the accuracy of that number.
* What does "...not write code that compiles" mean? Were the people being tested provided an IDE? I'm an expert Java programmer, but if I were to open up a text file and type Java code, odds are pretty good that my code won't compile on the first try. That's what IDE's are there for - to fix the inane syntax issues. But lets say that the IDE's were provided. What sort of languages were used in the test? Were the test takers familiar in the language being used? Was the measurement really meaning that they ran out of time to make the program compile or that they were incapable of making it compile because they really weren't a programmer? I note that the "cannot even compile" statistic is 2/3 - not 95% according to TFA. Still bad, but details are needed to see what was being measured. * What does the sample mean? TFA says that the sample size was 36000, but how does this compare to the universe out there, and who made up the sample? Were these graduates in computer science or first year students or people already working in the field? What was the level of quality for these universities? Where did the 5% who did good come from, and did those 5% come from the really good schools? Was the sample size structured to represent the real world distribution of quality in educational institutions? * Bias: who is aspiring minds, and what is their motivation? Are they tied to a particular agenda? Is there a competing country that wants their programmers to be hired over Indian programmers pushing these stats? I will point out that there were numerous doctors pushing the agenda of the tobacco industry, and numerous scientists pushing the agenda of the oil industry (global warming). So, yes, the affiliations need to be clear.
I will also point out that in the silicon valley, Indian engineers are present in high numbers. And a lot of the clamor for getting Indians into the US comes from companies in that area. If 95% of them were useless, I can't help but think that there would be less demand.
How long is it going to be before someone customizes the design to weaponize it? It doesn't have to carry a gun / missile. The payload can be a biological weapon. Spores of anthrax, anyone? Something that sprays the agent over someones backyard? Maybe the backyard of your political enemies? Or maybe you have a rich uncle, who has you in his will, and you really really could use some money now?
To defend against infrastructure attacks, the government will put more drones in the sky for policing. And then we'll be off to the races. You will have hobbyists / malicious agenst trying to figure out how to make their drones stealthy. And then the government escalating on those. Counter-counter measures being developed. The whole thing will look like something that came out of a Spy vs Spy cartoon from Mad comics.
And lets not forget that the US is winning (or atleast NOT losing) wars right now because of its drone superiority. Wait till the taliban or ISIS get their hands on these designs.....
Exactly. I watched a documentary recently on the LHC, and one of the scenes showed a physicist explaining to a lay audience what the multi-billion dollar effort was all about. One of the questions from the audience (who self-identified as an economist) was what was the economic benefits from knowing about all those particles or discovering the Higgs boson.
The response from the scientist was - "nothing". There is no economic benefit from spending all that money and doing that research. On the other hand, when they were discovered, radio waves weren't called radio waves - they were just a new form of radiation.
The major issue being you'd have to be near a deployment center, I imagine the only Amazon deployment centers in Canada are in Toronto and Ottawa.
Initially that will be true. But its possible that as this develops, the drones could take off and deliver from the shipping container that is travelling down the highway. IOW, you would be having a mobile (mini) warehouse that gets close enough to whereever you are to have the drones complete the delivery over the last few miles. After delivery, the drones would return back to the new location of the truck, which has continued down the highway....
Its generally the complexity of the requirements that makes something big or small. You're right - cost may not mean "big". For example, specialist skills like SAP or the latest buzzword technology can drive up the cost because its costs more to staff those developers. In general though, the more complex the requirements, the more it costs to develop the application.
Building an application server requires a different skillset and mindset than building an application does. Being a specialist in a product / technology is a wonderful achievement, and will make you very good at implementing designs. However, putting together the design and looking at the bigger pictures and making sure that the system works well together, and addresses maintainability, scalability, performance constraints, and reliability concerns requires the mindset and skill of an architect. Most small projects don't require an architect. When you get work at an enterprise level - when building an application costs (development costs only - not deployment, hosting, or operational costs) million+ dollars, you need an architect, and thats where an exclusively specialist team often doesn't deliver what the customer needs.
To draw an analogy, one can have a jam session with a handful of musicians, without requiring a conductor. But if you have hundreds of musicians (like an orchestra does), a conductor is required to deliver a quality performance.
Why is this relevant to your post? Simply put, it is easy to work without EJB's or other aspects of JEE and implement everything a servlet container. But when it gets to big applications, and you are architecting an application, JEE makes it so much easier to deliver quality.
There was a great episode of Bullshit which focussed on the organic food vs non-organic food topic. It turns out that most of the (superior) taste difference that people claim for organic food is psychological. For a single banana cut into half, if one piece is labelled "organic" and the other is not, people would report a better taste for the "organic" half. Now granted that Penn & Teller weren't producing a scientifically peer reviewed experiment, it still is an interesting data point. For my part, I don't see any difference whatsoever between organic and non-organic, other than that the organic stuff seems to spoil faster.
Yes, the view looks great through those rose-tinted glasses. I did all those unsafe things you mentioned, but there is a big difference between doing all those things and what the Chinese are proposing. The only one who took the risk was me. If I screwed up, only I suffered. The consequences of failure in this grand scheme being concocted are not limited to China alone, and if we all take the risk, then we should all have a say in this endeavor, and we should all benefit from it.
This is somewhat like the BP oil spill. The spill may have occurred outside of US territorial waters, but it sure as hell impacted the US. And the US will certainly want a say in what oil companies do when drilling offshore, because of the fiasco we witnessed.
Yes, Airbnb is a service that doesn't provide any value (why do they exist, again?), but thats not the problem here. Even if they did provide verification of the renter, it would still be stupid to rent out ones apartment exposing private and personal information to some stranger. In this case, the landlord realized that her identity was at risk because the place had been comprehensively trashed. A smarter thief would have simply noted down all the personal data would letting the landlord suspect anything. And because the identity theft using this data could happen many months later, it would be difficult to pin this down to a specific renter.
There is no escaping the fact that landlords like this need a reality check. Maybe the world is filled with people who do and want to do the right thing, but why would you take a risk like this assuming that no bad apples would come in contact with you?
She didn't _prove_ him wrong. You can walk across a busy highway, and by some miracle escape being hit by a vehicle. That doesn't prove that everyone who told you that you are doing something stupid was wrong.
Maybe this is your experience, having come from working on applications that serve mom and pop shops, but don't assume that your experience is the same as everyone else's. Mine is the opposite of yours. Most applications are engineered for maintainability and very often, when compromises are made in shipping things out the door, it is often the function points that are left on the floor, rather than shipping function points backed by unmaintainable code.
The only exceptions to this that I have seen have been in shops which are so small that the development team lacks an architect who can enforce this discipline, and you have a team consisting of prima donnas. I'm not saying that small teams can't deliver good code. Just that most of the screwups that I've seen come from small teams operating without any discipline (and they typically lack the discipline because they think they are small enough to operate in that mode).
You are mostly correct, though you didn't mention the key word: control system. The patent that the Wright Brothers file was not for the shape of the plane, or the engine they used, but for the control systems that let them control the pitch, yaw, and roll of the aircraft. Indeed, controlling the aircraft in stable flight by defining parameters like pitch, yaw, and roll was a key insight of theirs. All their competitors weren't able to achieve stable flight because they were still guessing their way around how to keep their aircraft up and steady, and didn't really have a solution that let them control the aircraft.
Slashdot Mirror
You've nailed it. Your statement though, is giving a positive take on their behavior. My experience has been more aligned with the uproar over the sunset of google+ - google simply does not honor its commitments. To them, change to support inexorable demand that progress be made, outweighs the cost of broken promises. The internet public may be ok with that, but businesses aren't. I've seen this happen with business services that they provide. This, IMHO, is why GCP will never be a serious contender for AWS or Azure. They simply can't be trusted.
Couldn't have said it better. Instruments fail all the time. Knowing how to navigate by first principles is needed if one is to survive. Besides which, situations are unpredictable. Your ship may sink, or your aircraft may crash in the middle of nowhere, and take your navigational automation with it.
This is only true for certain types of work. If there is a substantial stream of work that can be transferred offshore_in its entirety_ including the subject matter expertise, then all that work can be performed remotely. For anything else, a local presence is required. Either to accept the iterative knowledge transfer from the local SMEs, or so that the work can be performed locally under supervision. If this isn't done, then delays, misunderstanding, and other screwups will contribute to a greatly increased failure rate.
Car company 1: Chooses pedestrian safety over passenger
Car company 2: Chooses passenger safety over pedestrian.
Ad for car company 2: In the event of an accident, we value your safety and that of your family / children over other people outside the car.
I'd be shocked if _any_ parent bought a car from company 1.
Sigh. I hear this argument often, but its not true. You don't need a separate person as an architect when your project is small. Do you need an architect for putting together the barn behind your house? No. But its not because an architect isn't needed. Rather its because, building the barn is such a small problem that the builder (programmer) can perform the trivial architecture piece all by themselves (in most cases, in their head, without needing to formally declare it on paper).
It takes a while before college graduates deal with the big problems. Until one understands that big problems come with challenges that require a different approach, its hard to understand why an architect is needed. To go back to the example of the parent post: the architect isn't specifying how exactly one needs to implement the code. It is a false argument to say that they are taking away anyone's flexibility in that area; this viewpoint makes it clear that the poster doesn't know what an architect does. To go back to the building analogy: suppose the customer comes to the builders and say that they want an office building. Who gets to make the decisions on what it should look like, how tall it should be, how many entrances and exits, where does the supporting infrastructure (pumps, networking and telephony equipment, etc) go? Its not the builder or the electrician, or the brick layer or what ever the trade is. They are not laying down the vision of what to build. The architect - whether it is civil engineering or software engineering - is describing what it is that you need to implement - not how. An architect is NOT a lead developer. If you have to blame someone for taking away your flexibility in programming style, blame the lead developer.
Its an age old question, who watches the watchers? You want to give the government more power to control its population but yet you fail to see how such things are how you give nefarious actors the power to take control of the government and thus the population.
I'm not failing to see any such thing. I know what the consequences are, and I still am making the choice to say "no" to anonymity. There are solutions other than anonymity that deal with the issues of government overreach. And they are all meat space solution. I'm perfectly fine with those being options. What are the options? Here I'll be a little flippant: https://en.wikipedia.org/wiki/Four_boxes_of_liberty , but that is the general direction in which I'm thinking.
Thank you. There is a lot of anger directed against the police in the US - much of it coming from their heavy handed tactics in law-enforcement. However, the key differentiator here is that their tactics aren't politically motivated. Comparing the police forces to that of more brutal regimes is not just a matter of degree (of oppression) - its also a bad comparison in terms of the rationale for the behavior.
Back on topic, I agree with the "accountability is the only thing" idea. Well....perhaps not the only thing, but in this case, its the thing thats needed to put out this fire before it consumes everything in its path. Anonymity is not a fundamental human right. It has value in certain contexts (like protecting dissent), but it also has downsides (as you can see in slashdot comments on this page itself - where there are many trolls as anonymous cowards who try to drag the rest of the posters down just because they can). Its a balance that someone has to strike, and in the absence of a specific law, one has to look at which causes the greater problem. In the short term, accountability will help a lot. It may even help with more problems than just lynchings - for example, what if the US military could now track down terrorists better because the messages they send are now traceable? In the long term, anonymity against law enforcement over the internet takes a big hit. I can live with that, because its something that was invented quite recently, and I'm not losing anything by it going away.
Another point to keep in mind is that privacy and some forms of anonymity already existed pre-internet, and they were carefully weighed and considered within the legal system. Reporters can keep their sources private. Doctors have doctor-patient confidentiality. Religious confidentiality is honored. But there are exceptions to all these, that the court system has deliberately breached with the public interest in mind. And the world hasn't ended.
This is being misunderstood, because the traditional purchasing model is not the way they government wants to purchase software any more - at least within the DOD. DISA - the IT arm of the Dept. of Defense, has bought into the cloud movement wholesale. One of the benefits that the cloud brings to them is that software - once sold as SaaS, becomes opex, instead of capex. This means that when they put out requirements for software, they will ask for the entire SaaS stack - down to the compute, storage, and networking, to be provided as part of the bid. The only caveat is that quite often, all of this has to run on DOD premises, or DOD accredited premises. Both Amazon, and IBM have the ability to run a private cloud on premise, and could respond to RFPs like this. Microsoft was missing out on multi-million dollar bids because they didn't have a private cloud offering till now.
Given that the DOD _wants_ a local hosted solution, there is nothing net new about the expense of it being hosted locally. With a cloud / SaaS model though, the DOD can now walk away from a vendor if they chose to, at will. So, the hosting cost will be baked into the price of the service, but the depreciation will be owned by the Cloud Provider. The DOD wins because it can be nimble ("oh - you want to add 5000 more users as users of service X? No problem, we just provision more users in the system. It will be ready in two days"), scaleable ("Oh there is a war breaking out? No problem, our cloud platform can scale up and meet the additional load"), and modern (because the software will have to be maintained _by the vendor_ in an evergreen state). And the SaaS / Cloud provider wins because they get $$$$ from the government.
1. Yes, no system is unbreakable. But the barrier of entry needs to be raised to rule out the halfway intelligent.
2. No question reform is needed, but as has been pointed out by many posters in this story, the police lacked the intent to do harm. Its just like a gun / weapon. The gun lacks intent / motive. The person wielding the weapon has the far bigger share of the blame. Taking away the weapon will just cause the person with intent to reach for a different weapon.
3. Threat of punishment may not deter all idiots. But (a) its a numbers game - it should deter enough that occurrences of these should reduce greatly. (b) actual punishment takes them out of the system where they could cause more incidents like this.
The problem with this is that the LED off state could tell the user that there is a blood sugar problem when there really isn't one. And for diabetics, fixing a problem which isn't there can result in a condition that is just as dangerous / life-threatening. So, this isn't fail-safe by any means.
I agree with you, that two states can't distinguish between three conditions. But until the device fixes that problem, the chosen approach is just as bad as the one the OP was advocating (and me too). In that case, why not choose the more user-friendly one?
It doesn't seem like the chosen approach can distinguish between the two either. I'm with the OP. If there is a reason why this approach was chosen, it would be good to know.
So there is probably a lot of truth in the reporting, but the shock value of the story comes from the numbers. 95% you say! Oh my! We cannot have any Indians write code! The details, in this case, matter a great deal, so lets take a look at some of the unanswered questions that may impact the accuracy of that number.
* What does "...not write code that compiles" mean? Were the people being tested provided an IDE? I'm an expert Java programmer, but if I were to open up a text file and type Java code, odds are pretty good that my code won't compile on the first try. That's what IDE's are there for - to fix the inane syntax issues. But lets say that the IDE's were provided. What sort of languages were used in the test? Were the test takers familiar in the language being used? Was the measurement really meaning that they ran out of time to make the program compile or that they were incapable of making it compile because they really weren't a programmer? I note that the "cannot even compile" statistic is 2/3 - not 95% according to TFA. Still bad, but details are needed to see what was being measured.
* What does the sample mean? TFA says that the sample size was 36000, but how does this compare to the universe out there, and who made up the sample? Were these graduates in computer science or first year students or people already working in the field? What was the level of quality for these universities? Where did the 5% who did good come from, and did those 5% come from the really good schools? Was the sample size structured to represent the real world distribution of quality in educational institutions?
* Bias: who is aspiring minds, and what is their motivation? Are they tied to a particular agenda? Is there a competing country that wants their programmers to be hired over Indian programmers pushing these stats? I will point out that there were numerous doctors pushing the agenda of the tobacco industry, and numerous scientists pushing the agenda of the oil industry (global warming). So, yes, the affiliations need to be clear.
I will also point out that in the silicon valley, Indian engineers are present in high numbers. And a lot of the clamor for getting Indians into the US comes from companies in that area. If 95% of them were useless, I can't help but think that there would be less demand.
Come on, moderators - this is funny. mod it up please
How long is it going to be before someone customizes the design to weaponize it? It doesn't have to carry a gun / missile. The payload can be a biological weapon. Spores of anthrax, anyone? Something that sprays the agent over someones backyard? Maybe the backyard of your political enemies? Or maybe you have a rich uncle, who has you in his will, and you really really could use some money now?
To defend against infrastructure attacks, the government will put more drones in the sky for policing. And then we'll be off to the races. You will have hobbyists / malicious agenst trying to figure out how to make their drones stealthy. And then the government escalating on those. Counter-counter measures being developed. The whole thing will look like something that came out of a Spy vs Spy cartoon from Mad comics.
And lets not forget that the US is winning (or atleast NOT losing) wars right now because of its drone superiority. Wait till the taliban or ISIS get their hands on these designs.....
Exactly. I watched a documentary recently on the LHC, and one of the scenes showed a physicist explaining to a lay audience what the multi-billion dollar effort was all about. One of the questions from the audience (who self-identified as an economist) was what was the economic benefits from knowing about all those particles or discovering the Higgs boson.
The response from the scientist was - "nothing". There is no economic benefit from spending all that money and doing that research. On the other hand, when they were discovered, radio waves weren't called radio waves - they were just a new form of radiation.
The major issue being you'd have to be near a deployment center, I imagine the only Amazon deployment centers in Canada are in Toronto and Ottawa.
Initially that will be true. But its possible that as this develops, the drones could take off and deliver from the shipping container that is travelling down the highway. IOW, you would be having a mobile (mini) warehouse that gets close enough to whereever you are to have the drones complete the delivery over the last few miles. After delivery, the drones would return back to the new location of the truck, which has continued down the highway....
Its generally the complexity of the requirements that makes something big or small. You're right - cost may not mean "big". For example, specialist skills like SAP or the latest buzzword technology can drive up the cost because its costs more to staff those developers. In general though, the more complex the requirements, the more it costs to develop the application.
Building an application server requires a different skillset and mindset than building an application does. Being a specialist in a product / technology is a wonderful achievement, and will make you very good at implementing designs. However, putting together the design and looking at the bigger pictures and making sure that the system works well together, and addresses maintainability, scalability, performance constraints, and reliability concerns requires the mindset and skill of an architect. Most small projects don't require an architect. When you get work at an enterprise level - when building an application costs (development costs only - not deployment, hosting, or operational costs) million+ dollars, you need an architect, and thats where an exclusively specialist team often doesn't deliver what the customer needs.
To draw an analogy, one can have a jam session with a handful of musicians, without requiring a conductor. But if you have hundreds of musicians (like an orchestra does), a conductor is required to deliver a quality performance.
Why is this relevant to your post? Simply put, it is easy to work without EJB's or other aspects of JEE and implement everything a servlet container. But when it gets to big applications, and you are architecting an application, JEE makes it so much easier to deliver quality.
There was a great episode of Bullshit which focussed on the organic food vs non-organic food topic. It turns out that most of the (superior) taste difference that people claim for organic food is psychological. For a single banana cut into half, if one piece is labelled "organic" and the other is not, people would report a better taste for the "organic" half. Now granted that Penn & Teller weren't producing a scientifically peer reviewed experiment, it still is an interesting data point. For my part, I don't see any difference whatsoever between organic and non-organic, other than that the organic stuff seems to spoil faster.
Yes, the view looks great through those rose-tinted glasses. I did all those unsafe things you mentioned, but there is a big difference between doing all those things and what the Chinese are proposing. The only one who took the risk was me. If I screwed up, only I suffered. The consequences of failure in this grand scheme being concocted are not limited to China alone, and if we all take the risk, then we should all have a say in this endeavor, and we should all benefit from it.
This is somewhat like the BP oil spill. The spill may have occurred outside of US territorial waters, but it sure as hell impacted the US. And the US will certainly want a say in what oil companies do when drilling offshore, because of the fiasco we witnessed.
I get the humour, but the tower of Babel was supposed to have been located in Mesopotamia - i.e modern Iraq
Yes, Airbnb is a service that doesn't provide any value (why do they exist, again?), but thats not the problem here. Even if they did provide verification of the renter, it would still be stupid to rent out ones apartment exposing private and personal information to some stranger. In this case, the landlord realized that her identity was at risk because the place had been comprehensively trashed. A smarter thief would have simply noted down all the personal data would letting the landlord suspect anything. And because the identity theft using this data could happen many months later, it would be difficult to pin this down to a specific renter.
There is no escaping the fact that landlords like this need a reality check. Maybe the world is filled with people who do and want to do the right thing, but why would you take a risk like this assuming that no bad apples would come in contact with you?
She didn't _prove_ him wrong. You can walk across a busy highway, and by some miracle escape being hit by a vehicle. That doesn't prove that everyone who told you that you are doing something stupid was wrong.
Maybe this is your experience, having come from working on applications that serve mom and pop shops, but don't assume that your experience is the same as everyone else's. Mine is the opposite of yours. Most applications are engineered for maintainability and very often, when compromises are made in shipping things out the door, it is often the function points that are left on the floor, rather than shipping function points backed by unmaintainable code.
The only exceptions to this that I have seen have been in shops which are so small that the development team lacks an architect who can enforce this discipline, and you have a team consisting of prima donnas. I'm not saying that small teams can't deliver good code. Just that most of the screwups that I've seen come from small teams operating without any discipline (and they typically lack the discipline because they think they are small enough to operate in that mode).
You are mostly correct, though you didn't mention the key word: control system. The patent that the Wright Brothers file was not for the shape of the plane, or the engine they used, but for the control systems that let them control the pitch, yaw, and roll of the aircraft. Indeed, controlling the aircraft in stable flight by defining parameters like pitch, yaw, and roll was a key insight of theirs. All their competitors weren't able to achieve stable flight because they were still guessing their way around how to keep their aircraft up and steady, and didn't really have a solution that let them control the aircraft.