Tim Segraves

Leadership books can provide a lot of great information about how to run companies.  I’ve read a lot of great ones, some not so great ones, and some shitty ones.  The problem with most of them is they were not written by software developers, for software developers. Trying to manage a development team using the techniques in these books is a good way to end up with a team of unhappy, unmotivated developers.

The Level 5 Leader

If you’re trying to find or develop Level 5 leaders on your dev team you’re at best wasting your time, at worst mortally wounding the moral of your team.  While the Level 5 leader makes a lot of sense for the type of person you want to running your company, trying to get everyone to aspire to that or think in that mindset is a mistake.

It’s not to say developers don’t need mentorship and coaching but the one-size-fits-all approach of most leadership books can be damaging when applied to developers.  I’ve seen too many happy developers/engineers/designers/etc become frustrated due to the type of management that from the outside looks to be “textbook”.

Why is it Wrong?

With the occasional exception, most developers want to get their shit done.  Asking for status updates, commitments to deadlines, meetings to discuss progress, conference calls to discuss known issues, etc. is counterproductive.  This is especially true for your top developers that know the process, requirements, expectations, etc.

Project Leadership

Below is a simple formula for leading a development team from a project perspective.

• Make sure your team knows what is expected up front
• CLEAR THE PATH
• Make sure your team knows you can help them track down any questions
• CLEAR THE PATH
• Make sure your team knows you’ll address any blocking issues
• CLEAR THE PATH

So the key here in case you couldn’t tell is clearing the path for your team.  They know what needs to be done, help them do it.

Career Leadership

“So where do you see yourself in 5 years?” Everyone’s favorite question right?  While I hate the question, the point of it is valid. You need to make sure you know you’re doing what you need to in order to support your team in their career goals.  The problem is this shouldn’t be a question you ask every 6 months in a formal review.  You should know the members of your team better than that.

You should know their strengths and weaknesses and know the direction they’re heading. You should have the conversation when it appropriate and makes sense, not when the HR department says it’s time to.

Conclusion

To sum all this up, your development team needs to know you have their back.  They’re going to bust their ass for you if you just let them.  So go forth and don’t be an obstruction to your team.

While these two topics are often discussed in the same context, they are in many ways, opposing ideas. Continuous Delivery requires a path to production for any code that is ready to be released but Continuous Integration says you should be integrating all of your latest code together multiple times per day. This makes releasing a certain feature that is ready difficult because it has been integrated with other code that may not be ready for prime-time.

In this post I’ll talk through a couple of techniques to find the balance of continually integrating your latest code while also being able to do on-demand releases of any work that is ready.

Branch By Feature

While this has typically been frowned upon by the CI crowd, there are some benefits to this approach. The perceived negatives of this approach are:

• * It promotes long running feature branches where the code isn’t integrated with other work until it is pushed into the trunk.
• * Branching has a lot of overhead.
• * It causes developers to work in a silo where they are not in touch with the rest of the team.

While these can be negatives, there are some techniques that can be applied to get around these. GitHub branches by feature successfully by pulling down latest from master for any feature branch that runs longer than a few days and utilizing pull requests to move code between branches. They also are able to run their test suite on any branch. A few things that can make branching by feature work better:

• * Keep your work items small. Small work items or stories can be completed in a couple days or less which should immediately be merged into master and released once they are completed and have passed all automated tests. Feature toggles may be required in order to hide incomplete features.
• * Merging down from master allows you to keep your branch in sync with anything that’s been released to production.

Integrated Feature Branches

I first read about this from a post from Adam Dymitruk as I was investigating a similar solution for my company. It basically starts out like the above flow from GitHub but adds in a CI branch.  Each feature is developed in isolation but regular checkins and merges are made to an integration branch where tests are run and you verify that all of the in-progress code plays nice.

The key to making this work with CD is to only merge up to the CI branch and never merge down.  By merging down you lose the ability to deploy your code in isolation so this should be avoided.

In the event you want to use some code someone has written in another branch you can cherry pick it from that branch directly without talking to the integration branch.  Some other benefits of this approach are:

• * It keeps the ability to release code to production in isolation.
• * Code is still integrated constantly to ensure developers aren’t breaking each other’s code and not knowing for days or weeks.
• * It also allows for more rapid development since you are able to focus solely on your code in isolation.
• * When using Git on another DVCS you can still collaborate with other developers on a single feature branch.

Tooling

Obviously tooling becomes very important for branching by feature to work.  Using something old school like SVN or TFS will have obvious issues with all of the branching and merging but in theory it would still work.  More modern systems like Git or Mercurial makes this much easier among other things.

Now go forth and branch, integrate, and ship your code!

I officially opened up the site I’ve been working on this morning to new users.  You can signup for free at www.twistertracker.com and start tracking severe storms and tornadoes as they happen.