The dev team went on and had a party, they were rewarded for job well done, new and profitable functionality released. At the end of the year, Ops got penalized for the outage! Amazon rewarded development for releasing software and providing value and operations was not a part of that. They were in fact penalized for something that was out of their control.”

This is a great post, go read the rest.

When we look at what ‘CS researchers’ actually do, we see three kinds of people. We can describe them roughly as creative programmers, mathematicians, and bureaucrats.”

To excerpt from this post does it a great disservice, and, like most other things I post to my blog, is highly recommended reading.

From my time in undergraduate CS studies at a prestigious university (attached to the programming languages team, for good measure!), I can both accept and amend the author’s central claim: CS research sucks.

I worked on a team working on an optimizing compiler for the Java language that could detect when known transforms could be applied yielding a semantically equivalent, but faster, set of bytecodes. The platform gets marginally faster for everyone, should the research yield meaningful fruit and get adopted upstream. A noble goal, undertaken by earnest and intelligent men and women, but ultimately doomed.

One note the author does not strike is of the commercial nature of programming languages. Over and over, we see the pattern: evangelism, adoption, glut of choice, everything starts to suck and get vendor dependent, death. After its acquisition by Oracle, to the author’s “creative programmers”, Java is now in its final stage, destined to live as a zombie whose musculature (the JVM) is kept alive only by newer languages (e.g. Scala, Clojure, JRuby, Groovy, etc.) that target the platform. This fact should not be lost on the judgement of quality of CS research.

On the other side of the equation, programming an IDE that supported an alternative implementation of the generics which became part of the Java language in JDK 1.5 introduced me to basically all of the concepts I use still today as a successful programmer. It wasn’t because of the work I did faked on writing the grammar for this extended language, it was because of the techniques we used as a team in writing the IDE. Pair programming, test driven development, The Pragmatic Programmer, etc. It’s hard for me to think of that being a failure. I love programming, and it’s because of my time with the PLT team at Rice University. Thanks, Dr. Cartwright!

(Original via @puredanger.)

Nostrademons writes:

“That was one of the things that really surprised me about the real world: that big advancement only comes from big lateral jumps. Different companies, different projects, different markets, or different customers.
There’s this model of the world we’re taught as schoolkids – at least where I grew up – where you work hard at something, do as your told, and slowly but surely you rise up. And maybe at one level it’s true, but it’s very slow, and you’ll never become the sort of success you read about in the paper that way.

Instead, I’ve found that what usually happens is that you join an organization because you meet some minimum skill baseline that they’re looking for. And then as you practice and learn from the people around you, you end up picking up a bunch of other skills and getting better at your job. But the people around you generally won’t notice. First impressions usually pigeonhole you into a general category, and then people are blind to gradual changes.

So to reap the rewards of everything you’ve learned, you have to expose yourself to new people. Jump ship, and suddenly you seem really valuable to them, because all those skills you’ve picked up which your current organization takes for granted are new and useful.

There’s a leverage effect as well: people try to work with others of roughly the same level. If you’re diligent about practicing, you’ll go from being (hopefully) near the bottom of your team to the top of it. If you then repeat the process, your new teammates better be higher skilled still, and so your team as a whole can tackle more ambitious problems.”

Unless you work very hard at your communications within the organization, this is a very likely outcome. It may even be inevitable. Embrace it.

(Via @peteforde.)

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.

I’ve been following Ben for a long time, since he was doing podcasts (ps pipe grep!) with the other Joyent knuckleheads in 2007. I enjoyed reading this post, although it highlights how wide ranging the term “Devops” can be. My background couldn’t be more different. I started by only learning enough system administration to help run the Rails applications I wrote, and now I find myself looking at a trend in the server-side part of the operation that I think is very promising.

It’s not in the form of “what Devops means to me” but my post on Chef from about a year ago still captures what I think Devops has to offer the rest of the development stack, leading right up to the business. My experience is that the business is the customer of the developers, and the developers are the customers of ops. Successful devops can use either their experience as developers or their knowledge about the depth and breadth of systems to guide the process of putting together a high quality stack to meet business goals on the budget provided. I personally do not share Ben’s fear of having “hot Devops” take jobs from specialists– specialists are part of the team just the same.

With all these differences in approach and background, we still end up with a very similar idea:

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.

I am a “smallest team possible” sort of guy, so I happen to think that considering them three different cultures is a bit much, but I think it should be obvious that more and more recognized roles in engineering are popping up around communication. It’s a good thing!

Software engineering as it’s taught in universities simply doesn’t work. It doesn’t produce software systems of high quality, and it doesn’t produce them for low cost. Sometimes, even when practiced rigorously, it doesn’t produce systems at all.

That’s odd, because in every other field, the term ‘engineering’ is reserved for methods that work.

What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we’ll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being ‘anti-engineering’ (as they are often described), actually represent the best of engineering principles applied to the task of software development.

This is one of the finest talks I’ve seen in my time going to conferences. This version was given at the Lone Star Ruby Conference, but I had a chance to see it myself at Ruby Hoedown X in Nashville. Glenn and I also worked together on the project that brought me to Charlotte, originally. Thanks, Glenn!

Ethan and I came up with the ‘Zombie Team’ test for figuring out whether or not someone is ready to work on an intense project, be it a start-up or otherwise. The test is this: If zombies suddenly sprung from the earth, could you trust the perspective team member to cover your back? Would they tell you if they got bit? Most importantly would you give them the team’s only gun if you knew they were the better shot? If the answer is no to any of those questions you need to let them get eaten by the cubicle wasteland of corporate culture, because they aren’t ready for this kind of work.”

(Via 25 Best Startup Failure Post-Mortems of All Time.)

A great excerpt from a great post. Go read it, seriously! As the site no longer resolves, I wonder what became of it.

Does this sound familiar?

via @kevsmith

This is an area of great interest to me; I am fascinated by the marketplace. I share my skepticism about the form of the business described herein, but have heard of a company or two in the space. The primary issue I see is drawn from my own experience.

I was the lead developer for an application that grew large on my watch. My recollection of the message coming from presentations in the Rails community at the time was “Learn to be fast when you need to, because you probably won’t need to.” While this may be accurate since most projects are failures, it serves you poorly if you later learn that performance is important to you. It deals with capacity (another critical concept, especially in Rails) not at all. I wouldn’t be surprised to see the two equated by the community at large.

So what are the results of this message? Developers are writing applications that can get them into trouble– “design by laptop” has claimed many a deliverable, just that I’m aware of personally. They’re not familiar with operations. Their systems do not count on failure as an outcome. The architecture is poor. Many don’t know that there is a solution. Those that do scratch and claw to find one find that, unlike their development experience so far, tools and systems to increase capacity and performance require a great deal of knowledge to plan for their use. It is a complicated field requiring great study, and some mind-bending. This is the path I’m still walking down, months after leaving that lead developer job to start my own consulting business, and it’s humbling and awe-inspiring all at once.

Part of the issue there is that it can be difficult to find help– as the commenters to that post point out, engineers with this skillset are in-demand among the already in-demand Rails space. Talks on the issue are still rare. I wrote about my love of Chef recently, which includes some exhortations of responsibility on the part of developers, but– let’s get serious– very few are listening to me right now. That’s OK, I’m working on it.

At the end of the day, these issues matter. Knowing what to expect from your operating system, your VM’s, and your architecture is crucial to acceptable response times and uptime when you start getting the traffic that will make your business a success. Shouldn’t our entire community be more interested in ensuring that our applications have an upside? There is no silver bullet for this problem, not even hosting with Engine Yard or Heroku. Shouldn’t we have it as our mission to ensure whoever owns this registration lets it expire?

Some highlights:

Dynamism

• Disintermediation: Developers can freely experiment.
• Isolation: Applications safely co-exist
• Utilization: Best use of expensive resources

This is what you are paying for.

Cost

• CapEx versus OpEx
• The Cloud is not “Cheaper”
• Do you have money, time, or experience?

What are you willing to pay for?

My Thoughts

There is a tremendous amount of information in this slide show, and I can only fully contextualize parts of it. Exciting times are ahead.

I couldn’t agree more with the observation that much complexity can be moved up the stack to the HTTP protocol. The tooling around the message’s form and its method of delivery are multiplying in number and accelerating in quality. And you can read the results in your browser, sometimes, too!

(Via @fastip.)

I’m fascinated by scale, particularly this definition via absence.