Thursday, November 1, 2012

Linking Google Drive Docs with Evernote


There is at least one service (CloudHQ) that will keep them in sync for a fee.  What if your requirements are very lightweight, though?

In my case, I just want to be able to link a Google doc to a note.  What I have been doing is:

  1. Open the doc in Google drive.
  2. Click the share button.
  3. Copy the link.
  4. Paste it in Evernote with Cmd-K, Cmd-V.
That's not a difficult workflow, but it isn't as light as it could be.  

As an alternative, try doing a one-time install of the Google Drive app (if you don't see a button to install it at the link, that probably means its already installed on your machine).  Then you can use Evernote's built-in "attach files" button or menu shortcut to put a Google Docs link right in your note.  Just navigate to the right place in your local Google Drive folder and and click 'open'.


Monday, October 29, 2012

A Good Code Editor Is Easy To Find

I've been playing around with Sublime Text, which is a code editor with a very active community.  I thought it was nice, but after years of using Eclipse, no big deal.  However, some people whom I respect (the guys at Bitovi have turned me and several of my Coworkers on to it) insisted that it was the best editor for programming that you can find.

To decide for yourself, I recommend the videos that Jeff Way at Nettuts put together to improve your workflow.  Watch the first one (it's only 2.5 minutes long) to get a feel for whether it's worth watching any of the rest.  If you watch just a couple more, I'll bet you'll be hooked, though.

What do I like about it?  I'll summarize in terms that are the most important to me:

  • Multi-platform (Linux, Windows and OSX - all platforms I use regularly).
  • You can open a folder and use it like a project.  None of the long tedious "import" BS that you have to do in Eclipse.
  • Quick file and symbol searching.  (Seriously, I can type command-P, part of a file name, "@" and part of a symbol to drill to a particular method in a particular Java class.  That's all kinds of awesome!)
I never much liked vi (though I can use it in a half-assed way), and I'm not all that thrilled with using a heavyweight IDE like Eclipse (the flakiness outweighs the benefits of having a continuous build too).

Now I can finally be one of those guys who is comfortable with just a shell and a stand-alone editor to do all of their programming work.  That's a level of nerd-cool that I have heretofore reserved for people like Magnus.

Maybe I should grow a beard.


Friday, October 12, 2012

Specializing Generalist: How Much of Each?

I just had a conversation with one of my teammates.  He's not happy with being seen as "The Javascript Guy", and prefers to be seen as a good all-around software developer.

He does make a very good point.  How much of our time should be as "generalists" and how much specializing in particular languages, libraries and toolkits?  How much time should we spend learning new things, vs time spent using the skills we have already built?

It isn't an idle question.  At the extremes, if you're constantly learning new things, you're always a newbie and not adding a lot of velocity to your project.  If you stick with the skills you have and apply only those skills, you will eventually be left behind by the march of technology, and obsolete as a developer.

My opinion is that the balance lies somewhere around 80/20, or even 90/10.  The majority of your time should be spent putting the skills you already have to good use.  I also think that the 10-20% time is spent in bursts, so the reality is that I'll spend 99% of my time exercising skills I already have, and building just a but of new mental muscle.  Then I'll discover a need for new skills and spend 90% of my time learning *that* new thing, which slowly ramps down as I use it.

What do you think?  How "special" and how "general" should a good developer be?

Friday, October 5, 2012

What is software craftsmanship?

In a conversation with Patrick Welsh today, and his take on it was that a craftsman is someone who:

  • Writes small methods.
  • Uses excellent names.
  • Keeps modules small.
  • Test drives code.
The context of this is that it is possible to do all of these things in Javascript.  Claiming that JS is fundamentally different from Java (or any other modern language) is a poor excuse for not being a craftsman.

I tend to agree with him, and disagree with John Marx's statement that you can be a software craftsman without doing the above things.  I think that John's point was that technique != mindset.  My disagreement is that at the current time, using these techniques is the way to be a craftsman.  As techniques and tools evolve, the definition of craftsmanship will evolve.

What do you think?

Thursday, October 4, 2012

Death by Oversight: How much overhead is too much for an agile project?

I had a great discussion with one of my coworkers today.  He felt that we were adding a lot of noise to our current project due to the number of "fluff" people on our project.  In his opinion, anyone who wasn't spending most of their time on a keyboard (software developer, analysts creating stories, QA) is overhead.

Such people (which list includes me, BTW) have the following negative effects:

  • Communication overhead / Noise - people doing the actual work are often asked by multiple people how something works or why a particular choice was made.
  • Meetings - we can be a source of meetings and other discussions apart from the "noise" above, if only to justify our time on the project.
  • Duplication of effort - this has definitely happened to us.  More than one person steps up to get something done (analysis of a problem, breaking down & estimating a set of stories, etc.) and because we're not all communicating face-to-face, they don't work together on it.
  • Climate of fear - feeling that you have to please a lot of people with different agendas can create a climate of fear, even if most or all of the people involved have good motives.
It was a compelling case, and I don't have any easy answers.  Some worth considering:
  • Make sure all of the "fluff" people are aware of the problems above!  Stating the problem clearly is the most important step in solving it.
  • Reduce the fluff by having some people step out of the project, or by changing their role to something other than a decision-maker.  (For instance, my role could be developer + management bitch for buying hardware & approving access to resources, and I can step out of most of the planning & oversight work.  Hmm... that actually sounds like a lot more fun than what I've been doing.)

Wednesday, August 1, 2012

It's More Fun With Two: Pair programming done right

A couple of months ago, I blogged about some of the mechanics of pair programming.  This post is more about the attitudes around it and supporting practices.

Pair programming is often held up as the one true path to good code, but there are some dissenters.  Many of these people aren't naysayers, but instead believe that while pair programming has it's place, so does writing code in blessed solitude.  Some (at least anecdotally) think that pairing is the root of all evil.

The truth isn't somewhere in between.  Pair programming really is coding nirvana, but only if you do it right.

Keys to Success


I have spent the last three years in a software development organization that has strong values around pair programming (after spending 20 years in 23 other organizations that didn't).  It is pretty consistent - most of the seven teams practice nearly 100% pair programming.  Most are pretty good at it.  Some are awesome at it.  In my experience, the following keys are what allowed them to reach levels of never-before-seen awesomeness:
  • People - you have to eliminate assholes from the organization.  If you have developers who belittle or bully other developers, they will destroy your ability to make this work.
  • Frequency - you have to do it a lot.  By "do it", I mean pairing pretty much all of the time, and swapping pairs daily or almost daily. (Some people advocate swapping even more often, but I don't have direct experience with that practice - yet.) Do this for at least 2 months before allowing any solo work.  You simply can't get good at it unless you have a lot of practice.
  • Urgency - build and maintain a sense of urgency across the team.  All of the developers should be motivated to get stories all-the-way to done as soon as they can, with zero defects.
  • Communication - pairs should be constantly discussing, whiteboarding, and calling over a product owner (or proxy) to clarify details.

Benefits


I'll assume for the moment that your organization doesn't practice pair programming, or does so only on a part-time basis.  Why should you go to the trouble?  What will you get out of it?

First of all, there are some sound psychological reasons.  From a programmer's perspective, it is just plain more fun to work with a pair all day.  You keep each other honest, which means that you never go home at the end of the day feeling like you haven't accomplished much. Productivity really is its own reward.  It's hard to overstate the profound impact of going home at the end of the day - almost every day, with a sense of accomplishment.

It also feeds our social needs.  You spend the day in a relaxed conversation (and occasional heated debate), talking about something you both enjoy and understand.  How often do you spend 6 or more hours talking to your significant other about something you're both into?  Once the team has been together a while, you'll also get a sense of camaraderie, as well as building up a lot of inside jokes.  I haven't worked at many jobs where I felt as close to my coworkers as I have on projects were we constantly pair.  (This is also a good reason to look for a sense of humor when you interview people.)

Finally, there are a number of excellent business reasons.  Here is a logic-chain for you to consider:
  • When developers are committed to pairing and feel the need to work fast, they work harder to understand each other.
  • To help understand each other, developers usually draw pictures on a whiteboard or paper.
  • When people communicate visually as well as verbally, they understand what the other person intends to do much better.
  • When people understand each other's intentions and plans really well, they can point out flaws, solutions to the flaws, and additional opportunities for improvement much more quickly and effectively.
  • When developers are communicating quickly and effectively, you get the benefit of two programmers' experience in a fraction of the time, with almost no software defects.
This means high-quality code done quickly.  There aren't too many customers who would say no to that.


Pitfalls and objections


Of course, no plan ever survives contact with the real world.  There are a lot of things that you have to adapt to.  Here are a few of the problems I have seen and their solutions.

Problem:
How do you get a team to feel a sense of urgency, communicate a lot and pair all of the time?
Solution:
Tell them what you want them to do and why.  Coach them to do it.  It's simple, though not easy.  Hire an agile coach or two if you can't do it yourself.  And remove any jerks from the team.  (Like I said, simple, but not easy.)

Problem:
Noise!  Isn't it really distracting to work in an environment with constant chatter and movement?
Solution:
This one mostly solves itself.  You'll be amazed at what people can adapt to.  If the acoustics in your space really suck, look into some sound absorbing ceiling tiles and baffles.  They can make a pretty big difference.

Problem:
The developers on my team just aren't committed to this.  They're not jerks about it, they just don't believe in it.
Solution:
This is one of the most difficult problems, and probably the most common.  The only answer that I have seen work is to have the committed people significantly outnumber the non-comitted people.  Culture tends to follow the majority.  If you have to, start with a small seed team and outnumber them with some contractors with the right outlook and skills, then slowly (every month or so) add another person to the team.  When it gets large enough, fission the team into two teams and repeat.  This is expensive, but worth it.

Problem:
There really are some things that are best done solo.  How can I tell my team that they have to pair on them when common sense dictates that it's more efficient to split them up?
Solution:
There are probably far fewer thinks that are better done un-paired than you think.  Enforced pairing at the outset helps the team identify more clearly what they are.  Just tell them that - they'll probably get it!  Give them a time-frame if you must, but it should be no less than 2 months.  After that, he more obvious things like fixing simple UI bugs can be done solo… though if you're doing it right, you may find that you don't have any UI bugs, simple or otherwise.  I'm just sayin'...

Problem:
I can't sell this to my business.  They'll never let us do it!
Solution:
How hard have you tried?  Can you enlist some help in selling the idea to them?  Just as important - do you really need their permission, or will your boss (or his/her boss) provide enough air cover to let you get it done?  If not, maybe your business is filled with jerks and you should just find another job.  I have worked in automotive companies before and I feel your pain.


Summing it up


Pair programming really isn't just the best way to get a project done quickly, it's also the most fun.  Most programming shops don't practice pairing because they haven't tried doing it without understanding the keys to success or the challenges they were likely to encounter, then came to the conclusion that "pair programming doesn't work".

Doing it right really is simple: stress communication and urgency, and insist that your developers pair 100% of the time until they get good at it.  It's a winning formula.


Discussion Question
What other problems could derail implementing pair programming in your shop?

Thursday, June 7, 2012

Agile Transformation Defined


I'm currently leading an agile transformation, and it has been an incredible learning experience.

It has also been a frustrating experience that causes me to drink to wretched excess, and sometimes kick my dog.  But that's a whole different blog post.

Some Background

My company went "Agile" 3 years ago, and I was hired as part of that process.  We did it mainly by bringing a large amount of offshore software development back onshore, and hiring people who had the right skills to replace the offshore team.  This may be the easiest way to do it, and explains why we were successful where so many others have failed.

This Spring, one of our remote offices was having some trouble delivering a flagship product, so the suits decided that a leadership change was in order.  They moved a couple of people around to make room, then appointed my boss as the interim leader of the remote office.  Being a savvy businessman and a keen judge of character, he charged me with leading things from the engineering side.  (The fact that I held my breath and threatened to cry if he didn't let me do it may have had something to do with his decision.)

Compared to my previous experience, this has been a much rougher ride.  There are a couple of reasons for this: 
  • First and foremost, the people already on the ground weren't hired with agile development in mind - most of them had to be sold on the concepts before we could get them on board.  This is by no means done yet.
  • Second, the people (I won't call them a team, because they're still not) had never been part of a healthy development group, and had no idea what it felt like.

I'm not maligning the people.  They're smarter than most of the developers I've worked for, but they didn't sign up for this.  Three of them have already taken their services elsewhere.  That's actually an opportunity for us because we now have room to hire people who do want to do this crazy Agile thing.
You can't force a culture on people, it has to grow by itself.  And it won't look like what you expected when your'e done.

OK, so what does "Agile Transformation" mean?

There are probably as many versions of "Agile" as there are people practicing it.  That's why I usually put it in quotes.  The way we do it is:
  • We don't need permission to build in quality - we use the engineering practices of pair programming and test driven development.
  • Everybody that can code does - managers are programmers too.
  • Build a learning culture - anyone can do a short presentation or hands-on exercise to teach others, and many do.
  • We set aside a day every few months for an in-house software conference, usually technology focused.
  • The 60-80 developers (1/3 - 1/2 are contractors) we have at any time, are split into 4-6 teams based on products or platform projects.
There are a lot of little cultural quirks, but that's the core.  Applying the same methods to a team 1/5 the size should be easy, but it's not.  



(Photo by Алексей Харченко, and no, I can't pronounce that either)

Thursday, May 10, 2012

Pair Programming: How To Do It Right


Pair programming is an XP practice of putting two people in front of a computer, and having them program together. If you haven't seen it work before, it sounds wasteful. It is wasteful if you have one person writing code while the other passively watches, but there are some practices that make it a lot more valuable. When done right, I consider "paring" to be vastly superior to solo programming.


The way I have done pair programming goes hand-in-hand with test driven development. Here are the techniques I have used.


Ping-Pong Pairing

This is a beginner technique. It can get you in the groove for a day of pairing, and it's also useful as an introductory technique to pair programming.


Here is how it works:
  1. Developer A: write a failing test
  2. Developer B: make the test pass
  3. Refactor together
  4. Developer B: write a failing test
  5. Developer A: make the test pass
  6. Refactor together
  7. Rinse and repeat
The idea is to make a game out of it. Write the simplest possible piece of code to make the test pass, and do so as quickly as you can.


Navigator / Driver

Notice that this isn't "Observer / Driver", as I have sometimes seen it described. I don't like "Observer", because it implies a passive role. At it's best, the person who is not writing code should feel like they are working harder than the person on the keyboard.

This is an intermediate-to-advanced strategy, and the way that pair programming works in a high-functioning team. The roles are:

Navigator
  • Thinks strategy: "What do we need to test?"
  • Keeps the overall objective of the story in mind.
  • Keeps track of potential refactorings along the way.
  • Does NOT tell the Driver what to code.


Driver
  • Thinks tactically: "How do I write this test?"
  • Focused on the next small step.
  • Keeps up a dialogue with the Navigator, describing what he/she is doing.

The key is to switch roles periodically. You don't want to do it too often, or you risk getting out of a good rhythm. You don't want to do it too seldom, because it's too easy for the Navigator to become disengaged.
Good times to switch are when:
  • There is a change of concept.
  • "I need a change."
  • A timer beeps (this isn't a bad way of starting with this technique, but not best for long-term).

Wednesday, May 9, 2012

Team Accountability: Be Courageous, But Don't Be A Jerk

I have been helping to lead an agile transformation / continuous improvement effort for the past couple of months.  It has been a great experience, and I want to capture some of the things that I'm learning as I go.

In yesterday's stand-up, one of the coach/developers brought up a problem he saw.  One of the team members appeared to have waited too long to ask for help, working on the same story for several days.  It went something like this:
We need to spend more time listening to each other and ourselves in stand-up.  If you find yourself saying "I'm almost done" two or more days in a row, or if you hear someone else doing it, that's a red flag.  For instance, I was pairing on a story with Bob last Friday, and I heard him say today that he was almost done with it.  He and his pair need to say "we're blocked", and reach out for additional help on their story.
I thought it was well put, but Bob (not his real name) was pretty upset about it, and felt that he was being called out.  I brought it up again in this morning's stand-up, and made it clear that what was being called out was the behavior, not the person.  I even said that "Bob wasn't being singled out - we need to call out improvement opportunities as we go so we can all learn."

He wasn't completely satisfied with that response and we've gone back & forth a couple of times over it.  I consider this a very good thing.  Minimizing conflict and argument in the interests of getting along is a bad practice.  It is far better to call out problems as you see them, provided that you keep the following in mind:
  • Always criticize a practice, rather than a person.
  • If you use a person as an example, be sure to make it clear that this is an example of behavior that anyone on the team could end up engaging in if we don't guard against it.
  • Be polite.
In the case above, "Bob" may have already asked for appropriate assistance, but the coach wasn't aware of it.   That really just highlights another problem about communication in stand-up - if you're blocked and find help, but you're still not done, say so.  Someone else may have something to offer, and the whole team should know that you're working on a particularly thorny problem and may call in more points of view.

The purpose of stand-up is to enable good communication.  This helps us hold each other accountable, which is another way of saying that we help each other to be good team players.

Friday, February 3, 2012

Agile Performance Management: Why Performance Reviews Suck

What People Actually Hear in a Performance Review



Many thanks to Mary Poppendieck, who wrote about this topic in 2004, and proposed a comprehensive solution.  She is the inspiration for much of my thinking on this subject.  She is also a better writer than I am a cartoonist.


Performance reviews suck.  I don't know of anyone who goes into their appraisal without some trepidation.  Your boss is guaranteed spring some surprise criticism on you that is ill-informed or misses the point as you see it.  It's a real challenge not to get defensive about that.

The only thing that makes your own performance review suck less is having to give them.  As a manager, I have dished out quite a few, and some of them went pretty badly.  (To the people at my first management job: Thanks for helping me learn how to get better at them.  Your sacrifice was not in vain.)  Since then, receiving one isn't nearly as gut-wrenching, if only because I try to make it easier for the guy on the other side of the desk.  I've been there, and I know how clueless I feel trying to evaluate someone who is at least as smart as I am.

So, why do reviews suck?

  • You usually get a year's worth of "constructive feedback" in an hour or less.
  • "Mixing the good with the bad" makes it hard appreciate the positive things you've done.
  • The purpose of the review is to explain why you're not getting a large raise.

This last point is important.  I have never worked for a company that dishes out large raises based on a performance review.  Sure, you can get 1-2% more than the other people on your team if you really kicked ass, but the pie is just too small to give you much more.  Real compensation bumps come from bonuses or promotions.


Performance evaluations are counterproductive
It gets worse if you're managing an agile team.  "Agile" is all about team performance.  Evaluating individual performance lies somewhere between "very difficult" and "you're sure to get it wrong".  In fact, effectively evaluating individual performance is counterproductive, and can actually make the team worse.

Why?  Let's compare individual and team performance first.

Outstanding individual performance is very different from outstanding team performance.  More to the point, individual performance - by the kind of metrics we usually use, is much less valuable than team performance.  Consider that a strong "team" contributor might constantly enable others to get work done - cleaning up a backlog, helping teammates fix broken builds, working with a product manager to eliminate low-value storie, etc.  Such behavior might add quite a lot of velocity to a team and provide a regular morale boost ("we're really moving fast!"), but it is almost impossible to measure for an individual.

On the other hand, it's pretty easy to tell if a team is performing at a high level.  Is the product owner happy?  Are they getting things done as fast or faster than expected?  Are the customers happy?  Do you feel the velocity in the team room when you spend time in there?

So how does measuring individual performance hurt team performance?  By fostering competition.

When you ask people within a team to compete with each other for their share of the pie, you're asking them to make themselves look good at the expense of their teammates.

Think about it.  Using traditional evaluations, you don't get the biggest raise by helping your teammates the most.  You get the biggest raise by convincing your manager that you add more value than the other people in the room.


Fortunately, your efforts are wasted.
Luckily, an annual review happens too seldom to have any impact.  Until I started managing people, I thought I was the only dummy who consistently forgot to look at his goals throughout the year.  Nope.  I doubt that anyone on my team has an IQ under 120, and none of them do it, either.

If someone gets a good review, they walk away thinking, "Whew!  I'm glad the stuff I did matched up with my goals, since I haven't looked at them since last year."  If they get a bad review, it's "Screw this place and my next raise.  I'll find another job by this time next year."  (They think this even if they accept the review with apparent good grace.  Watch their performance a while and tell me I'm wrong.)

So.  Either your efforts are neutral, or they have a negative effect.  That sucks if you've been spending days and days of your time gathering feedback, and obsessing over the precise wording on the review form.  Sorry.


Bullshit, my team is doing great!
What's that you say?  You are a good manager?  You have a high performing team, and you deserve some credit for that?

You're probably right.  It just has nothing to do with performance evaluations.

If you have a capable, hardworking team, it probably is due (at least in part) to your efforts.  But they're not doing great because of your evaluations:

They're smart because you hired well.  They're all pulling in the same direction because you've shown them some leadership. They're thinking for themselves because you get out of their way.  They're telling you about problems early because they know you care about them, and they want to reciprocate by making your job easier.

So relax.  You did great.  Have a cigar.


Managing Losers
The manager of a traditional team is focused on extracting as much work as they can from a bunch of losers who aren't in the same league as the manager.  You disagree?  Read Mary's article and take another look at your what "performance management" really does, compared to what it is supposed to do.  The entire process was designed in an age of command-and-control management, when the boss was always right.

I'm not accusing you of treating your people like losers.  I'm saying that reviews motivate people to do just enough to not get fired, or have no effect at all.  If your team is going above and beyond, it's because you're doing something else right.


So what's the answer?
The short answer is "Do what Mary says."  To help you decide whether to read her article or not, here are the "Cliff's notes" from what I saw in it:

  • Eliminate the annual performance raise.
  • Give a small annual cost-of-living raise.
  • Create finer-grained job titles and salary bands.
  • Reward teams frequently.  It doesn't need to be money (in fact, it probably shouldn't be money).


I like her advice, and I think it's workable.  Unfortunately, I haven't found a single case study showing that it works after a whole five minutes of searching Google.  (OK, maybe it was a little bit longer than that.)  I also don't think I can sell it to my HR department any more than you can sell it to yours.

The best way to deal with the problem is will be with a transitional / hybrid approach of some sort.  I'll be sure to post that approach when I find one that works consistently.