March 2, 2015 at 10:03 PM by Dr. Drang
I got some interesting responses to my post last week about ethics and licensing, more on licensing than ethics. I thought it worth a quick followup post.
First, I was a little surprised at the responses I didn’t get. Given the popularity of dumbass libertarian politics on the internet, I was expecting more comments like
“@drdrang: ⛄️ Engineering ethics
Licensing like doctors/lawyers leads only to insular anticompetitive rules/laws
— Dog Shit Frosting (@DogShitFrosting) Feb 28 2015 11:22 AM
but this was the only one.
More people had comments on the topics covered by the software engineering licensing exam, and opinions were split. Some thought it a good cross-section of professional practice (Casey Liss’s post was the archetype of this response), while others thought actual programming was seriously underrepresented.
I don’t have a dog in this hunt, but I have noticed that when programmers talk about software engineering as a discipline there’s a tendency to focus more on the process than on the result. It always sounds more like management than engineering.
Traditional engineers do spend a lot of time working with design, construction, and testing standards—organizations like ANSI and ASTM wouldn’t exist otherwise. And testing standards are very heavily focused on process because test results are comparable only if the process is consistent across all the tests. But design and construction standards focus on results—the properties and quality of the finished product—rather than on the means used to get to those results. No one cares how you came up with the design of your mobile crane as long as it meets all the strength and safety requirements.
The licensing exam questions reflect this. Electrical engineers are asked about circuitry, metallurgical engineers about heat treatment, civil engineers about pipe flow, and mechanical engineers about thermodynamics. Take a look for yourself. The exams for the traditional disciplines certainly have project management questions, but they’re a small percentage of the total.
The software engineering test, in contrast, looks to me to be dominated by project management questions. Maybe this is appropriate, but it does make software engineering seem like a different beast.
February 28, 2015 at 9:23 AM by Dr. Drang
A couple of days ago, I ran into an obscure bug in BBEdit. It was easy to find a workaround—which was fortunate, as I was in the middle of a project for work on a tight deadline—but I didn’t want to use the workaround forever. So I dashed off a quick bug report to Bare Bones. After a few emails back and forth, I now have my own artisanal version of BBEdit1 that fixes the problem. That’s customer service!
I found the bug through yak shaving. I was writing a series of Python scripts for structural analysis using NumPy and Matplotlib. I hadn’t updated either library in quite a while and found myself wanting to use a new feature that was only available in a more recent version. So I tried to update the libraries via
pip, but that led only to a long series of compiler error messages.
Screw it, I said, I’ll just install Anaconda and get up-to-date versions of a bunch of numerical and scientific libraries at once. This would mean installing an entirely new version of Python in addition to the libraries, and I’d have to do some fiddling to ensure that I always used Anaconda’s Python, but the tradeoff seemed worthwhile.
Anaconda installed itself without a hitch, and I only had to move a couple of homemade modules to its
site-packages directory and add one line to my
Now the Anaconda version of Python is the one invoked when I type
ipython at the command line or use
at the start of an executable script file.
So far, so good. But I also like to run scripts from within BBEdit using thecommand in its menu.
When I tried running my scripts this way, I got a long series of error messages, starting with the
import numpy as np
line near the top of my script and finishing with a line deep within Python’s
Because I was in a hurry to finish my analysis, I just ran my scripts from the Terminal, which never generated this error. I wrote a hasty bug report, sent it off to Bare Bones, and got back to work.
Patrick Woolsey, Bare Bones’s front line support guru, wrote back a couple of hours later asking for more information. He didn’t mention how poorly written my bug report had been, but I was embarrassed when I reread it—there was no way anyone could track down the bug with the information I sent in that first report. Now that I had more time, I was determined to send a more useful report.
After a bit of digging, it seemed to me that the problem lay in an environment variable set by BBEdit. The current version of the NumPy library runs
os.environ.clear() when it loads, and that’s what triggered the errors I was seeing. I sent off a much longer bug report with what I’d found.
The second report got a response the following day from Rich Siegel himself. I’m sure he had better things to do than track down a bug that maybe only one of his customers had or ever would run into, but I think it got under his skin. Later that same day, he tracked it down, squashed it, and sent me a link to a rebuilt version of BBEdit to try out. It worked perfectly, and I assume the fix will be incorporated in the next release. Until then, I have my own personalized version of BBEdit.
I’ve mentioned before how nice Bare Bones was in giving me the upgrade price on BBEdit when I returned to the Mac after eight years as a Linux (and Emacs/XEmacs/NEdit) user. And they’ve always been prompt and helpful when I’ve had support questions. But this particular bug fix went above and beyond my expectations. To be sure, it was a bug and did need to be fixed, but it certainly wasn’t a showstopper and didn’t need to be fixed so quickly.
I sometimes worry about using BBEdit. What if Rich decides to retire before I become too old and feeble to write anymore? Is there someone waiting in the wings to take over, or will I have to got through the trauma of learning another text editor? Emacs users don’t have this worry about Richard Stallman, and Vim users don’t have this worry about Bram Moolenaar. Their programming is already dispersed and doesn’t rely so heavily on the original developers.
On the other hand, if I were using Emacs or Vim I’d have many more things to worry about, chief among them my sanity. ⌃x⌃c :wq!
Which will soon be released to the rest of you plebs. ↩
February 26, 2015 at 10:02 PM by Dr. Drang
Brent Simmons has a good post today on ethics for programmers:
Were software engineer a profession like doctor or lawyer, we’d have a strong and binding set of ethics.
There is a code of ethics for software engineers—over and above the ACM code Brent mentions—but it’s known mostly to licensed professional engineers, and few programmers are licensed.
If you’re a regular reader of this blog or my Twitter feed, you know how hard it is for me to write the phrase software engineer. Deep down, I still think engineering should be reserved for work in the physical world, not in the conceptual world where most software resides. But the writing has been on the wall for a long time, and I don’t really expect the traditional definition to prevail. Nowadays my complaints about programmers calling themselves engineers are done as a joke in the “get off my lawn” vein:
@danielpunkass @caseyliss You software people are so cute with your ideas and stuff.
— Dr. Drang (@drdrang) Jan 14 2015 7:44 AM
@drdrang @caseyliss Excuse me, I am a software ENGINEER. I should know a thing or two about ENGINEERING, thank you very much. Look it up …
— Daniel Jalkut (@danielpunkass) Jan 14 2015 7:45 AM
Not that long ago, Daniel couldn’t be a licensed engineer, because there was no licensure procedure for software engineers, but that changed a couple of years ago. Now there’s a licensing exam for software engineering, although I don’t know how many states currently accept it.1 Each state has its own rules for the licensing of professional engineers, and some of those rules would probably have to be altered to allow programmers to get licensed, even with the availability of an exam.
(I am, by the way, curious what programmers think of the topics covered by the exam.)
Professional engineers are guided by the NSPE code of ethics. Licensed software engineers are no different. Strictly speaking, the NSPE has no statutory power—it’s just a professional organization like ACM—but state boards of registration do consider it when conducting disciplinary investigations.2
The six fundamental canons of the code are:
- Hold paramount the safety, health, and welfare of the public.
- Perform services only in areas of their competence.
- Issue public statements only in an objective and truthful manner.
- Act for each employer or client as faithful agents or trustees.
- Avoid deceptive acts.
- Conduct themselves honorably, responsibly, ethically, and lawfully so as to enhance the honor, reputation, and usefulness of the profession.
I’d say the Brent’s concerns about spyware and monitoring software fall under the “avoid deceptive acts” canon. Another section of the code states
Engineers shall avoid all conduct or practice that deceives the public.
I think that fits, too.
The purpose of licensure is to protect the public by guaranteeing a minimum level of competence in licensed practitioners. Typically, this means protection from physical harm. Since most software poses no risk of physical harm—beating your head against your desk when a program eats one of your files doesn’t count—licensure of software engineers may not seem that important. But as software threads its way into more aspects of our lives, our definition of protection will broaden, and more software will have to be approved by licensed software engineers.
The NSPE is an American organization, but most nations have a similar code of ethics for engineers. Several years ago, I was working on a project with a Canadian engineer who wore an iron ring on his right pinky. The Iron Ring ceremony is a wonderfully Victorian ritual (complete with text by Rudyard Kipling) to instill the ethics and obligations of the profession in young engineers. ↩
February 24, 2015 at 7:22 PM by Dr. Drang
When I ran across this New York Times article last night, I had a bad feeling. In classic inverted pyramid style, the gist of the article is in the first paragraph:
Turning what was once conventional wisdom on its head, a new study suggests that many, if not most peanut allergies can be prevented by feeding young children food containing peanuts beginning in infancy, rather than avoiding such foods.
Today I saw it at the top of the “most emailed” list the Times runs in its sidebar. This could be because lots of people are interested in peanut allergies, or science and medicine in general, but I suspect it’s really because the article confirms many people’s preconceived notions about overprotective parents, malpractice-averse doctors, and an alarmist press corps.
In fact, I don’t believe the reported study turns conventional wisdom on its head at all. Most of the people I’ve met who don’t have a child with peanut allergies were already certain that the problem was, if not entirely in the heads of a group of Munchausen-by-proxy parents, then certainly due to kids being raised in environments that are too clean, too safe, and too antiseptic. For these people, it’s obvious that exposure to peanuts will toughen up a kid’s immune system, and it’s about time doctors recognize that.
I am, as you’ve surely guessed by now, not a disinterested party in this matter. I’m not exactly sure when my wife and I realized our third child, Matt, had peanut and tree nut allergies, but he was pretty young. A little peanut butter at the corner of his mouth caused that side of his face to puff up and squeeze his eye shut. We thought back to a couple of times when he was even younger and had become suddenly sick for seemingly no reason. In one case he’d just eaten a piece of cookie that—we guessed in hindsight—had traces of nut in it.
Had we been especially cautious in what we fed Matt? Not really. He was, as I said, our third child, so we had the cavalier attitude common to experienced parents. Matt certainly didn’t get the intense scrutiny our oldest did. We fed him what seemed right based on what his older sister and brother had eaten when they were his age, adjusted for his apparent tastes and tolerances.
His tolerance for peanuts and nuts was essentially zero. When he went in for allergy tests, his reactions to the pinpricks on his back were so severe the allergist would stop the test before it was finished. When Matt was in elementary school, my wife once had trouble getting his EpiPen prescription filled at Walgreen’s. The pharmacist had no experience with a boy his age getting the full-sized EpiPen. He was sure the prescription should have been for an EpiPen Jr., but he was wrong.
Don’t get me wrong. I’m not saying the study is invalid or unimportant or that the Times did a poor job of reporting it. It would be wonderful if it leads to effective methods to reduce peanut allergies. I do, however, think this passage could have come earlier than the 16th and 17th paragraphs:
The study, sponsored by the National Institutes of Health and other organizations in the United States and Britain, involved infants 4 to 11 months old deemed to have a high risk of peanut allergy because they already had severe eczema or were allergic to eggs.
The infants were given skin-prick tests for peanut allergy. Those already allergic to peanuts were excluded from the study.
So this study has nothing to say about kids who have a peanut allergy before their first birthday.1 But that won’t stop your crazy uncle from emailing you the article and saying he knew it all along.
Actually, if you go to the New England Journal of Medicine article on which the Times story is based, you’ll learn that it’s more complicated than that. In the pre-trial screening, 542 children had no reaction and 98 had a relatively minor reaction to the skin-prick test. These were the children that were accepted into the trial. Excluded from the trial, and for good reason, were the 76 children who had a significant reaction to the pre-trial skin-prick test. ↩