I have a couple problems with the implication that "short time to find/fix" is so acceptable.

1. Some amount of damage was done (and no one really knows for sure) through this bug. A fix was identified rapidly after the bug was -discovered-, but that's a long time after the bug was -introduced-.

2. For some systems, particularly those like SCADA systems where we really have deep information assurance concerns, patching software is not easy! Not everything can use "grab the patched source, rebuild and reinstall" or even "download the patch and install" repairs.

Thus the emphasis Has To Be on preventing these kinds of problems, then defending against them. Fixing them after the system is deployed is by far the weakest strategy. (Thus I salute with a full hand the initiative announced today, and discussed on a related SlashDot thread: http://news.slashdot.org/story... )

"We will hear and they will be punished!!!"

http://www.crosstalkonline.org...

And here's my $.02: C syntax has been actively harmful in this regard. It's too easy to make a typo that compiles, or to introduce a statement/expression that has a different result than you expect (e.g. the Apple "extra break statement" bug.)

Fair enough, and that begs the question whether the passengers on the ship could ever tell the difference...

The new captain has set a new course, one that veers away from the rocks. But this ship will take a long time and a lot of leeway to make that turn.

(Of course, I thought the old captain should have been 'relieved for cause' years ago, but since personally I'm neither a customer/user nor a direct shareholder in MSFT, it really wasn't my business :-)

My school had a one afternoon per week gifted students program. Among other things we did programmed/self paced instruction and classroom work on boolean algebra and basic number theory. This was in the late 1960s in a middle class school district in suburban Pittsburgh (Avonworth.)

The other thing worth noting is how most mathematicians make their breakthrough discoveries before age 30. (Sorry don't have the reference for this, but I've seen it widely discussed.) So that means the earlier we expose kids "with the math gene" to more complex topics, the greater the possibility that stuff will 'stick'.

From http://appleinsider.com/articl...
"The most glaring inconsistency is a disconnect between Gartner's 70.4 million iPad sales and Apple's self-reported 74 million unit sales for 2013. From the first quarter — Apple's second fiscal quarter — to the fourth, the company reported iPad sales of 19.5 million, 14.6 million, 14.1 million and 26 million, respectively. The total: 74.2 million iPads sold during 2013. "

Note these numbers are reported by Apple on SEC filings, not on press releases.

If I'm configuring a laptop that I'll use for both work and vacation:

Default Folder (an add-on/replacement for the Open File dialog)
Graphic Converter (photo manipulation application)
Aquamacs (very well done MacOS version of EMACS)
HDRtist Pro (HDR processing application)
OmniGraffle (Mac equivalent to Visio, drawing package)
Aperture (Photo organizing)
1Password (Password safe)
DiskWarrior (File system maintenance)
Syncovery (front end to rsync)

This doesn't include the stuff I find essential that's built into Mac OS X (and its Unix foundations, such as ssh and bash.)

And for what it's worth, I've been using Graphic Converter and Default Folder for at least 20 years, back to Mac OS 7 days. It says something about the quality/utility of these two applications that they've "stood the test of time."

One of the best novels about a realistic and mostly dysfunctional future set in 2010. http://en.wikipedia.org/wiki/S...

and say anyone that doesn't understand EBNF probably doesn't need to be granted SuperUser privilege. If there are specific actions that should be permitted for trusted but unsophisticated users, set up scripts to do only those actions.

And I'll demonstrate my age by saying that Unix derivatives, including Linux, BSD, etc, etc, -have a long way to go- to match VMS for a truly useful/administrator-friendly privilege model.

True, but if your company's product is, for example, software - and that software company is being run by someone with a legal, financial, hardware, operations, or non-software engineering background, the problem is much more difficult. And that's what I'm seeing. First the engineers need to be able to think in terms of business objectives (one of the best courses I ever had was a grad course in "engineering economics"). But second, the management community (starting with the business schools) need to figure out how to train CxOs that actually -understand the business they're in-.

For the last 30+ years, I've been in the large scale systems business. Most, but not all of that has been on projects for the US DoD. I've been appalled by the number of senior executives, military/government, large industry, small industry, who fundamentally don't understand software-intensive systems. As my earlier post said, their software experience is encapsulated in some small-scale programming task, rather than in large scale software engineering. On the one hand, they expect software to perform miracles because "it's software, you can change it," while on the other hand they refuse to invest in software. For the former, the best quote is from a former co-worker, "The software engineer is the system engineer of last resort."

I'm reminded of a system I once reviewed where they had a 'software problem'. But it turned out they had a -networking problem-. They were trying to move large volumes of images over a 10BaseT ethernet connection, and wondered why they weren't getting system throughput. Their ethernet was usually well over 50% loaded and couldn't handle the data. But they expected the software to 'fix' this.

I've had the good fortune to work for several good managers, either as direct supervisors or as senior managers, up to the Corporate VP level. That includes people in small companies, in Fortune 500 companies, and even active duty Army officers.

What I've observed is that the top levels of management DO NOT want to listen to what the good engineering managers try to tell them, about topics like staff training and retention, schedules or resources (e.g. hardware/capital expenditures.) Instead, the CxO level people promote those who tell them what they want to hear. It's not universal, but many of the good managers I've had are products of deliberate leadership/management training, rather than being promoted from 'nerd' to 'boss' and left to figure it out on their own. Part of that training is how to talk to the CxO level and how to make arguments in terms of corporate business case, objectives, etc.

The only good news is that at least in this millennium, the number of top managers/CxOs who actually know something about software, has increased. They're still a minority, but you may well find a VP who understands that software isn't "that crappy stuff that always makes our systems late, so we'll 'fix' it by throwing more cheap bodies at it." (I got really tired of the engineering VPs whose experience was in hardware, and whose ideas of software systems engineering was framed by "that FORTRAN course I took in college...")

One interesting model that was popular in the early '90s may deserve another look. Some research labs* split managerial duties, separating technical leadership from administration. Where some organizations got into trouble with that model was not treating both classes of managers as equals. The technical leaders too often got marginalized, because the administrators were the ones that talked about the kinds of stuff CEO/CFO wanted to discuss. It takes a tremendous investment at the CxO level to institute a program that recognizes and grows technical leadership as distinct from, frankly, beancounting.

* It runs in my mind that DEC's Western Research Labs was one of the organizations that implemented this approach successfully.

and was recovering from all the partying and travel back to the Moon.

(Seriously, great news!)

and smiling... http://en.wikipedia.org/wiki/J...

Does this count as a Heisenfix?