DaedTech

Stories about Software

By

If You Promote Bad People, You Promote Bad Culture

Most of my cynicism toward the corporate world is safely directed into my new book these days, so there’s not a ton of spillage onto the blog.  But I’m going to make an exception today and talk about corporate culture.  To understand some of the terms I’m about to use, you can buy the book, if you’re so inclined, but you can also see an original definition here in this post.

I originally intended for my notes on this topic to make it into the book, but one of the main uplifting themes of the book is that I see programmers creating a professional working arrangement in which the corporate idealist doesn’t exist.  And since deliberate company culture, which I’ll refer to as “corporate religion,” is largely theater for idealists, spending a lot of time talking about it in the book would be somewhat superfluous (I do mention it, but not extensively).  But that’s not to say that corporate culture and religion don’t matter.  And, all these half-formed notes I have ought to go somewhere.  So, here they are.

Corporate culture is more or less defined by three things: what it takes to advance within the company, and what it takes to stay in the same role within the company, and what it takes to be walked out by the company.  Paintball outings and “bring your pet to work” don’t define or even describe company culture.  Perhaps more surprisingly, neither do things like company “mission,” “values,” and “principles.”  These things, which constitute corporate religion, are mainly orthogonal to culture.  Corporate religion consists of ceremonies, outreach activities, and the official canon (mission statements and expressions of “official values”).  But none of these things are culture, any more than the Ten Commandments, New Testament, and church bake sales are the ‘culture’ of a rural evangelical town in the USA.

If you look up the definition of the word culture, you’ll have to scroll all the way down to definition number 5 to get to an actual definition of corporate culture.

The behaviors and beliefs characteristic of a particular social, ethnic,or age group: the youth culture; the drug culture.

For our purposes here, we’re talking about the social group “people who have opted to work at this company.”  This means that we’re talking about behaviors and beliefs of employees when we talk about culture, and this is why culture and religion are disparate and sometimes orthogonal entities.  Corporate employees are forced to attend religious ceremonies and memorize the canon, but what they actually believe and do outside of structured activities is another matter altogether.  Plenty of people who show up to church every Sunday go forth immediately afterward and pound beer and gamble on football.

ArmchairQuarterback Read More

By

Your Old Language Version is Costing You Money

Editorial note: this post was originally written for the Infragistics blog, and you can read the original here.  Check it out on their site and read the rest of the stuff there, as well.

Imagine that you walk into a company, and take a stroll through the software department.  All around you, as far as the eye can see, developers toil away, staring into 17 inch CRT monitors.  What would you think of that?  Would you have to restrain yourself from jogging over to the HR department, enthusiastically, to apply for a job?  Or would you thank your lucky stars that you worked somewhere else?  I’m betting the latter.

One of the most penny wise, pound foolish strategies that a company can pursue is hiring a team of software developers, whose mean salary may be in the six figure range, and saving a few bucks by forcing them to do their work on obsolete hardware.  It’s foolish because the productivity lost by these expensive workers far outpaces the cost of updated computers and monitors.  Of course, this is pretty commonly known these days.  You don’t see or hear about nearly as many companies skimping too much on a second monitor or new machines for software developers.

PackagedComputer

And yet, it’s still fairly common to make developers use older versions of programming languages and frameworks.  Now, this isn’t a completely direct parallel.  Companies historically have let hardware age on developers’ desks mainly as a cost savings strategy, whereas continuing to work on a “stable” version of a language or framework is generally a risk minimization strategy; why port your code base to v-next when that could introduce bugs and it doesn’t matter to the users?  That’s a fair argument, but the thing is, when you pull back a level of abstraction, risk minimizing is, at its core, still about cost savings.  In a company, everything comes down to top line revenue minus bottom line cost. Read More

By

Scrum Master + Team Lead = Team Master?

Last week, I gave the Scrum Guide a fresh read.  I did this for the simple purpose of making sure I was remembering the rules of the game correctly, and not just having conversations based on echoes of memories.  It turns out that my understanding and recollection had not drifted very far, which was good news.  But it also turns out that I still think of “Scrum Master” as somewhat silly.  I re-read the manifesto, had the same impression, and was somewhat gratified to learn that I have the same taste as myself.

What is a Scrum Master, Anyway?

There’s a lot to like in the Scrum guide, but Scrum Master, in my opinion, just isn’t in that bucket.  At best, it’s a built in sales role for Scrum, and one that should become unnecessary as time passes.  The guide itself is pretty unambiguous about this: “the Scrum Master is responsible for ensuring Scrum is understood and enacted.”  Presumably, once Scrum is “understood and enacted,” the role need not exist.  At its worst, “Scrum Master” is an escape hatch for non-technical project managers in an agile world that largely proclaims them unnecessary (unless re-cast as BAs, product owners, or line managers).

InterruptionCop

Unfortunately, and in far too many organizations, I think that Scrum Master winds up at its worst.  Scrum falls under the umbrella of agile methodologies, and it says something right there in the agile manifesto (or, at least, the principles behind it) about how to organize teams: “the best architectures, requirements, and designs emerge from self-organizing teams.”  This describes a scenario in which empowered and engaged technical folks figure out how to deliver value to interested stakeholders without relying on traditional command and control structures.

In other words, agile teams (and, by extension, Scrum teams) don’t need managers or masters.  They need a “product owner” to represent the interests of the business and… well, that’s it.  They need someone to explain to them what’s needed out of the software and then it’s up to them to go do it.  It’s refreshingly grass-roots.

Read More

By

Prediction Markets for Software Estimates

The ongoing kerfuffle over the “No Estimates” movement is surreal to me.  So before I get to prediction markets for software estimates, I’ll discuss the surreal a bit. Instead of attempting to describe it, which, I can only imagine, would be meta-surreal, I’ll make use of an allegory of sorts.

No Wedding Estimates

Imagine that wedding planners have long struggled with an important issue.  For years and years, their clients have asked them to help pick a date on which it would not rain so that they could have outdoor weddings.  And, for years and years, their predictions have been spotty at best, resulting in irate clients, wet formal wear, and general heartburn.

In all that time, wedding planners have pored over weather patterns and diligently studied farmers’ almanacs.  And yet, the predictions did not substantially improve.  It got so bad that a group of upstart wedding planners met one year in the mountains and authored a document called “The Contingency Manifesto.”  This resulted in an important advance in wedding planning for outdoor weddings: reserving a backup plan not dependent on the weather.

RainyWedding

And yet, not all was fixed.  People still wanted outdoor weddings, and continued to be disappointed when it rained, contingency notwithstanding.  They still demanded wedding planners help them figure out months and months in advance whether or not it would rain on a particular day.  And, this is understandable after all — weddings are important.

Quite recently, a group of wedding planners emerged under the hashtag #NoOutdoorWeddings.  Their message was simple: “we can’t predict the weather, so have your wedding inside and stop whining.”  The message was, of course, music to the ears of frustrated wedding planners everywhere.  But some planners and most clients balked.  “How can you tell the clients not to have weddings outside?  They’re the ones paying, so it’s our obligation to facilitate their wishes!”

This schism, it seemed, was irreparable.  And surreal.

  • Why is it necessary for wedding planners all to agree?  Can’t the ones that don’t want to deal with weather contingency just not do it and the ones who want to can?
  • Why can’t people figure out that trying to predict a chaotic system like the weather is a fool’s errand?
  • Why would you ask a wedding planner to make a prediction that could easily be influenced by his own interest?
  • Frankly, if one person is dumb enough to ask another to predict the weather on a day 9 months from now, and the other person is dumb enough to do it, can’t we just agree that the two deserve each other and the inevitable lawsuit?

How Estimation Actually Works Today

Read More

By

Make the Complex Simple

For many years, I associated the concept of “making the complex simple” with teaching. And that’s certainly not wrong. We’re in an industry filled with complexity, both essential and accidental. To survive in this industry requires understanding essential complexity and eliminating accidental complexity, and novices struggle with this. As developers become self-sufficient, they figure out complexity reduction enough that they can mentor others in the concept. Once they get to the point of teaching concepts pretty seriously — giving conference talks, creating courses, coaching, etc. — it can definitely be said they’ve become good at “making the complex simple.”

Of course, it could also be said that the term applies to communications with non-technical stakeholders and not just teaching inexperienced developers. Think fast — how would you explain to the CIO who doesn’t have a programming background why you should stop delivering features for a couple of weeks in order to retrofit an IoC container onto your codebase? If you start saying things like “inject your dependencies” and “switch your database driver without recompiling,” you’re keeping the complex complex as the CIO stares blankly at you. Making it simple isn’t easy, is it?

To take complicated concepts and communicate them simply, with minimized loss of pertinent information, is a skill you could (and should) spend a lifetime improving. It requires overcoming the curse of knowledge, understanding your subject matter extensively, knowing your target audience’s world fairly well, being  adept at mapping concepts and creating analogies, communicating clearly and, oh yeah, often doing it all off the cuff. Piece of cake, right?

Hard though it may be, it’s a skill worth developing.

I originally wrote this post for John Sonmez’s site, Simple Programmer.  Click here to read the rest of my argument as to why you should develop this skill.