A while back, I wrote a post on why software should feel pain. Since then, I’ve had that lesson reinforced in my mind, and I’ve also understood some nuances that weren’t obvious to me before, so I’m revisiting the topic.
What brought this topic back to my mind was a root cause analysis I did to diagnose a recent system failure. I’ll spare you the gory details, but here’s what happened in a nutshell: a daemon got bad data files and began behaving strangely as a result. The replication process for its data files had been impaired because the app producing the data files finished much later than normal. That app in turn was impacted by anomalous network brownouts which began with a partly damaged network cable.
The Obvious but Naive Lesson
The final step in my root cause analysis was to make recommendations, and I was quick to offer some: the daemon should double-check the integrity of its data file; the originating app should monitor its timing and complain about anomalies.
The more I thought about it, however, the more unhappy I became. Surely, such monitoring is a good idea. So why did I not believe my recommendations would really make things better?
The pain pathway is more than nerves in the toes; it runs all the way back to the brain. From René Descartes’s Treatise of Man. (Wikimedia Commons)
My title might seem oddly out of place on a tech blog, but a slashdot post today led me to an email thread for linux kernel developers, and the thread and its fallout leave me troubled.
Apparently, a veteran contributor is leaving the kernel dev community because she feels like the communication style there is too harsh. This is unfortunate, but what seems even more lamentable to me is the lack of sympathy in Linus Torvalds’ reaction. It seems to me that his attitude is: “That’s just the way us kernel devs are, and we aren’t going to change to accommodate anybody. If you can’t take the heat, get out of the kitchen.”
This feels sad to me. Kind words can be such a joy.
[Image credit: Glen J. Photography (Flickr)]
Linus is a brilliant guy, and I’m grateful to him. I use linux and git every day; the tools he’s built do a lot of good in the world, and they replace earlier approaches that are clearly inferior. I also agree with his complaint that an explicit standard of “professionalism” in communication can, in some cases, lead to opacity, disingenuousness, and inefficiency. Sometimes we need to say things that are difficult for others to hear, and we need to say them quickly–and that may not jibe with the communication style of a slick politician.
However, I find it ironic that a profession so passionate about message passing and interfaces and producer/consumer contracts could lightly dismiss communication concerns when they involve humans. Do the messes created by DDoS, attackers probing vulnerabilities, and poorly behaved clients teach us nothing?
We certainly need clarity in our careers, and we may occasionally need bluntness as well, but we don’t need ridicule, sarcasm, or disdain. I applaud the sentiments of Marvin J. Ashton:
When an English speaker is drowning in details that make the big picture hard to see, she might complain, “I can’t see the forest for the trees.”
image credit: Miguel Virkkunen Carvalho (Flickr)
It’s an odd expression, partly ironic and partly humorous. When I hear it, I sometimes think of my sister, who, after moving from Indiana to Utah, complained that the mountains were getting in the way of her view. (Her tongue was firmly in her cheek… :-)
The expression also describes an important problem of software engineering–one that a lot of engineers don’t understand well enough. It’s a problem with generalization.
I’ve been involved in a learning experiment these past six weeks. Now that it’s winding down, I thought I’d reflect a bit on some themes that emerged.
For the past 9 months or so, I’ve been taking classes online from Coursera to complete a Cybersecurity specialization taught by the University of Maryland. I’ve learned about security and usability, various flavors of software vulnerability, secure integrated circuit design, digital watermarks, and encryption theory.
In early May I began the final class in the sequence–a capstone project where teams of students attempt to build secure software to match a spec, then try to break one another’s submissions with a combination of pen testing, static code analysis, fuzzers, and theory taught in our other security courses. The project is framed as an international coding/testing competition hosted on builditbreakit.org (hence the “bibifi” in the title of this post), and this May’s running of the contest includes several hundred very sharp participants from around the world.
Partial bibifi scoreboard, showing 5 of about 100 teams. I was on team “SEADA”. Net of score in buildit round minus bugs logged against code in breakit round shows current overall standings.
Sometimes developers limit the choices that are offered to their users as a way to simplify. This can be a good thing; I’m a big fan of simplicity.
However, this strategy comes with an important caveat:
If you’re going to force all choices into a few predefined buckets, you better provide buckets that match the needs
of your users
Broken buckets will not earn you brownie points. Or revenue.
image credit: Eva the Weaver (Flickr)
Today I was adjusting my 401k contribution. Here’s the broken buckets I saw when I logged in to the financial services website: