Where do you think Shell comes from ? Major stockholder: the Dutch government.
Our government basically has a lot invested in doing nothing, so this was a good decision. The liberal conservatives immediately shrugged and said they wouldn't change a thing, but a precedent has been set. Maybe some good will come from this after all.

I agree that understanding computers is important, but there is much more to the "computing landscape" that programming. Remember that to a hammer (i.e., programmer), everything looks like a nail (i.e., a program). Machine learning is the new paradigm, and there is no programming. IBM's "True North" chip is a neural network chip - not a programmable CPU. In 20 years (maybe sooner) no human will be programming. So we should not be telling kids that being a programmer is a "career".

Well, it is up to them to agree. It is indeed your job to propose ideas, but users get to decide if your idea is the right one. In Agile that role is called the Product Owner (PO). The Product Owner owns the project. The dev team interprets the PO's requests, and writes those down as "stories". The PO must agree that the story is what he/she actually wants before the team works on a story. When the story has been implemented, the PO decides if is REALLY what he/she wants. If it is not, then the team still gets credit for completing the story, but the PO has the right to write a new story that changes things. The PO is paying for the project, so they can do that as long as they want. However, the team is supposed to help the PO to track progress toward the overall goal.

There are certainly Agile teams that work that way, but that is not how well run teams operate. Agile has a reputation for not planning, but the opposite is true - there is a-lot of planning in Agile. Well run teams also design. The difference is that Agile teams _allow_ requirements to change as a result of customer feedback, instead of trying to stick to a set of "agreed upfront requirements". Agile teams work at a steady pace, producing working software at regular intervals, instead of waiting for a huge release six months down the road - when it is often discovered that the design is unworkable. Agile projects can go off the rails just like any project, but in an Agile project, you find out very soon, instead of toward the end. There is no magic bullet for this stuff. The intent of Agile is to divide the work up into small items that are deliverable incrementally. It is not rocket science. You still have to do that dividing intelligently, and you still have to practice software design. Some in the Agile community disparage design somewhat, advocating test-driven development, but that point of view has been largely discredited. See http://martinfowler.com/articl...

Many organizations implement "Agile" without understanding it. Agile is not a methodology. It is a philosophy, expressed by http://agilemanifesto.org/ . The intent of Agile is to rewind back to what worked during the 70s and 80s. The authors of the Agile Manifesto are all people who were around then. It is well documented that large software projects with detailed up front requirements have a very high probability of failure. Agile merely advocates a return to common sense, including:

1. 1. Dividing the work up into smaller loosely coupled projects, and small features that can be implemented individually.
2. 2. Allowing requirements to change, in recognition of the fact that users often don't know what they need until they see something working.
3. 3. Testing as you go, instead of all at the end, based on acceptance criteria.

In the case that you describe, it sounds like acceptance criteria were not defined well.

Well run Agile projects do not abandon quality or non-functional requirements, detailed requirements, or design. What is different is that these things are allowed to evolve over time, through a process of refinement; but if no one is orchestrating that process, then indeed junk will be produced.

Many organizations are confused about how QA relates to Agile. Agile does not dispense with QA. If you search online, you will find a-lot of discussion of that. It is true that some in the Agile community do not understand the need for QA, but the more experienced and rational ones do. I can offer the following four-part article on Agile testing the way that it is done in many real organizations that do it right: http://www.transition2agile.co...

In many cases yes, but in many cases no. People who live in rural areas have things like this that are accessible. In Alaska, for example, it is not unusual for people to own sea planes and be bush pilots. Small planes are not unaffordable to a successful doctor or rancher. E.g., the Icon A5 is coming out soon and it lists for $140K. That is not cheap but it is affordable to most professionals.

The problem is, airplanes fly everywhere. Sport aviation pilots often fly at low altitude, and not necessarily with a fight plan. E.g., one might fly an amphibian plane from one's ranch to a lake a few hundred miles away and land in the lake. Many people also fly for recreation, doing loops and just enjoying the experience of flying. This is a longstanding activity, since the birth of aviation. This is especially true in rural areas. The problem with drones is that you can't see them - they are too small. It would be like having tiny drones on highways going in all directions - with the risk that you are driving along and one smacks into your windshield, except that a real drone is large enough that it would smash your plane's windscreen and kill you. Those using drones are basically saying, No more sport aviation for anyone: something people have done for 100 years is now off limits.

Will private pilots have to worry about hitting these drones? Many sport aviation pilots fly under 10,000 feet. With that airspace now be infested with drones that can impact and kill a pilot flying along at 150mph?

... on ars technica: http://arstechnica.com/security/2015/05/01/googles-new-version-of-password-alert-blocking-bypass-is-bypassed/. This one also has the original author of the exploit commenting on his findings.

Firethorn, I think that you might be reading it in "black and white". Reality is shades of gray. It might be that, statistically, more women are attracted to socially meaningful work. That does not mean that "[all] men aren't". The propositions of the article might be true - do you have evidence to the contrary? (I am not saying it is or is not - I don't know; but the article rings true to me.)

or it gets slower and slower as time goes on, as my iPhone seems to do. Or unless someone hacks into it and inserts malware that slows it down.

I am not a fan of the Mac, even though I am on my third one. But it is a far cry better than a Windows machine. And for programming it is excellent, because it is Unix. I use my Mac for all of my "devops" programming. And if she needs to do some heavy duty computation, she will want to run that in AWS or somewhere anyway. The problem with Linux as a general purpose laptop is that you are limited in all of the mainstream things. I assume that she does not do physics all day and all night: so if she wants to, say, watch Netflix, she will have a much easier time with a Mac. Most things can be done with Linux, but it requires research and effort. If she were studying computer science I would say she should go with Linux, but she is studying physics, so she will not want to waste her time on getting Linux to serve up a movie or exasperating over the fact that her Open Office document looks different when someone loads it on a PC, since the Mac supports MS Office. Her time is better spent thinking about gravitational waves. Get her a Mac, and she can do anything she needs to do with minimum hassle. Problem solved. Also, Macs are pretty durable due to the metal case.

Isn't it ironic that a great percentage of the programming that occurs today is for using the Internet to enable online commerce, collaboration, and business? And yet the Agile community (of which I am a member, and believe in Agile - although not ever single idea or practice) shuns distributed teams - the very technology that we build.

http://valuedrivenit.blogspot.com/2013/11/are-agilists-turning-their-backs-on.html

Well said. I actually agree with all of this. When I use the term "design pattern", I am speaking generally - not in terms of the "design pattern" movement. I simply mean defining the design in some way - not just rushing to the keyboard and coding. As you put it, you need all three: good architecture, good design, and good implementation. Many programmers today skip the first two.

Yes, I agree with what you say. You misunderstood the intent of what I said. I was not arguing for formal proofs. By "assurance argument" I merely meant that the programmer uses some explicit design patterns, that can be analyzed: the "assurance argument" is merely the logical analysis that convinces the programmer that the pattern is a secure pattern. Thus, I claim that secure code does not start as code, but starts as diagrams (design patterns) and algorithms that are then turned into code. The assurance argument is merely the thought process of verifying those patterns and algorithms on paper before writing the code. And this can be done in an "agile" way by progressively refining and adding to the design: the focus is on the design, however - not the code.