Posts Tagged ‘process’
Friday, 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!
process, quickrelease, tools
Releases, tipstricks | No Comments »
V1093
Tuesday, 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!
commentary, organizational interaction, process, release engineering, strategy
Preed on Build/Release Engineering | No Comments »
V1088
Wednesday, 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…
commentary, organizational interaction, process, strategy, teamwork
Preed on Build/Release Engineering | 1 Comment »
V1072
Friday, March 9th, 2012
I’m still very much enjoying Robert Glass’ The Facts and Fallacies of Software Engineering1
I’m still making my way through it, but I wanted to call out a corollary to one of the facts he covers (which even he calls out as possibly controversial):
An Australian colleague, Steve Jenkin, suggested to me his view of the rate of progress of the software profession. It’s average experience level, he said, has tended to remain constant over time. … [W]hat he meant was: with the explosion of newcomers arriving in this fast-growing profession, the increasing experience level of the growing-olders is more than overcome by the low experience level of the hordes of newbies. As I thought a bit about what Steve said, I came to this thought that I would like to introduce as a corollary:
The wisdom of the software field is not increasing.
If our experience level is not growing, then neither is our wisdom level. In fact, in our mad rush toward the new, we tend to discard much of the old. (For example, software’s newest and most popular methodologies, like Extreme and Agile, tend to make a point of rejecting the accumulated wisdom of the older methodologies.)
This insight particularly spoke to me.
It may be the local environment in which I work, or maybe the (professional) [echo?] chamber I choose to put myself in. Maybe it’s a pattern in the history that repeats every four-to-five years2, or maybe it is a fundamental shift in the industry.
In any event, the “DVCS solves all developer problems” and “Cloud solves all infrastructure problems” and “NoSQL solves all scaling problems” and “Rails is the only way to develop a website”-cacophony I often find myself in the middle of… may just be an indication that Glass’ corollary is, indeed, right.
Fred Brooks wrote almost 25 years ago that despite claims to the contrary, no silver bullet exists to reduce complexity of the software development process. And yet it’s become almost fashionable in the space to proclaim as loudly (and proudly) as one can: “Here’s a statement that implies I don’t know the history of the industry in which I practice my craft.”
If true, that’s certainly another point in support of Glass’ corollary.
I’m apparently not the only one who’s noticed the industry may be waking up to what Glass posits was true all along.
What do you think?
_______________
1 Thanks again for the reco, Ali!
2 What I tend to refer to as “an Internet generation”
agile, commentary, organizational interactions, process, strategy, teamwork
Preed on Build/Release Engineering | 4 Comments »
V1042
Thursday, December 15th, 2011
A friend sent me this yesterday:
Passengers on a plane are waiting for the flight to leave.
The aircraft entrance opens and two men walk up the aisle, dressed in pilot uniforms. Both are wearing dark glasses. One is using a seeing-eye dog, and the other is tapping his way up the aisle with a cane.
Nervous laughter spreads through the cabin, but the men enter the cockpit, the door closes, and the engines start.
The passengers begin glancing nervously, searching for some sign that this is just a little practical joke. None is forthcoming. The plane taxies out to the runway and begins its takeoff roll.
It moves faster and faster down the runway, and passengers near the windows realize they’re headed straight for the water at the edge of the airport.
As it begins to look as though the plane will never take off and instead plow into the water at full speed, screams of panic fill the cabin.
But at that moment, the plane lifts smoothly into the air.
Up in the cockpit, the co-pilot turns to the pilot and says, “You know, Bob, one of these days, they’re going to scream too late, and we’re all gonna die.”
This story resonated with me.
It’s probably because I’ve often made the case that successful, sustainable release engineering practices share many characteristics with (the operational nature) of aviation.
But there’s something else… something reminiscent of the many war stories we all swap about getting software shipped.
Certainly, the anecdote is meant to be absurd, and the humor lies within that absurdity. But the story also illustrates how patently obvious some problems can become when you examine them from a different perspective1.
We see how we can all be in situations where it’s easier to share nervous glances, instead of speaking up and averting panic.
And the story makes very plain how much energy we spend on angst and consternation, as we all barrel down the runway, unsure of the outcome.
While discussing these issues with a release engineer colleague, I coined the term “chicken-ship” to describe this pattern: a release involving this chicken-esque game between at least a couple2 of the release’s stakeholders, combined with the perceived threat of harm3.
As the available runway passes beneath the release, fewer and fewer have confidence it will make it off the ground; and only when that doubt turns into hysterical screaming, do we take note and do what needs to be done to avert disaster.
No one would fly if every takeoff was conducted like this, but many routinely ship release after release utilizing this “methodology.”
There’s a better way. And were we the passengers in the story, we’d already intuitively know that.
In release engineering, it may be more difficult and more subtle to see.
But it’s no less true.
_______________
1 Outside the plane!
2 Though often more
3 Which, to be fair, is often founded
aviation, organizational interaction, people, process, release engineering
Preed on Build/Release Engineering | No Comments »
V927
« Older Entries