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
Tuesday, November 1st, 2011
From a great Apple story:
Once again, my sanity was saved by the kindness of a stranger. At 2:00 one morning, a visitor appeared in my office: the engineer responsible for making the PowerPC system disk master. He explained things this way: “Apple is a hardware company. There are factories far away building Apple computers. One of the final steps of their assembly line is to copy all of the system software from the ‘Golden Master’ hard disk onto each computer’s hard disk. I create the Golden Master and FedEx it to the manufacturing plant. In a very real and pragmatic sense, I decide what software does and does not ship.” He told me that if I gave him our software the day before the production run began, it could appear on the Golden Master disk.
I’d bet money the mysterious engineer that saved the day was a release engineer.
This is a minor historical footnote in Apple’s history, but it’s a fascinating look at the policies, environment, camaraderie, and engineering spirit of the company in its previous life; definitely worth a few minutes.
(Via @othiym23, originally via @raum.)
***
I must admit: one of the things I do miss the most is creating the golden masters. I’m young enough to have not had to worry about it for years, but old enough to have had to do it for a few products that I shipped.
I think we might have a different mentality about software release process and quality if we still went through that ritual today, and it actually involved cardboard boxes, pieces of plastic to hold the bits, and shipping trucks.
folklore, release engineering, Releases, teamwork
Releases, blahblahblah | 2 Comments »
V903