Archive for December, 2010
Gavin Clarke of El Reg has written a really nice piece based on an interview with Scott: McNealy to Ellison: How to duck death by open source: Ex-Sun boss talks code, community, and underpants
Unlike so many other articles, this one is fair, balanced, and very respectful of Sun and its legacy.
My favorite quote has to be this, referring to the tactics of Microsoft, Intel, and the like: “I feel good as a company we didn’t engage in that. I sleep better at night — but not on a yacht!”
I’ve always felt uneasy about the pairing of “computer” with “science”. There are two reasons. First, “science” is conventionally realized as the observation of nature; since computers are man made the rules we may derive from observation and analysis may not be applicable when we build a better or different computer. The second is that “computer science” in industry rarely seems to exhibit any of the distinguishing marks of “science”.
Perhaps you have had similar thoughts… but like so many things that flutter in and out of our heads on a daily basis never got around to digging deeper on the issue. I therefore thought I’d pass along some interesting research/discussion on the subject for your personal edification.
The first is The Cruelty of Really Teaching Computer Science (PDF) by E. W. Dijkstra written in 1988. The paper is hand-written and a joy to read. Its a bit long, but reads quickly. When reading it I found my self nodding a lot and feeling a joy that someone of such immense talent and honor has throughly given thought to these things.
The second is a piece in Wired from 2007 in which Bruce Sterling summarizes an ACM interview with Peter Denning: Computer Science. Is it Really a Science, and What’s It a Science About? in which the subject is address head on. Peter here discusses his project to produce a set of solid principles of computer science, to put these questions to bed. The results of that project are found on the site: The Great Principles of Computing project
These two resources should help you significantly along your way. There are many more, but these two stand out to me. And, because I think they are so interesting and important, I shall not do you the disservice of any further description here.
It does, hopefully, raise in your mind a question on you can answer about yourself: “Am I an engineer or a technician?”
As I pointed to in a recent post, an Engineer is “the discipline, art and profession of acquiring and applying scientific, mathematical, economic, social, and practical knowledge to design and build structures, machines, devices, systems, materials and processes that safely realize solutions to the needs of society.”
A technician is “a worker in a field of technology who is proficient in the relevant skills and techniques, with a relatively practical understanding of the theoretical principles.” So says Wikipedia. The entry continues with a useful example: “For example, although audio technicians are not as learned in acoustics as acoustical engineers, they are more proficient in operating sound equipment, and they will likely know more about acoustics than other studio personnel such as performers.”
Dijkstra argues that we do ourselves a disservice by preferring the term “bug” (which seems somehow passive and inevitable) instead of the more accurate “error” (which is active and direct). In the same way, I think we do ourselves a disservice by blurring the lines between “engineer” and “technician”.
Lets take a little journey through a thought and see where it shall take us.
Let us first consider “devops”. It is a cultural movement which codifies various characteristics, including the zen like interweaving of development and operations, better integration of “IT” with the business objectives as a whole, infrastructure as code, agile (or lean depending on who you speak with) operations, etc, etc. Alright. As I’ve stated in the past, its all the things ITIL claimed to be but somehow more hip. Alright, capture that in your minds eye and then move it aside.
Next consider the title “Systems Engineer”. It is a very ambiguous title to be sure, because it is cross discipline. Borrowing from WIkipedia: “Systems engineering is an interdisciplinary field of engineering that focuses on how complex engineering projects should be designed and managed.” OK… now, lets break it down into its consituent parts. An engineer is, Wikipedia says: An engineer is a professional practitioner of engineering, concerned with applying scientific knowledge, mathematics and ingenuity to develop solutions for technical problems.” Alright, and “system” comes from Greek literally meaning: “whole compounded of several parts or members, system”. Great, now put it back together… a System Engineer is one who solves technical problems using science and math to to make diverse components act harmoniously together as one. Great, put that aside.
As a geek, I have two pictures of the classical “systems engineer”. The first is a guy at NASA building the lunar lander, pocket protector and slide rule in hand, he’s making sure he can cram everything he needs into a landing module while still fitting on top of a rocket and capable of re-entry into the atmosphere. This guy has to think outside the box, consider every detail and yet be flexible enough to change the plan, like splitting the lander into two pieces, one which stays on the lunar surface and the other that blasts back to earth, etc. The other guy is a “kernel programmer”, I put that in quotes because maybe they might build compilers or drivers or libraries, but these folks know their ASM and don’t think FORTH is out of style yet. Most of these guys are up there in years, work at stodgy companies, and don’t have much of a sense of humor. Externally these guys don’t seem much different… ones at AT&T or IBM, the other NASA, but the same image:
Lets now consider OS’s and computers. On the whole, OS’s aren’t changing. Is Linux fundamentally that different than other UNIX’s? We’re not seeing radical shifts in what we use. Similarly, in the chip space we’re all now comfortable with the reality that 5GHz CPU’s aren’t going to pop up any time soon (at least, not in general use) but we’re going to get more and more 2.xGhz cores. 2, 4, now 6, etc. Even your parents little Dell now has 2 or more CPU’s, soon your kids will have a laptop with 6 or more… and they won’t know or care. The point is that we’ve hit a maturity point in which the building blocks are pretty solid, but the way in which we use them is now more interesting. The old image of the Systems Engineer feels, well, old.
OK… lets now knit this together.
When I first came in contact with the “Devops” movement I thought it was about better systems administration, a maturing of the craft. It was, I thought, more about Ops and less about dev. Dev had their day in the sun with Agile… now sysadmins were getting theirs. Remember, if you can, when Agile came on the scene and how giddy developers got with eXtreme Programming, then Pragmatic Programmer books are everywhere, and then SCRUM comes along, and its all about this “lets do the old thing, in the new way” excitement. Re-inventing the craft for a new age. I thought devops was that.
But that initial view is fading away.
System Administrators have a weird legacy. Very very few of us set out from our youth into the craft. More common are stories, fables really, about the Physics PhD who got more enjoyment out of the computers than they did the calculations they ran on them. From various technical paths, they came and feel in love with the tool rather than the task it was used for.
Now look at our books and our talk. We view our worth in our expertise in various technologies. The Linux expert, the Storage expert, the HP-UX expert, whatever. And knowing all the surrounding technologies and how they fit together, such as DB2 installation, performance and backup on AIX using IBM POWER systems. Up to date on the latest LTO advances, an answer for every little hickup of NetBackup. I mean, look at the most fundamental books for aspiring SA’s, they tell you how to learn the various UNIX OS’s, install software, manage hardware, back shit up, and use scripts to glue things where necessary.
These devops guys I’m meeting don’t fit that criteria. Or even that legacy. They are something new.
Everyone is quick to tell you that “devops” is not a role, nor a title, nor a job description. Its a culture. To which I say, enthusiastically, right! Except… the devops guys I keep meeting don’t look, act, or sound like systems administrators. I was most aware of this at LISA this year. Looking around at my fellow administrators, I didn’t get a “devops” vibe from the vast majority. The uber-nerds around the LOPSA table? No devops vibe.
The people that I met that seems to “get” the devops culture are devs. But not that kind… You see, they profess years in administration or ops, but they more excited by JSON and AMQP than they are by the next release of their favorite OS or chip architecture. These people no longer see computers as autonomous entities, rather they see the protocols to link them. They are more excited by NoSQL databases that can house metrics than they are in the commands and interfaces they can get them from. Spending time learning every little feature of an OS isn’t exciting, but optimizing inter-system communication is.
What I’m driving at is that the most interesting artifact of the “devops” movement is that its bringing a new generation of Systems Engineers out of the closet. They are devs in an ops world. Not dev for dev sake… not ops for ops sake… but rather dev for the sake of ops.
These people say its about bridging the divide, tearing down the wall, etc. But I don’t buy it. The most astute among them will recognize that you will still need “experts” on either side of that wall, who might not “do much” (which is one hell of an understatement) but do it very well. So, this idea that “devops isn’t a title” and yet “we still need specialists” seem to logically conflict.
It is therefore my assertion that “devops” isn’t a job title, but Systems Engineer is, and when you look at the folks really exclaiming the joys of it, they really seem to me to be Systems Engineers, or fanboys, who are spreading their joy of having found their new nitch in the universe.
Were not done yet……. let me explain why I think this is important.
As the good news of “devops” spreads it first enlightens, then brings excitement, then dread. If your one of those “specialists”, you can easily feel that your now out-dated. Consider that there is now pride within the devops elite that CIO’s are now talking about having a “devops strategy”. Some even suggest a (I’m paraphrasing) “evolve or die” scenario for operations teams. If your a sysadmin who uses Borne or Korn shell instead of Ruby, look out! I don’t think that’s fair, nor do I think its true for all. Instead, it all makes more sense when you see it as three camps instead of two, with a the culture over the three… that is, applications developers (traditional “dev”), system administrators (traditional “ops”), with a new role in the middle of Systems Engineers that helps glue the camps together. Some of your Systems Engineers will emerge from the dev side, some from the ops side, always having hidden their secret urges to do both. And, as with any emergent role, many will aspire to it but simply not be cut out for it.
Devops is a culture. Yes. Devs get it, Ops get it… but this new generation of Systems Engineers have it in their hearts, and you can see it in them. They are special… not better, just different. Like all of God’s creatures.