Saturday, July 25, 2009

Are You Following Your Team's Information Stream?

If not, you suck. Really, you do. You sucky suck suck. You're a bad, bad manager. Sorry to be the bearer of bad news.

It's sad really, because you've got a great team, that's filling the atmosphere with fantastic information, and you're not taking the time to soak it in. Chances are, most people on your team are on Twitter. Also chances are there's a solid percentage of your team that's got a blog somewhere. This is likely the most valuable information that you can possibly consume. But you don't, so you suck.

I don't think you're alone though... I think that most manager's only hook into their team's digital personality is IM status, and that's just sad (though, I've seen some really good IM statuses). But, did you know that your most introverted engineer has 3,000 status updates on Twitter? Did you know that your Project Manager has a blog about Haskell coding? Did you know that your QA engineer is a semi-pro kickboxer?

Your team is giving you feedback, intentionally, indirectly. I think it's time that you need to accept the fact that this stream is like a uber-informative facial expression. Your team is letting you know how their day went, what they think you're doing wrong (or right), and what they think the company is doing wrong (or right). Maybe it's a bit passive aggressive, but who cares if they're telling you something that you should be hearing? Is there really a better channel for them?

As a manager, you've always got time to learn more about the craft, practices, people... And your team member's streams are full of great information about it. Believe it or not, they're thinking about work just as much as you.

Your team is likely doing very, very interesting stuff outside of work. Having an idea of what that is, and showing that you're interested in it goes a long way toward strengthening your relationship. Think about walking in on a Monday morning and saying "Saw you went hand gliding, how awesome was that?" instead of sounding like a fucking tool at the water cooler saying "How was your weekend?" and getting the same old "Good, yours?", followed by the awkward silence then "ok, have a good one". Get involved, and you'll have something interesting to talk about.

Your team would appreciate it. As a manager, your team looks up to you, and them knowing that you're paying attention and interested in what their doing, makes them feel appreciated. The more they do to feel appreciated through this information stream, the better off everyone is. You're all growing.

So, here's the good news; I can retract the sucky bad manager claim if you start following your team's information stream today. Do it, or you still suck.

Tuesday, July 21, 2009

Response From programmer.grrl

You should read Amy G's response to my last post:

Companies are Addicted to Profit Like Smokers are Addicted to Nicotine?

It's good.

Monday, July 20, 2009

Define success...

Amy G wrote a response to my post about why I think that large development projects don't work.

My concern is, so what? Just because a project fell short of what was envisioned, blew the timeline, or damaged the team, does that mean it wasn't successful?

My answer to that, is, no, it doesn't mean that at all. But only along the same lines as: If you smoke a pack of cigarettes today, does that mean it's going to kill you? No, it probably won't. You'll likely live, but, you'll also likely smoke another pack tomorrow, and the next day, and then the answer changes.

Now, as if it wasn't bad enough that I equated large development projects to smoking cigarettes, I'm going to quote DeMarco and Lister, who I think she feels are icons of an unattainable utopian relationship between management/organizations and the folks in the trenches (but I don't want to put words in her mouth, you should ask her yourself).
Historians long ago formed an abstraction about different theories of value: The Spanish Theory, for one, held that only a fixed amount of value existed on earth, and therefore the path to the accumulation of wealth was to learn to extract it more efficiently from the soil or from people's backs. Then there was the English Theory that held that value could be created through ingenuity and technology. So the English had an Industrial Revolution, while the Spanish spun their wheels trying to exploit the land and the Indians in the New World. They moved huge quantities of gold across the ocean, and all they got for their effort was enormous inflation (too much gold money chasing too few usable goods).

Value in software comes from having a great understanding of the domain and the gap that the software is trying to fill, and coming up with innovative and smart solutions to fill that gap. Innovations and smart solutions don't come from people who are constantly working overtime, or constantly feeling defeated because of another missed timeline or unrealized feature.

But value in software is hard to gauge, especially when something of lower value can sell really well in the immediate future. Some businesses are great at selling products that are of lower value. But without value, any success will always be fleeting.

Thursday, July 09, 2009

Merge Tracking with Subversion 1.5

A year or so ago, a few of us at the office piled into a conference room to watch a webinar about all the new features Subversion 1.5. One of those features that sounded cool, but was conceptually opaque to me, was merge tracking. But, recently, I've had to get my merge on, and wanted to see what it was all about, and it was one of things I'd wished I'd taken the time to do sooner.

The bottom line, is that now Subversion actually has a workflow for keeping your branch in sync with the trunk, so you've got less surprises when it's time to put your work back into the trunk. You no longer need re-branch in order to get the latest trunk changes for your branch. You can just tell SVN to get any changes from the trunk since you either made the branch, or last took changes from the trunk.

The workflow is pretty simple. You make your branch, you work on it for a while, you say, "I'm going to be merging into the trunk eventually, I'd better make sure that goes smoothly." so you update your branch with the latest from the trunk:

$ pwd

$ svn merge
--- Merging r345 through r356 into '.':
U button.c
U integer.c

So, since we didn't specify revisions, you can see that Subversion is fully aware of what revision of the trunk your branch came from. Also, Subversion is going to store all the revisions that you've just merged into your branch. You can do this to see:

$ cd my-calc-branch

$ svn mergeinfo


You can also see which changes from the trunk that you're missing:

$ svn mergeinfo --show-revs eligible

So, you can repeat this process often, which I'd recommend. The more frequently you integrate the changes from the trunk, the more unicorns and rainbows come merge time.

Another benefit of Subversion keeping the merge information around, is that you can undo merges:

$ svn merge -c -303
--- Reverse-merging r303 into 'integer.c':
U integer.c

This is just for keeping your branch in sync with the trunk. How bout when you want to move your changes into trunk when your work is complete? Well, all this merge history will be taken into account when you decide to merge back into the trunk. Subversion will understand what has already been pulled in from the trunk (or any branch for that matter), and only merge the revisions that aren't in the merge history.

This is a very handy feature, it's a shame I waited this long to dive in.

(Note: all these examples I shamelessly copied from the svn book)

Monday, July 06, 2009

Large-Scale Project Doesn't Equal Large-Scale Development

Jeff and I were have a discussion on Twitter last month around 37signals' "Getting Real" philosophy. Specifically, Ben's post initiated the conversation, and his post was based on this one from Signal vs. Noise. What we were discussing was how the "Getting Real" philosophy applies (or doesn't) to other organizations that have justifiably complicated problems to solve, or have to work with legacy systems, or have to deliver up front estimates on work to be completed, or have a QA team.

My point was that ultimately, "Getting Real" is delivered in an extremely prescriptive manner by the folks at 37signals. Their philosophy is contrived in a vacuum that they've built with well-packaged and well-priced software, which I'm sure they worked very hard to create, but, unfortunately, that model isn't in the stars for everyone.

Eventually, our Twitter conversation ended on me promising Jeff a blog post on why I thought "Getting Real" does apply to large scale development. The reason is that we need to stop thinking that large scale development is necessary. Just because the project may be relatively large, the development doesn't need to be equivalently large. The concept of parallelizing development with a large team to deliver a large amount of code for a large project all at once, is in my opinion, well... broke.

The only successful large projects I've been a part of have consisted of small development releases. Small teams focused on single or few chunks of functionality delivered in short iterations, with the team deferring as many of the decisions as late as possible. And this is where I think the "Getting Real" philosophy fits in really well, and works well even if it doesn't fit into the other aspects of the organization.

Take "large scale development" off the table, eliminate it from your vocabulary. Keep it short and sweet, even if the rest of your organization can't be that way.

With the "large scale development" mind set, the odds are stacked against you. You'll find that you've fallen short on what you've envisioned, fallen short on your timeline, and probably done some irreparable damage to your talented team.