Especially for complex, multi-purpose systems, the gap between how things are supposed to work and how they actually work can be quite large. (Ask any police sergeant about the difference between policing in theory and policing in practice!) A primary function of operators is to bridge this gap in ways that result in better rather than worse outcomes. The capacity of systems to be operated is what allows operators to perform this valuable function, sometimes called technical work.
~ Richard Cook
More and more I’ve been getting a lot mileage from this idea: Make things easier TO USE, rather than trying to fully automate (i.e., so I don’t have to use them.) One cornerstone to accomplishing that is creating “affordences“.
The Heartbleed OpenSSL problem is big news ( http://heartbleed.com if you’ve been under a rock ). What’s wrong?
In short, Heartbeat allows one endpoint to go “I’m sending you some data, echo it back to me”. It supports up to 64 KiB. You send both a length figure and the data itself. Unfortunately, if you use the length figure to claim “I’m sending 64 KiB of data” (for example) and then only actually send, say, one byte, OpenSSL would send you back your one byte — plus 64 KiB minus one byte of other data from RAM.
~ Matt Nordhoff
So this one, tiny-looking problem brings our entire sand-castle Internet kingdom down. “Secure” web sites turn out aren’t necessarily secure. Worse, they haven’t been secure for some uncertain amount of time. So, anything communicated insecurely, during some uncertain time-frame… is, uh, possibly snooped, stolen, etc. The system admins have to patch the fix in, then redo site certificates, then everything everyone has put to/from those sites, (your login and password for example!) has to all be considered stolen/tainted and has to be reentered.
Bonus: it’s even worse than I’m making it sound: Try this on…
The Senate Judiciary Committee spent the day looking into recent data thefts at Target and Neiman Marcus. Lawmakers know there is a big problem, but they are struggling with what role the federal government should play is creating new standards to safeguard consumer data.
~ Jim Zarroli
Yeah. I said this before.
Other people are recognizing that we work in an important intersection of knowledge and responsibility, too. I came across a presentation from this year’s Chaos Communication Congress in Germany. It was a talk by Jacob Appelbaum and Julian Assange, who were introduced by Sarah Harrison. The name of the talk was SysAdmins of the World Unite.
~ Matt Simmons
If I were in government right now, I would be leery of starting another big software project. I’d also know that big software projects are going to be necessary as our civilization gets more and more complex. So, if I were in government right now, I’d be thinking about laws to regulate the Software Industry. I’d be thinking about what languages and processes we should force them to use, what auditing should be done, what schooling is necessary, etc. etc. I’d be thinking about passing laws to get this unruly and chaotic industry under some kind of control.
If I were the President right now, I might even be thinking about creating a new Czar or Cabinet position: The Secretary of Software Quality. Someone who could regulate this misbehaving industry upon which so much of our future depends.
Maybe that thought hasn’t occurred to them yet. Maybe. But how many more healthcare.gov debacles will it take before it does?
~ Bob Martin
Most people I’ve talked to, (who write software or do systems and network administration,) are in the “I have work to do” camp. They’ve no time to think about professionalization, or standardization, of their field. To which I say:
That’s cool; I understand. No worries! The government will eventually get around to ramming standardization and licensing down your throat. I’m sure that will work out well for us.
If you work in these fields, you should be paying attention. If you wok in network and systems administration, you should be paying attention to LOPSA and Usenix/LISA.
Feb 2014: Senate Steps Into the Data Breach Controversy
Just in case you thought it was fairly new, it’s probably(*) older than you. Here’s a deep link, to a down-the-rabbit-hole discussion. Seems most sources attribute a 1968 conference, while the author of this message from the Software Craftsmanship group has dug up an ACM article from 1966.
* …and probably significantly older than you since the average age of the entire world population is definitely less than Software Engineering’s 47 years (and counting.)
They then mapped out the correlations between the various symptoms, creating a network. An increasingly standard tool in network theory these days is cluster detection–the ability to spot parts of a network that are more strongly linked together than others.
Acute mountain sickness (AMS) is a common problem among visitors at high altitude, and may progress to life-threatening pulmonary and cerebral oedema in a minority of cases. … These results challenge the accepted paradigm that AMS is a single disease process and describe at least two distinct syndromes following acute ascent to high altitude. This approach to analysing symptom patterns has potential utility in other clinical syndromes.
In fact it is so difficult to argue against simplicity that this post won’t even attempt to. Let’s state emphatically that software should always do only what you need it to do, with the fewest number of steps, and least potential for errors due to complex choices and options.
On the other hand, good luck with that.
~ Steven Sinofsky
The Internet is a surveillance state. Whether we admit it to ourselves or not, and whether we like it or not, we’re being tracked all the time. Google tracks us, both on its pages and on other pages it has access to. Facebook does the same; it even tracks non-Facebook users. Apple tracks us on our iPhones and iPads. One reporter used a tool called Collusion to track who was tracking him; 105 companies tracked his Internet use during one 36-hour period.
~ Bruce Schneier
…and he wrote that essay before the Snowden/NSA revelation showed us we’ve gone far beyond it being only an Internet surveillance state. We have collectively delivered ourselves into the power of ideas we do not know we have accepted.
(Part 3 of 72 in My Journey)
Getting done right does not mean getting done slow. Getting done right means getting done fast. You will go faster if you do things right. You will go faster if you come down off the “high” generated by the illusion that effort is speed. You will go faster if you calm down, follow your disciplines, and refuse to rush.
~ Bob Martin
While he’s talking about software development in general, and test-driven development specifically, this is true for – I think – everything. My experience is that this is true for software development, and other technical work. But it is also true of martial arts practice, parkour, games, building model airplanes… you name it.
The pervasive admonishment should be “do it well,” rather than, “slow down.” Do it well and you’ve – by definition – done it as fast as possible. What’s the point of doing it poorly? What’s the point of rushing to completion; If you didn’t do it well, then it’s not done.