What Good Is Code History?

Seriously, I'm asking.  I had this discussion with a colleague the other day, and it left me feeling unanswered, so I'm curious to hear some anecdotes.

I assume that since it's 2014, we are all using some kind of source control repository.  One of the main reasons we have repositories is to keep our code safe in case something happens to our dev machine.  If you didn't have a saved copy somewhere, having a hard drive failure would be catastrophic to your organization.

One of the ancillary features that comes with source code control is incremental history.  As source code files are added, deleted, or changed, source control repositories dutifully keep a history of all changes, and they keep that information indefinitely.  I have always assumed that was a good thing to have an indefinitely long history of all code changes since inception.

Now I'm not so sure.

At face value, the code history is about finding how things were in the ago, some indeterminate time in the past.  They don't represent the production codebase of today (especially if you release features frequently).  In a lot of agile shops, the code in them is stale after only a few weeks.

Some companies have processes that theoretically allow you to pick any date in the past and redeploy the entire system as of that date.  You have to have code history to enable this.  Unfortunately, despite unlimited rollback being cited to do any number of things in the software industry, it's rare that rolling back is actually plausible.  DB changes, business processes, bug fixes that have been made since that date - those can all torpedo the idea of rolling back to some generic past date.

Maybe there's a legal case for keeping code indefinitely.  I'm not aware of such requirements, but I can imagine that maybe certain industries/entities may require it.  If it's a requirement for you, I give it a pass, although I still question what the actual benefit of digital hoarding is.

When I think about the uses I've had for code history, it's almost always been to research something that the team is certain was working at some point, and we have a new bug reported.  The purpose of the research is to look at the history of the file and find out not only what change was made who made the change.

Why does who made the change matter?  The only thing that you should really care about as a team (assuming you're all competent developers) is whether the code works, right?  Something is broken, and we want to fix the problem.

One reason you might want to know who made a breaking change is to ask what the thought process was behind the change, and whether they have a reason that the change wasn't made differently. I've never seen this reasoning hold up in practice.  Most often, the person responsible has implemented dozens of features since the one that's broken and doesn't have the slightest idea why something was done a particular way.  Also, frequently, the person making mistakes can feel checked up on or targeted.  Making team members defensive or concerned about not being valued or thought less of will not help the team.

Also, figuring out who made the breaking change has the effect of personalizing the code, when it's actually the team and the team dynamic that allowed the change to be made.  We want to keep things as ego-free as possible.

So is it all about blame, then?  Is that the only reason you would want to know who made a change? I'm on the fence about that.  Modern development shops all have some kind of automated testing associated with their development cycle.  While it is not impossible to introduce breaking changes into well-tested code, it should certainly be difficult.  When implementing a new feature, if the code you're changing isn't already tested, it's your responsibility to get current behavior under test, and then introduce new tests for the new behavior.

Strong teams hold each other accountable for not mistakes, which are unavoidable, but for process. If there is an indication that, say, testing process was subverted, it's useful for a team lead to pull a person aside and say something like, "Hey, I just fixed a production bug, and it looks like you may have been involved with this code in the past.  I noticed that we could have had better test coverage of the feature, so let's check out what I did to test this code.  I'd value your insight, in case I'm missing something."  It could be that the feature was urgent and the developer on the story was too afraid to ask for help testing.  Turn the problem into a teachable moment without belittling or threatening and the team member levels up without fear.

I'm curious to hear what y'all think.  Could you live without your source control history?  Why or why not?  What other uses have you had for digging into the ago?

Creating an Ego-Free Environment

For years I've been talking to my teams about "ego-less development".  I don't remember where or when I heard about the concept, but I thought I'd take a couple minutes to talk about what that means to me.

For me, ego-less development starts with the recognition that not everything is about me.  All of this code we write daily is code written by us on behalf of and for the organization that employs us, and for which we are paid a (hopefully) fair wage.  When we are done writing it, we do not own it.  It is not who we are.  The idea behind an ego-free environment is that you check your ego at the door, and do your best to produce the best software for the company the best way you know how.

You can think of software as commissioned art.  Not every piece is perfect, but when the project is over, the piece sits in the living room of the commissioning person to be enjoyed by that person, not taken home.

When you take the perspective that the code that you write is not yours, it becomes a lot easier to decouple yourself from the code you write.  Many people take criticism of their code as a criticism of their own person.  While criticism on your code can include a criticism of your skill set, it's should not be intended to suggest anything wrong with you as a person, even though your mind might translate the criticism.

The translation works like this:  What's said is "Well, I see something wrong in this code here." What is heard is "You wrote this code.  Something is wrong with it.  So something is wrong with YOU! STUPID!"

If you're a team lead, you need to make sure that the culture changes so the message comes across correctly.  Here's a couple things I've found really helpful in cultures I've been part of:

Freely admit your own mistakes:  Everyone makes them.  It's no fun to make them, and worse to have things blow up because of something you did.  When things do explode, fess up.  No excuses. "I did that. I'm really sorry."  You're looking to demonstrate the correct approach that you're looking for. Lead by example.

Let people know it's okay to screw up:  While habitual bad performance has to be addressed, not every little failure is something team members should feel like they have to fret over.  Be honest. Don't gloss over it by saying it's okay.  "Yes, you screwed up.  We've all been there.  We'll do what we need to fix it."

Don't map ownership of specific code to people:  If there's a bug found in the system, there's a tendency to say something like, "Oh, looks like a bug in your code.  Guess you better get in there and fix it." Once the code is integrated, it's company code.  You don't own that code.  Anyone can go fix it.  Throw the bug in the backlog and let the next available dev snag it.

Use positive language, even when disagreeing:  Yes, this is software, and at some point you've got to ship.  Sometimes there are differences of opinion, but you lose the instant you say something like "Well, the smart thing to do is..."  That's another way of calling someone stupid, if they legitimately disagree with you.  Language and communication sets the tone.  Make sure that you phrase the argument in terms of risks, rewards, costs, or benefits.  "The problem I see with approach A is that X, whereas this other approach [note: not "my approach"] avoids that problem."

Let's say you even get to Nerdvana and have an ego-free environment.  Never forget that there are scores of cognitive biases out there and that at any point, you may be falling prey to them.  Keep an eye on your own communication to ensure that you're truly communicating the way you would like. Even in an ego-free environment, people still can be defensive.

Not many environments work as one-person bands.  Great work takes great teams.  Great teams are formed by trust.  Check your egos at the door, and build that trust in your environment today!

Inspire the Troops

Ok, so today I want to talk to the team leads, the tech leads, and the tech managers out there, the people that other developers and software engineers look to when they want answers, the people whose job involves technology thought leadership.

One of your biggest challenges at your job is motivation.  Not yours, obviously.  No, you're the kind of go-getter who gets up in the morning and eats a big bowl of "I can do it" for breakfast.  You read blogs.  You watch your favorite speakers on Twitter.  Your motivation is beyond reproach.

But you've got folks on your team who have been doing this whole development thing awhile.  Maybe they've been working on that document management subsystem for two years and are really coasting. Maybe they've been stuck on the same platform or same language so long that you see them not being able to think outside the box for a solution.  Maybe they are sitting around waiting for direction instead of proactively looking for improvements the way they used to.  That doesn't make them bad employees.  Life sometimes happens.

As a team lead, you need to get their enthusiasm up.  You need to generate in them a lust for coding.  Not so they'll code for you 12 hours a day.  Don't do that.  Burnout is as bad as or worse than a lack of enthusiasm. No, you need your folks to enjoy coding, to enjoy solving problems, to think about their work critically and try to find and suggest new ways of doing things.

But that's a slippery and elusive thing to go looking for.  Team motivation might as well be your white whale. You've tried lunch and learns, brown bags, watching team internet videos, and that seemed to help, but you're only one person, and you can't do your job and also manage an inspirational team calendar.  Or maybe you can and it's just not enough.

So here's what helped me.  That Conference.  I've made it no secret that community conferences changed my life.  That's just me.  But you're not me.  You're a successful team lead.  You've got the motivation.  So don't come to That Conference.  Send your team.  Here's why.

See, if you want them trained on a particular topic, send them to Pluralsight (I'm not a shill, and they're not a sponsor, but I've had good luck with them).  Send them to a class.  There are lots of good training programs.  Sometimes those programs inspire, to be sure.  But I've seen so many people sit through a dull class and come out bored.  That's if they were even happy to be there or paying attention to begin with.

What about big conferences, like TechEd, or Google I/O, or one of the huge $2500/ticket conferences (never mind the per diem, the hotel stay, the air fare => maybe you're looking at a $5k total)?  They have value, sure, and employees may be motivated by the fact that you've given them a perq.  There's value in that , too.  But motivation to code and get things done may not be the value there.  Maybe it's too marketing-speak.  Maybe it's too specific.  Maybe it's too platform-limiting.

That Conference, and polyglot community conferences in general, are designed to inspire.  By getting attendees into a place where the boss has no presence and giving them a buffet of technologies to feast at, you allow them to rediscover why they came to that field to begin with.  You offer them a chance to see different approaches, try different platforms, or understand a different technology culture.

August 11-13, we're hosting the biggest, baddest community-led technology conference/summer camp at the Kalahari Resort up in the Wisconsin Dells.  150 sessions on a glorious and dizzying array of technologies are available to attendees.  Encourage them to go to sessions outside their comfort zone, and they may amaze you with what they learn.  Even if they stay near to their platform of choice, however, they will find their ideas challenged, and their techniques extended with everything from overview sessions to deep dives.

Of course, it's not just about the technologies.  At the end of the day, we're all people interested in similar things.  Many of the Speakers (err... Camp Counselors) are industry leaders, but they don't fly in and fly out without interacting.  They hang out, meet people, share war stories, and in general are available.  I have chatted to people on Twitter forever and then met them for the first time in person at community conferences. Meeting inspirational people is just another way to get motivated.  Heck, just meeting a new colleague at another company who is doing similar types of development can be rewarding.

All that would be totally invaluable at the price of one of the bigger conferences.  Inspiration and motivation are hard to create, but they seriously affect your team's productivity.  That Conference tickets come in at $399.99. With easy travel by auto for anyone in IL, WI, and MN, and most meals included with the ticket, you're talking about more enthusiasm and motivation for potentially south of $1k.  Such a deal, really.

So send your teams.  Let them bring back their enthusiasm to you.  Let them share with you what they learn. Tickets on sale now.

Hey wait, before you go, remember how I said not to come to That Conference?  I lied.  We totally want you to come, too.  We value that leadership and enthusiasm.  Speakers for the main sessions are already set, but there are dozens of Open Spaces slots over three days where you can share what you know and maybe even get a little inspired yourself.  Come out and meet me.  I hope to see you there.