Don’t “Good to Great” Your Dev Team
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.
Continuous Delivery vs. Continuous Integration
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!
Twister Tracker Beta
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.
Ruby Version Manager (RVM)
So I’ve been struggling lately after trying to update my native/macport installation of Ruby/RubyGems/Rails to 1.9.2 and Rails3. After tons and tons of errors I decided to try RVM. Worked like a champ! I was up and running in less than 10 minutes. I’d highly recommend it if you are having configuration issues on OS X.
UUIDTools on Media Temple
So I’ve been working on deploying my site to Media Temple and ran into some problems with the UUIDTools plugin. I think the root of the problem came from the fact that on the Grid Server at MT you cannot use the ifconfig command which the plugin was using to determine the mac address in order to generate a UUID (or GUID). The other issue was the @@mac_address was not defined when I installed the plugin on MT (though it was fine locally). Here’s what I did to fix these issues in case it helps anyone else.
1. Add the following line just below class UUID if it doesn’t exist:
@@mac_address = nil
2. Comment out the following section and add in any valid mac address:
# if mac_address != nil && mac_address != ""
# nodes = mac_address.split(":").collect do |octet|
# octet.to_i(16)
# end
# else
# nodes = self.random_bits(48).split("").map do |chr|
# if chr.respond_to?(:ord)
# # Ruby 1.9
# chr.ord
# else
# # Ruby 1.8
# chr.sum(8)
# end
# end
# nodes[0] |= 0b00000001
# end
mac_address = "00:1d:2a:fb:d2:1f"
There’s probably a better way than hardcoding one in there but it’s working for now. If anyone has any other suggestions I’d love to hear them. Thanks.
jQuery on Rails
Though I feel a little late to the party, I’ve recently discovered the joy of jQuery. I did have some trouble though getting it to work with the Rails app I’ve been working. Here’s what I came across in case it helps anyone else.
Most examples you see on the web for using rails use the following in the controller for handling and responding to an ajax request:
respond_to do |format|
format.js {}
format.html { render :text => "Location Changed!" }
end
The problem was I kept getting a syntax error in the JavaScript returned to the page. After several hours of trying different things, I realized it was rendering the JavaScript specified in the .js.erb file wrapped inside the layout html. In order to fix this I did the following:
respond_to do |format|
format.js { render :layout => false }
format.html { render :text => "Location Changed!" }
end
I suppose the other thing that could be done is to not render the layout for the action handling the ajax request.
layout "main", :except => :your_ajax_action
Git r’ Done
I’ve recently started using the Git version control system. I’ve found it very easy to use, especially with the TextMate bundle. It’s a distributed version control system which makes collaborating with remote people really easy.
I’ve been using GitHub as my host and have had great luck with them. I highly recommend checking them out. I’ll be posting soon about configuring a Capistrano script to work with GitHub and MediaTemple.