DaedTech

Stories about Software

By

Developer Hegemony: The Crazy Idea that Software Developers Should Run Software Development

Well, today we officially launch the book, Developer Hegemony.  I’d like to thank everyone who followed along, offered feedback, bought books, and generally supported the efforts.  I’ve enjoyed the ride and I hope you all love the book.  Also, congratulations to the winners of the Thunderclap raffle: Justin Neff, Jim Wang, and Gintautas Miselis!  I will be sending free copies their way.  Thanks to them and to everyone that participated!

In the final days of writing Developer Hegemony and throughout launch preparation, I wrestled with an elevator pitch.  As regular readers know, you wouldn’t find “brevity” listed on my resume, even if making resumes was something I did.  And so I struggled.  But I think I have it now.

“Why aren’t software developers in charge of the software development industry?  Developer Hegemony explains why not, and it explains how we fix that problem.”

Today, I’ll explain the book by expanding on this elevator pitch a bit.

Who’s In Charge Here, Anyway?

So, if software developers don’t run the industry, who does?  To answer that question, understand the context in which most developers write software.  It happens in the corporate world, which consists of companies shaped like pyramids.

 

Reminiscent of military organizations, a tree-like chain of command serves as the scaffolding for most companies.  The CEO gives orders to a handful of C-suite members.  These people, in turn, give orders to a larger number of vice presidents, who then give orders to a whole bunch of directors.  The directors then give orders to hordes of managers, who pass those orders down to legions of grunts.  Finally, with the grunts, you arrive at the leaves of the tree and the bottom of the pyramid.

And those leafy grunts write the world’s software, carrying pyramids of management upon their backs.  So who is more important than software developers in the business of software development?  Literally gigantic pyramids of management.  Oh, and you can also toss in some people who technically exist in the same level of the reporting organization but have titles like “analyst” or “project manager.”

So the question shifts from “who is more important than software developers in the business of software development?” to “who isn’t?”

Read More

By

The Efficiencer’s Guide: Getting Started

You thought Developer Hegemony Week stopped on Friday?  Nah.  Today I give you post 6.  It contains somewhat lighter fare, since it’s the weekend, but the show must go on.  We’re doing really well on the Thunderclap campaign — 83% as of this writing.  But that means I still need 17 more people to do the raffle.  So, please help me out and spend a few seconds signing up!

In the book, I coined this term, Efficiencer.  I also talked about it on the blog this week.  Today, I’d like to offer what I’ll call the efficiencer’s guide (or, at least, the start of it).  I’ve called out a number of idealized behaviors and philosophies, but haven’t given a lot of practical field advice.

For the purposes of the efficiencer’s guide, I’ll assume you work as a salaried software developer in some organization.  This probably describes most of my audience, and it makes for a natural starting point in this journey.  If you’re already a free agent or you don’t write software, don’t worry.  You can still get some info here.  I’m going to include reading materials and links, so I have something for everyone.

Defining Efficiencer

First things first.  I won’t ask you to go do a bunch of homework.  Instead, I’ll define this term again, off the cuff.  I’ve described it in the book, but I invite you all to participate alongside me in kind of an evolutionary definition of the term.

I think of software developers (or engineers or programmers or whatever) as people who collect a salary to write code.  I feel fairly confident that this definition has blown exactly 0 of your minds.  But consider it maybe a bit more literally.  You collect a salary to code… and, that’s it.

Therefore, you don’t worry about business considerations like sales or marketing.  You generally don’t participate in discussions about why you write the code that you do.  Nope, you just show up, get a spec or something, fire up your IDE, and get to work.

The efficiencer, on the other hand, does ask why.  In fact, the efficiencer doesn’t do any work without understanding and approving of the why.  You see, she doesn’t count herself a coder but an automation professional.  She specializes in making you more efficient.  That might mean writing some code, or it might just mean sending you a link to a COTS product that already does what you want.  She doesn’t accept specs or story cards or requirements or anything like that.  She listens to your business goals around cutting cost or increasing revenue, and she decides how that will happen.

Read More

By

A Closer Look at the Efficiencer Firm

For Day 3 of Developer Hegemony Week, I’m going to up the stakes on the Thunderclap.IT campaign.  If you sign up, you could win a free paperback copy of the book.  I’m going to raffle off three books at random for everyone that signs up, but only if we meet the goal of 100 participants.  We’re more than a third of the way there, but still have a long way to go.

For Monday morning’s post, I introduced the efficiencer in detail.  But I took an admittedly philosophical tack in that post, offering more rhetoric than specifics.  Today, I’d like go get specific instead.  I want to talk about more pragmatically about the efficiencer firm.

In order to do that, I’m going to start by talking about inefficiency.  After all, as efficiencers, we ought to have a keen eye for such things.

My Stint Making Hearing Aid Fitting Software

Years ago, I went to work for a company that manufactured hearing aids.  This included several brands under the umbrella of the parent corporation, and all of them had international distribution networks.  So, at the end of the day, the company does everything needed for the manufacture and global distribution of hearing aids.

Operationally, this includes something you might not consider at first blush.  Hearing aids need something called fitting software.  The people responsible for prescribing hearing aids to the population, audiologists, use this software to program the devices.  This includes configuring different gains at different frequencies and setting up so-called “programs” that wearers can use in different environments.  For instance, you might have a “restaurant” program with a much different array of settings than a “home watching TV” program.

Since you didn’t come here to learn the particulars of the hearing aid business, I won’t keep going with further detail.  But I could.  A lot.  As I would learn during my tenure there, developer in this space face a steep learning curve.  The complex nature of sound and gains mixes with the bureaucratic world of medical devices and regulations for a rich tapestry of arcane complexity.  Months passed before I got my bearings there.

Read More

By

Why is Staff Aug a Dirty Term?

This is day 2 of Developer Hegemony Week, and the book goes live in just over a week.  I’m about a third of the way there on my Thunderclap Campaign, but I need your help!  Even if you’ve already signed up, you can sign up from both Facebook and Twitter.  Thanks to everyone for your support!

“Don’t worry.  We’re not a staff aug firm or anything like that.”

Years before this would matter to me, I remember some recruiter saying this to me on the phone.  I didn’t know what “staff aug” meant, so I remember looking it up afterward.  I won’t force you to do that, though.

“Staff aug” abbreviates the longer form term staff augmentation.  Wiki attempts to utterly crush readers’ souls by calling it an “allocation of dedicated technical resources, usually offshore, hired as overseas development extensions of in-house application development teams on fixed or flexible terms and conditions”.  Jargon aside, it refers to hiring a relatively disposable contractor in lieu of a more permanent employee.

Over the course of the decade following that recruiter call that I never pursued, I learned a great deal more about this subject.  In the world of custom app dev (er, excuse me, “consulting”), you have two types of firms.  First, you have staff aug firms, and then you have firms that scream from the rooftops that they would never stoop to the gutter of staff aug.  Apparently, there’s nothing in between.

Don’t believe me?  Check out this post from an app dev shop.  In 2015, they derisively called the staff augmentation firm a “body shop” and declared it dead.  “The recruiting and staff augmentation model is losing popularity in the industry – they are going the way of the dinosaur. Dunzo.”  Two years later, it turns out that reports of its death may have been greatly exaggerated.

Still, why all of the hostility and scorn?  Why does the industry split this way?

Staff Aug from the Client’s Perspective

Have you ever worked alongside some guy who seemed unremarkable until you learned that he didn’t really work for your company?  He could have fooled you, though.  He came in every day, attended all of the meetings, and exhibited consummately middle-of-the-pack amounts of skill.  But in spite of looking, walking, and quacking just like a fellow employee, he turned out to be contractor.

To make matters even more mystifying (and aggravating), you subsequently learned that the company pays a lot more for him than for you.  At some point, you probably (half) joked to a coworker that you should quit and return as a contractor to make twice the money.  Inside, you may have seethed at the injustice of it all.  Why should he make so much more when you do better work?

You may not like the answer.

Read More

By

Your Job Title of Tomorrow: Efficiencer

Since I boasted about this on Twitter, I have to follow through.  I’m going to do “Developer Hegemony Week” on my blog, leading up to the book launch on May 2nd.  (I suppose this makes Developer Hegemony Week a misnomer of sorts, since we’re talking about 9 days of posts.)  I can think of no better way to kick this off than to talk about “the efficiencer.”  For those of you not familiar, Developer Hegemony is the book I’ve written and am launching on Amazon soon.  In it, I coin the term efficiencer.

First, though, some housekeeping.  I need a bit of help from you, if you don’t mind helping.  I’ve started a Thunderclap.IT campaign to help with the book launch.  Thunderclap operates according to a simple, kickstarter-like premise.  If I can get 100 people to sign up to tweet or share the book, then all of those shares go out on launch day.  If I fall short, all becomes for naught as none of the shares go out.

Okay.  Back to explaining why I’ve coined a word and why you should care.  For the rest of this post, I took an excerpt from the book and modified it a bit.  I’m now offering it here as a canonical definition for the blog.  And in it, I explain why we need to go from shrugging when presented with wire-frames and specs to saying, “I understand the business problem you’re trying to solve — let’s talk revenue goals, and you can leave the specs to me.”

I’m Glad You Called — I’d Love Some Unsolicited Financial Advice!

My cell phone rang about mid-morning, and it presented me with the ultimate conundrum for an introverted entrepreneur/consultant: an unrecognized phone number from my area code. On the one hand, it could have been a prospective client or generally someone whose call it would make sense to take. On the other hand, I didn’t recognize the number, which usually signals some kind of solicitor or scam. I decided to answer because I thought I’d seen the number before. Either someone really wanted to talk to me or I’d have to tell them to put me on their do not call list to get them to leave me alone.

I instantly regretted my decision to answer. A criminally cheerful voice said, “Is this Erik Dietrich?!” You’d think he’d just gotten his personal hero on the phone.

I sighed, recognizing the forced, chipper tone of someone who lives by the motto “Always be closing.” “Yes,” I said guardedly.

He told me that one of my friends had referred him to me, saying that I was someone that would potentially be interested in his services. He was a financial planner, you see, who specialized in helping young couples achieve their dreams — couples like my wife and me, as my luck would have it. “When is a good time for us to get coffee?” he asked after blithely glossing over this dubious introduction. (My friend never had, in fact, briefed me that this guy would call.)

Do you see what he did there? It’s a classic sales technique wherein you don’t give the mark prospect the option of saying no. This bit of slicked-back-hair salesmanship is a close cousin of the “loaded question” logical fallacy. “Have you stopped cheating on your taxes?” “Yes, I mean, no, I mean—hey!!” No matter how you answer the question, you implicitly concede a point made by the asker. In the case of our used-car salesman cum financial planner, answering his question politely leaves me no choice but to agree to meet him.

I sighed again. Briefly, I thought about setting a meeting at some Starbucks in the area and then never thinking about him again. But that seemed disproportionately cruel, so I broke script and told him that I wasn’t interested. After taking one more stab at me with a “When is a good time to follow up to see if you’ve changed your mind?” he’d exhausted his slimy script and hung up on me with no fanfare. Class act from start to finish. I should call him back, say I’ve reconsidered, and set up that phony meeting after all.

Read More