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.
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.
Comments
I rarely hear coders referring to themselves as artists; I've heard the "art and science of programming" now and then, but never it as a purely artistic field. However, ask mathematicians, chess players, and other highly analytical specialists, and they'll speak to the "art" side to their field. The world of mathematical proofs often requires the stroke of brilliance to put concepts together in ways no one else has, and that's essentially the basis for art.
I am not dismissing the creative side of science, either. I am stressing the repeatability aspect. I recognize repeatability is necessary but not sufficient for scientific endeavors.
I do not consider math to be science.
Math is the part of science you'd have left if you woke up in the morning and the universe was gone.