Insights from Dr. Dobbs

I've been flying a fair amount recently, so that means I've been reading various articles and the like. I want to make note of those I found interesting.

The March 2006 issue of Dr, Dobb's Journal featured a cool article on Performance Analysis and Multicore Processors. I found the first section the most helpful, since it differentiates between multithreading and hyperthreading. I remember when the FreeBSD development team was criticized for devoting so many resources to SMP. Now it seems SMP will be everywhere.

In the same issue Ed Nisley writes about Crash Handling. I call out this article for this quote:

Mechanical and civil engineers must consider how their projects can fail, right at the start of the design process, by calculating the stress applied to each component and the strength required to withstand it. Electrical engineers apply similar calculations to their circuits by considering voltage, current, and thermal ratings. In each case, engineers determine the project's expected behavior based on well-known properties of the bulk material and the finished components.

Software design isn't engineering simply because it does not deal with physical materials that have known properties. Software components don't exhibit a graded response to increasing stress: A single, trivial, data-dependent error can cause complete, instantaneous failure with no prior warning. Programs simply don't have a well-defined safe operating area.

If that's true, we're finished. I'm afraid it may be, but also in the same DDJ issue we read these comments on Project Management by Gregory V. Wilson:

[W]hile Stepanek [Bejtlich: author of a book reviewed by Wilson] refers to many of the classic works in software engineering, he seems to have missed most of what's appeared in the primary literature in the last 10 years. New journals such as Empirical Software Engineering have both reflected, and encouraged, new studies of what actually works and doesn't—studies that are methodologically sounder than many of their predecessors—and I think they ought to be required reading for anyone writing about software engineering today. I share Stepanek's sense of frustration, but think that software engineering isn't as special as it is often convenient for software engineers to believe.

I agree with that statement. I find too many people use the term "art" to make themselves feel special. If they took the time to document their approaches (analysis, administration, coding, pen testing, reverse engineering, etc.) they would find their processes repeatable and far less "special." Science is boring; art is cool. Science can also be automated, which could mean replacing humans. While I always believe humans are the best operators, hiding behind "art" is cowardly.