DaedTech

Stories about Software

By

Encouraging Creative Conflict: Form, Storm, Top Gun

If you have any designs on management, it’ll help your cause to learn some of the more iconic bits of that problem domain’s lore.  Software people would be more impressive at cocktail hour by being able to speak intelligently about object oriented vs structured vs functional programming or about relational vs document databases.  Management people would be more impressive at their own cocktail hours being able to bandy about Drucker, lean principles, and Maslow’s Hierarchy of Needs.  And if you hang out at enough of these cocktail hours, you will be unable to avoid Tuckman’s stages of group development.

The short version of these stages is the catchy rhyme, “form, storm, norm, perform.”  The groups starts off being polite and feeling one another out, but they’re more or less too deferential to make serious progress.  After a bit, egos and tempers flare, people jockey for influence and rivalries emerge — the group ‘storms.’  Only once the team has duked it out and subsequently hugged it out can they move on to ‘norming,’ wherein they gruffly put up with one another’s peccadilloes in pursuit of a common goal.  And, finally, in the end, they all live happily ever after, humming along as a well-oiled machine.

Of course, this not only applies to feel-good stories of organizational politics, but also to about 90% of action movies in the history of the planet.  Whether it’s erstwhile enemies Maverick and Iceman agreeing to wingman each other at the end of Top Gun or the romance plot between Han, Leia and Luke eventually sorting itself out, we all get warm fuzzies when the former stormers become performers.  (Sorry, I couldn’t resist.)  Everyone likes a good tale of “form, storm, norm, perform.”

TopGunStorm

We like it so much, in fact, that I commonly hear variants of the idea that teams should be encouraged to ‘storm.’  It’s something like, “we want a team full of people that engage in fierce, angry debate to surface the best ideas, then, when 5:00 rolls around, they let it all go and happily go out to dinner.”  I’ve heard this described as “harnessing creative conflict,” or some such, and it echoes the management (Hollywood) narrative that through challenging one another and letting emotions run high, a catharsis of sorts occurs and all participants come out more creative and more closely bonded for their ordeal.  It’s an appealing notion, and it’s also the epitome of the “extrovert ideal.”

The extrovert ideal was a term coined (I think) in Susan Cain’s, “Quiet: The Power of Introverts in a World that Can’t Stop Talking.”  It refers to the notion that society has deemed extroversion the ‘correct’ choice between introversion and extroversion.  “Storm to perform” is very much an extrovert thing.  But I’ll return to that later.

Read More

By

Getting That New Tool Past The Gate Keeper

Editorial Note: this post was originally written for the SmartBear blog.  You can read the original here, at their site.  Check out the rest of the content while you’re there.

Let me tell you a tale, and stop me if it sounds familiar.  Well, I suppose the medium of blogging will prevent you from actually stopping me, but you get the idea.

You’re part of a software development group, and you’re surrounded by techies like yourself – people that get excited about new ideas, approaches, tools, frameworks, and languages.  But then there’s the guy on your team with the seniority.  Let’s call him Crusty.

Crusty is not your boss. He’s probably the team’s architect or even just a senior developer who is somehow, implicitly, more senior than the other developers.  Most significantly, he’s who management looks to for advice about whether to adopt things – the very things about which you and your teammates tend to get excited.

His answer is usually “no.”

Lifer

Management loves a guy like Crusty because he’s reassuring to them.  If you’re a dev team manager, the developers are constantly clamoring for new things, and you begin to wonder, “Is all of this really necessary?”  A good manager trusts her people to make recommendations, so she’ll tend to go along with it and hope that the spending is not wasteful.  But if there is a go-to guy on her team saying, “nah, we don’t need that,” she’s going to be grateful.  She has someone to reign in the spending, and she’s provided with the (potentially false) sense of security that, when something is actually needed, this guy will speak up.

This leaves you facing a conundrum if you’re part of such a group and want to propose a tool for adoption.  I talked previously about how to sell management on a tool, but Crusty effectively acts as a gatekeeper between you and making your case to management.  If you approach your manager directly, she might say something like, “Run it by Crusty first and get his buy-in.”

So, how do you get past this gatekeeper?  You need to understand his motivation and act accordingly.

Read More

By

Relax, Everyone’s Code Rots

Editorial note: I originally wrote this post for the NDepend blog.  Go on over and check out the original.  If you’re interested in topics like software department strategy, static analysis, and code metrics, it’ll be up your alley.  

I earn my living, or part of it, anyway, doing something very awkward.  I get called in to assess and analyze codebases for health and maintainability.  As you can no doubt imagine, this tends not to make me particularly popular with the folks who have constructed and who maintain this code.  “Who is this guy, and what does he know, anyway?” is a question that they ask, particularly when confronted with the parts of the assessment that paint the code in a less than flattering light.  And, frankly, they’re right to ask it.

scan0002

But in reality, it’s not so much about who I am and what I know as it is about properties of code bases.  Are code elements, like types and methods, larger and more complex than those of the average code base?  Is there a high degree of coupling and a low degree of cohesion?  Are the portions of the code with the highest fan-in exercised by automated tests or are they extremely risky to change?  Are there volatile parts of the code base that are touched with every commit?  And, for all of these considerations and more, are they trending better or worse?

It’s this last question that is, perhaps, most important.  And it helps me answer the question, “who are you and what do you know?”  I’m a guy who has run these types of analyses on a lot of codebases and I can see how yours stacks up and where it’s going.  And where it’s going isn’t awesome — it’s rotting.

But I’ll come back to that point later.

Read More

By

Agile for Introverts: Re-Imagined Programmer Collaboration

As I mentioned in a recent post, I’ve been listening to Susan Cain’s, “Quiet: The Power of Introverts in a World that Can’t Stop Talking.” I also mentioned that I’d be saying more on the topic, and here comes some more.  Today it’s going to be the idea of Agile for introverts.

In recent weeks, I’ve spent some time running a bootcamp of sorts that covered, among other things, XP and Scrum principles. Personally, I find that I light up when talking about clean coding practices and that I’m a bit more tepid when it comes to explaining process particulars. Reflecting one evening, it struck me that a lot of the practices involved in Scrum ceremonies and some of the XP practices aim to draw people “out of their shells.” In other words, a lot of agile is the Extrovert Ideal brought to programming.

This made me wonder what some Scrum ceremonies and/or XP practices might look like if they were introvert-friendly. That is, how could one accomplish the goals of these activities in ways that didn’t assume “let’s all get together and collaborate always!” was the right way to think.

What is introvert-friendly?

Before I can offer thoughts on how to make something introvert-friendly, I want to define what I mean by that. I feel it’s important to do so because the definition most people would assign by default is “things that don’t require interaction with others,” and that’s not right.

I’m going to go out in a limb here a bit and assume that I’m a good representative of the introvert population as described by Cain. I don’t feel that this is too much of a reach, since I got a 20 out of 20 on the informal “are you an introvert” quiz. So, I’ll explain my own psyche and trust that you find it reasonably representative of how you feel if you are also an introvert.

I don’t seek to minimize social interaction, per se, but I do shy away from unpredictable situations with a large amount of stimulus.  I also have an intense preference for a sort of social order that is predicated upon minimized conflict and a world in which information and opinions aren’t generally shared unless solicited.  You can actually read back through my blog posts and see a lot of this described before I’d ever heard of Susan Cain’s book.

There are probably more, but these certainly capture some of the themes at play here.  And from this basis, I propose the following concepts as introvert-friendly.

  • Differences of opinion are resolved by folks having time to process different viewpoints and build a case rather than by extemporaneous argument/debate.
  • Meetings and gatherings are limited in size.
  • In professional situations, it’s better to remain silent unless you have something high value to say, especially in larger groups.
  • Interpersonal interaction is primarily for camaraderie and logistical resolution (e.g. knowledge transfer or merging code), rather than important work.
  • The most productive work happens in a state of flow when you can tune the world out and concentrate.
  • It’s worth letting a group make a sub-optimal choice to preserve social harmony.
  • It’s good to be able to opt out of groups that frequently make sub-optimal choices.

Notice that none of this is, “I want to be home, alone, always, with no interaction.”  That’s not introversion — that’s being a recluse.  Rather, this is “I prefer orderly interactions, a cap on external stimulus, and time and space to form my ideas.”

Read More

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