May 1st, 2012
Firefox 12 was released last week.
One of the main features the release sports is “totally silent updates,” following Chrome’s path of “web-based version numbers”1 and going out of the way to obscure this information.
It will be interesting to see how this plays itself out.
Firefox 10 took us into the land of “always compatible” extensions2. Now with the obscuration of the act of versions changing, I wonder if the end-user’s experience will start to tend towards a more randomly-broken web browser, and users being confused why the extensions they were using yesterday are suddenly just-not-working today.
These are problems Chrome seemingly never faced, because they don’t have the rich ecosystem of addons that Mozilla does. This isn’t a particularly insightful revelation and I’ve even discussed it previously. I guess I’m still talking about it because I’ve never understood why Mozilla Corporation did it, beyond “because Chrome did it3.”
In any event, I recently got thinking about versioning again because of a conversation I had with a friend last week about version numbers and mobile.
We were chatting about our phones, and I mentioned I recently upgraded to iOS 5.1, having waited a bit to see how the update shook out on my friend’s iDevices.
He replied he’d been waiting for his carrier to roll out updates to “Ice Cream Sandwich.” I asked my friend—a college-level computer science instructor with a master’s degree in the subject—what version that was, and how it was different from… the previous version.
He answered “Oh… I don’t know. 2.3? 2.4?”
(It’s 4.0.x, actually.)
Thinking back to the features I use that were changed and updated in iOS 5.1, I said “Oh. Well… what’s different in the new release? What are you looking forward to?”
“Oh… … I have no idea. It gets stuck less in your teeth than Honey4 and is more satisfying on a cool day?”
The whole conversation was yet another great illustration of the point: not only do version numbers continue to matter… they matter in a marketing context.
They make it easier for your users to talk about your product in meaningful ways.
Obviously, number schemes are easier to test for equality and ordering, but they also can communicate the magnitude of change: an update from iOS 4.x to 5 communicates at a very intuitive cognitive level that the change is bigger than an update from iOS 5.0 to 5.15
These are important aspects when users want to identify, discuss, compare, and contrast features, stability, bugs, and overall usefulness of the products they use and (hopefully!) love.
After it was clear that our conversation about his Android phone simply didn’t have the adjectives necessary to meaningfully discuss, we moved on.
But my confusion remains: I still don’t understand the push (in certain circles?) to make our users’ conversations more difficult than they need to be.
_______________
1 aka “no version numbers”
2 Even if, y’know, the extensions are actually totally unusable on the new version
3 I can hear my mother saying “If Chrome jumped off a bridge…”
4 I think he meant Honeycomb
5 Some may point out that these numbers have sometimes been contorted to serve a business end; it is true this happens all the time; that’s a problem that solves itself when customers get burned by it too much.
Join the Conversation: 3 Comments »
V1103
April 27th, 2012
Just a quick note before your Friday happy hour get started: QuickRelease 0.14 has shipped.
This release focuses on a request we’ve had from many people: more documentation and examples.
0.14 sports:
We didn’t get to generated tarballs for releases in this release; that will be in 0.15. For now, you can grab a tarball from github as always.
We hope the documentation helps! If not, hit up the QuickRelease Google Group, and we’ll see how we can help!
Now, on to that happy hour!
Join the Conversation: No Comments »
V1093
April 24th, 2012
Last week, Robert X. Cringely did a fascinating four-part series1,2,3,4 on IBM’s failing fortunes.
It’s a great series of posts, and definitely worth your time, especially if you find you and your friends pondering the Old Guard’s tactical responses to current trends in our industry at cocktail parties5.
Cringely references a quotation from an old Steve Jobs interview to explain why the problem exists, and it really resonated:
The reason IBM can’t deliver is also explained well by Steve Jobs. It’s IBM’s maniacal fixation on process, once a strength but now a cancer.
“Companies get confused,” Jobs told me. “When they start getting bigger they want to replicate their initial success. And a lot of them think well somehow there is some magic in the process of how that success was created so they start to try to institutionalize process across the company. And before very long people get very confused that the process is the content6. And that’s ultimately the downfall of IBM. IBM has the best process people in the world. They just forgot about the content.”
This is a very astute observation7 and still an incredibly common problem, even today, with respect to process. You see it in organizations of all sizes, from start-ups to, well, IBM.
I think the issue stems from the notion that if it is assumed any good process can be scaled to any size organization or problem, then the structure of the process itself must be able to be extrapolated and specified. And because of this requirement that we do the heaving lifting to extrapolate, and all the work to specify it, it will remain consistent, and thus remain effective.
It’s a tantalizing notion. If true, it would mean one can make their finely tuned, tweaked, “perfect”-process into an asset, which they can apply everywhere and/or sell.
While there might be some truth in that—certainly, many attempt to make a living doing exactly that—ultimately the structure-of-the-structure of the process8 is more important than the structure of the process.
Put another way: good organizational (build/release) process has aspects that are clearly consistent across organizational size and disciplines, but trying to bolt the steps of a enterprise corporate security firm’s release process onto, say, a desktop client for a cloud-based media product, is a recipe for a lot of consternation9.
Pre-landing checklists obviously make sense for A380s just as much as they do for 182s; good checklists in both cases will have a natural flow which is backed up by the accompanying equipment’s ergonomics, seamlessly incorporate multiple checks for critical items, and are designed to fail-as-safely-as-possible.
But they’re very different checklists.
The desire to force “wrong-sized” process is what makes everyone roll their eyes and make that “I’m gonna barf”-motion capital-P Process comes up.
Figuring out what needs to go on their own release checklists, making it logically flow between their infrastructure and processes, and fine-tuning is one of my favorite exercises with my clients10.
One size certainly does not fit all, and transplanting process wholesale seldom works. But when we dissect effective process (and process management) from other disciplines, by taking a look at its structure, not the process itself, we can learn something applicable to release engineering.
And very valuable, too.
_______________
1 Part 1
2 Part 2
3 Part 3
4 Part 4
5 As I often do…
6 Cringely later clarifies: “In this instance content means the deliverable, whether a product or service.”
7 As most of Jobs’ are…
8 How very meta!
9 This may be obvious, but I see it all the time. Usually in reverse
10 If it’s something you struggle with, we should chat!
Join the Conversation: No Comments »
V1088
April 18th, 2012
Nathaniel Mott wrote an interesting piece on PandoDaily last week entitled Back-End Engineers Are the Unsung Heroes of the Tech Industry.
He argues that “Designers and front-end developers get all the credit,” despite the fact that the rest of the engineers supporting that whiz-bang device consumers want also make important contributions and have serious impacts on product quality and user experience.
It’s certainly a valid argument1. It can also a very demoralizing position to be in.
One of the core components of his argument is because technical topics like “wasted CPU cycles and their effect on battery life and “the costs of (effectively) Universal binaries” can be difficult to explain to end-users, this, in-part, is why back-end-engineers remain invisible.
To these things, I can only say: “come here and give us a hug! No, no… group-hug!”
In many organizations, those performing fundamental engineering support functions—QA, release engineering, and DevOps/TechOps—know exactly this feeling, and struggle every day to make sure what they do is visible without it being in such a manner that is associated with a disaster2.
The real trick is to find a way to not only make the case that these functions, which I fully agree support engineering, are critical and important in their own regard, but to try to find a way to make the fundamentals of what many of us do day-in and day-out more understandable, relatable, and heck… interesting.
I’m sure no one cares about gmake peculiarities, but “speeding the build up by 30%? Yes plz!”
And everyone loves to bad-mouth capital-P process, but that’s what turns that twenty-step ThingTM involving four-people stepping on each other editing the same wiki page into a self-serve, two-step process3.
Build/Release, QA, and DevOps Engineers have stories from their every day they could tell you about these sorts of things. All they need is someone to listen4.
And to our newest generation of “unsung-heroes”: you’re always welcome at our Unsung Heroes Anonymous meetings.
The coffee’s free.
And the cookies usually aren’t too bad.
_______________
1 Those claiming “engineers’ paychecks are they ‘thanks’ they get, and they shouldn’t expect any more.” are really missing the point
2 Most notably, in my profession, the release engineering team “blocking a release”; long-time QA’ers have felt the brunt of this too, I’m sure
3 If you follow these three simple rules
4 And maybe sometimes read a lil’ between the lines…
Join the Conversation: 1 Comment »
V1072
April 11th, 2012
I finally had the chance to read the ars technica piece on Facebook’s release engineering team that’s been sitting in a tab since last week.
Despite the article’s tone being a little… Charlie-in-Wonka’s-chocolate-factory-ish, it’s got a lot of interesting tidbits, and is worth the read. It’s especially interesting to see how Facebook’s unique engineering culture has shaped their release engineering process.
(Randomly: I actually worked years ago with Chuck Rossi for a few weeks at VMware before he headed over to Google.)
I did find this bit amusing:
I eventually reached the area where the release engineering team is headquartered. Like the rest of the development personnel, release engineering uses an open space at shared tables. But their space has a unique characteristic: a well-stocked bar.
(Emphasis mine.)
Maybe Google was right all along…
Join the Conversation: No Comments »
V1058
« Older Entries
