Continuous Integration

Release Schedule

October 2015
S M T W T F S
« Nov    
 123
45678910
11121314151617
18192021222324
25262728293031

Branches

Twitter

© 2015 - 2020 The Sober Build Engineer | Simply ship. Every time.

Simply ship. Every time.

The Fall of the Wall Between Dev and Ops

11/12/2014

From an article in the New York Times:

[F]iles demonstrate how members of the regime did not trust their colleagues, or their subordinates—and that this lack of trust gravely undermined their ability to blunt the rising revolution.

Sounds like how some organizations are struggling to deal with the tectonic shifts generally occurring within our industry.

(Though it’s actually from an article on the real causes of the fall of the Berlin Wall, which recently crossed the 25th anniversary mark.)

Sprinting on the Treadmill

06/06/2014

Shortly after Pete Cheslock’s talk at DevOpsDays Pittsburgh, I tweeted:

Wanting execs to value trust & learning will be a losing proposition until we stop firing ‘em for missing a quarter’s numbers #devopsdayspgh

The context was about building DevOps culture and practices within the organization, and giving people the time and space they need to learn and adjust. Andrew Shaffer talks a lot about this as well in his talk on building learning organizations.

I was reminded of this dichotomy (and probably the largest, most difficult-to-solve elephant in the so-called DevOps room) in an article in the Harvard Business Review about high-frequency trading:

Now, there are some rockstar CEOs — who oftentimes happen to be founders, such as Bezos, Steve Jobs, Reid Hastings — who have the ability to resist the pressure that the markets put on them. But what about everyone else? Well, it’s becoming increasingly hard to resist that pressure. The financial markets put pressure on you to generate the type of returns they’re looking for: quarterly results. If you’re an executive and your job lives and dies on those results, then you begin to realize that that’s what you need to deliver. Projects that take longer than that to materialize — particularly those that result in an upfront dip in earnings due to investment — get deprioritized.

In effect, financial markets are pushing companies to run a marathon… by having them sprint every lap.

I hear colleagues and clients murmur about this problem in various contexts, often in relation to how Agile is applied in an organization: once a cadence is achieved on the team and working well, the desire to “optimize” it starts to rear its head.

I think we have a similar problem within the DevOps space… and we’re going to have to find a credible way to address it. Or we’ll continue to remain stuck on “Why didn’t that DevOps Tool I bought solve our problems?”

A Winning Strategy

05/16/2014

I was reading about infamous Microsoft Technical “Evangelist” Jim Plamondon, at the suggestion of Matt Ray; I found this gem:

Mopping Up can be a lot of fun. In the Mopping Up phase, Evangelism’s goal is to put the final nail into the competing technology’s coffin, and bury it in the burning depths of the earth. Ideally, use of the competing technology becomes associated with mental deficiency, as in, “he believes in Santa Claus, the Easter Bunny, and OS/2.” Just keep rubbing it in, via the press, analysts, newsgroups, whatever. Make the complete failure of the competition’s technology part of the mythology of the computer industry.

Emphasis mine, obviously.

Compare that with Linus’ eloquent comments in 2007 about his beloved Git:

You can disagree with me as much as you want, but during this talk, by definition, anybody who disagrees is stupid and ugly. So keep that in mind. … [Y]es, I have strong opinions. CVS users… if you actually like using CVS, you shouldn’t be here. You should be in some mental institution… somewhere else.

For all the cawing Linus has done over the years about how horrible Microsoft is, it’s nice to see that he at least learned how to employ a winning marketing strategy from them.

Lies for Sale

05/12/2014

Like most people, I have too many tabs floating around in my browser. I just finished reading a New York times commentary that’s a couple of months old now, but well worth the read; it’s called “The Surprisingly Large Cost of Telling Small Lies.”

Some relevant quotations:

I did some research and it seems most of us lie quite a bit. A study by the University of Massachusetts found that 60 percent of adults could not have a 10-minute conversation without lying at least once. … Teenage girls lie more than any other group, which is attributed to peer pressure and expectation. The study did not investigate the number of lies told by entrepreneurs looking for investment capital, but I fear we would top the chart.

So yeah, yeah… lying is “bad,” but why is it more than just a morality issue?

Peter maintains that telling lies is the No. 1 reason entrepreneurs fail. Not because telling lies makes you a bad person but because the act of lying plucks you from the present, preventing you from facing what is really going on in your world. Every time you overreport a metric, underreport a cost, are less than honest with a client or a member of your team, you create a false reality and you start living in it.

You know the right path to take and choose another, and in so doing you lose control of the situation. Now, rather than tackling the problem head on, you have to manage the fallout from the lie. I know people who seem to have spent their entire careers inflating the truth and then fighting to meet the expectations they have set.

I think that nails it on the head: it’s the false cognitive context that we create for ourselves and our teams which creates the negative results.

If you don’t think it happens in our (DevOps-y) world, you’d be wrong: I’ve called out blatant lies and constructed metrics, for precisely the purpose of creating a false historical reality, here on this blog.

Lying always catches up with you, in one way or another.

At Least History is Consistent

03/01/2014

From How Silicon Valley Became The Man:

That’s all a way of ignoring the systems that make the world possible. One example from the ‘60s that I think is pretty telling is all the road trips. The road trips are always about the heroic actions of people like Ken Kesey and Neal Cassady and their amazing automobiles, right? Never, never did it get told that those road trips were only made possible by Eisenhower’s completion of the highway system. The highway system is never in the story. It’s boring.

—Fred Turner

Apparently, well-designed, stable (even revolutionary!) infrastructure has always been boring.

As have “the squares” who toil to build it.

A Post-Planet Module World

02/15/2014

I’ve been a Mozilla Planet module peer since the module was created in 2007.

The module, as incepted then, might have never existed, were it not for the issues I raised… but alas I’ve told that story already, and if you really care, you can click that link.

As originally created, our role was to attend to requests related to Planet’s settings and feeds, respond to technical issues as they arose, and ensure that Planet and the content it hosts serves the needs of the Mozilla Community.

Functionally, this came down to two major activities: researching and approving RSS feed additions and deletions. And making policy around content-appropriateness, including rulings whenever questionable content appeared on Planet.

We’ve been coasting on both of those mandates. For awhile now. And yet, this paralysis isn’t particularly surprising to me.

There have been instances where we, as Planet Module stewards, have been asked to “sit out” of discussions related to Planet1 and its operations. Whatever your opinions on this, it’s had the side-effect of gutting momentum on any initiatives or improvements we might have discussed.

It’s gotten so bad that there have apparently been a number of complaints about how we’ve been [not] doing been doing our jobs, but that feedback hasn’t effectively been making it to the module leadership. At least not until there are people with pitchforks.

There’s so much frustration about this issue, a Mozilla Corporation employee emailed the Planet list last week, all but demanding to be added as a peer. There was no hint in the message that any discussion would be tolerated. And while I disagree with his methods and logic, I certainly understand his frustrations.

Additions and deletions to a config file in source control aren’t rocket science.

And as for our other role—creating an acceptable-content policy for Planet and discussing those issues as they arise—Mozilla now has a Community Participation Guidelines that supersede anything a module owner or peers would say.

The fundamental issue, at the time, was one of free speech2 versus claims of “hostile work environment” and “bigotry.” While it’s unclear who is responsible for interpreting the Guidelines3, the Guidelines do take precedent over the Planet Module.

Without the policy responsibility, the Planet Module seems to me to be effectively reduced to something you could challenge a summer intern to automate4.

Who knows what the Planet Module will become. But I’m not interested in joining on that journey. So I’ve resigned my Planet module peership5.

So, as they say… so long. And thanks for all the RSS feeds.

__________    
  1. Don’t ask me by whom; I’ve asked repeatedly; I’ve been refused an answer every time↵
  2. Specifically, endorsing a political position↵
  3. Though, one can guess: I’ve only ever heard one answer to “Who is the final arbiter at Mozilla?” as long as Mozilla has existed↵
  4. Though, like most problems presented to software engineers, it’s not as simple as you might imagine↵
  5. Technically, effective last week on February 9th; but it’s been a busy week, so I didn’t have time to write about it until now↵

Now Showing: Your Life

01/31/2014

My grandmother passed away last week. She was 85.

Due to a series of poor choices1, compounded by the geriatric randomness, her last few weeks were spent in a county nursing facility. So the platitudes we all hear2 about “being in a better place now” are most certainly true.

When I look back upon time spent with her, I can safely say she was one of the few3 souls I’ve known with any familiarity or emotional intimacy whom I’d considered tortured. Of course, being a teenager during the prime years of World War II4 left her with scars I can’t begin to fathom.

In the aggregate, she did the best with the skills she was afforded, in the environment she was dealt, in the cultural context of the era she landed in. And I understand and empathize with that.

Alas, she spent most of her retirement years searching for solace from those demons. Oddly repeating her first years in this country, she spent much of her retirement moving around. I think she was searching for happiness, as if it were a physical place you could pack up and move to. I’m not sure if she ever understood that many of the things that made her stressed and unhappy were within, along for every move, and getting rid of them to get to that “happy place” involved some serious self-unpacking.

That’s probably one of the lessons I’ve learned from her that I’m most grateful for5.

***

Experiencing the death of a family member earlier in life prompted me to think more than I ever thought I would at that age6 about what happens when we die. And I find myself thinking of it again now.

Obviously, no one really knows what happens when we cease to be of this world7.

One of my favorite ideas about the immediate-afterlife is that of a grand movie theater… one of those that reminds us of Hollywood’s Golden Age8. A concession stand has all of our favorite treats. As we sit down in the empty theater—in our favorite row—an usher comes by and gives us a remote control.

As the movie starts, we soon realize it’s the story of our lives, from birth to death. As we get past the shock of watching ourselves be birthed, the purpose of the remote becomes clear: we can fast-forward, rewind, and zoom in and out of the movie unfolding before us. Think those movies with grandiose, interconnected plots9, that weave in and out of each other. Except… y’know… you and the people you knew.

That girlfriend that broke up with you? Now you’ll know the real reason why. That company you loved, who hired a director to replace you? Watch the scenes in the VP’s office and know what really happened. That first time you drove a car, or soloed in an airplane, or really felt like you grokked that Thing You Love: experience again how awesome it was. Those months after That Person died that were a visceral blur of emotion? You can watch those again too, in an as much or little detail as you’d like, as many times as you’d like. The fast-forward, rewind, director’s commentary, and “Special Features” buttons are yours and yours alone.

I find this idea alluring because parts of the life I’ve lived, I feel like I don’t have a clue why they unfolded the way they did. And as a pattern-matching engineer, that bothers me a lot. I really wish I knew the rich, complex story of the good times, so I could repeat them and the intricacies and influences of the bad ones, so I could avoid them in the future.

There’s a twist, though: this cozy theater, with all of your favorite snacks refilling endlessly, and an almost-infinite story to re-experience… sounds a little like purgatory. And that’s sort of the point.

As I go through life, deciding what it’s OMG REALLY IMPORTANT I care about and what may be less so… as things blindside me and I react (or falter while doing so)… as I think back on all the mistakes I’ve made, I hope such a great theater, where we truly get the opportunity to understand What Really Happened exists.

Part of me also feels like the goal of life here is that once we’re offered that ticket, we’re able to politely decline it, secure and happy in the choices we’ve made and the outcomes that ensued, and having made peace with the people and events that didn’t turn out the way we had hoped and planned.

I try really hard to live like that, even though I know I wouldn’t be able to decline that ticket right now… too many unanswered questions.

Assuming it’s anything like this, I suppose none of us knows how long we’d want to stay in that dimly lit theater, replaying our story… until that moment where that Featured Presentation starts.

__________    
  1. Probably the last legally-competent ones she made↵
  2. And say↵
  3. Only?↵
  4. On the eventually-losing side, too↵
  5. It’s also one of the lessons which I struggle the most with, and which scares me the most that I won’t ever learn… by I digress↵
  6. My early 20s↵
  7. Which is part of what makes it an interesting thought exercise↵
  8. Not unlike the Castro Theater↵
  9. A la Heat, Crash, Babel, Valentines Day↵
5-31

The Rise of BlahOps

01/28/2014

Last week, Perforce’s Matt Attaway and I got into an interesting twitversation de-constructing our beloved “DevOps” word.

It all started because I received an email from a recruiter with a job description referencing a “DevOps team”1, but with a description2 that sounded eerily familiar to the bread and butter of a build/release team.

Matt suggested I start a “BuildOps” movement, where I “Take all the existing text on build; s/build/BuildOps; profit!” Despite lamenting the overuse of the term “$blahOps,” the sad part is: he’s probably totally right; there probably is a mint to be made with some awk‘ing there.

What I thought most interesting, though, was his last observation on the matter:

We’re stuck with $blahOps I think. Movies have trained us to think ‘BlackOps’ are cool; anything + Ops sounds more awesome.

I’d never thought of it that way, but I think he’s onto something there. The imagery of Army-green helicopters, with soldiers jumping out of them, yelling “Go, go, go!” is not far in our imaginations whenever the word “ops” is uttered.

The irony of it all is that as many organizations try to transform themselves to the new, improved “DevOps” versions of themselves, they still ignore or under-invest in operationalizing their teams and their infrastructure. Myriad examples abound in anonymous, complain-y tweets: the CI server under the desk (or “in the cloooouuuud!” paid for with one developer’s personal credit card account3), the “just throw all the bits on S3, it’s fine” “artifact-management strategy”, the continuously muddled communication about who is responsible for which tasks, the shoving others aside justified as “just gotta get my job done”4, the indictment of the mere notion of repeatable process or consistency across actors5, the withstanding people not in right roles6. These are all antithetical behaviors of these “[Black]Ops” teams we so idolize. And yet, we think if we tack Ops on, some of that magic will imbue itself to our endeavors.

Of course, the part those movies often gloss over is the many hours7 these teams spend training and getting to know and trust each other, and how much stock they put in process (and yes, even Process) for the simple things, precisely so they can save their energy, mental and otherwise, for the complex and unexpected.

The lesson, illustrated once again is: just adding “Ops,” Dev- or any other kind, to your organization isn’t going to solve problems, business or otherwise… even if it does sound cool8.

__________    
  1. Strike one↵
  2. “… an opportunity for a Sr Build/Release Engineer to join a DevOps team responsible for Build, Release software packages [sic] as well as deploying to different Cloud [sic] environments.”↵
  3. They’ll never leave the company, obvs↵
  4. Instead of working with and trusting them↵
  5. “Because, dammit, I have thoughts and feels on Python formatting AND THEY’RE IMPORTANT SO EVERYONE NEEDS TO LISTEN!!”↵
  6. In effect, sabotaging the team↵
  7. Years?↵
  8. It’s not lost on me that the word “DevOps” has just the right mix of stop consonants and affricates (for English speakers, anyway) to really roll off the tongue… and I doubt it’s lost on our subconsciouses, either.↵

Mobile Doesn’t Suck: The Web Made Us Lazy

01/17/2014

I recently read Tim Bray’s Software in 2014, a sort of “state-of-the-industry” post, including what to watch for in the upcoming year.

It was a good read, but I found one of his observations, on the mobile space, interesting:

The update cycles are slow. Days in the case of iOS, hours for Android (compared to seconds for browser-based apps). What’s worse is that you can’t even count on people accepting the mobile-app updates you send them. Got a critical data-losing account-compromising privacy-infringing bug? Sucks to be you.

I LOL’d when I read this. Literally. Read More

Older Posts