In December last year we decided to migrate our whole codebase from Subversion to git. Here is a few tips I'd give to someone considering taking the same route:

Evaluate the reasons for the migration. Think about specific scenarios where Subversion is not meeting your project's requirements. Check if too much time is being spent trying to make the current version control work with your workflow. There must be an opportunity to make things simpler or more efficient by switching to git in order to justify the switch.

In our case we were already working almost exclusively with feature branches, which is a great way to isolate our different pieces of work, but was becoming a hell due to svn tree conflicts. Even though that was the single problem we faced with subversion in years of use, the time wasted with merges lately was enough to justify moving all our code to a more "branch-friendly" system.

Do your homework. In other words, before starting anything, learn more about git. The best places to start are probably the Git Community Book for theory and GitHub for practice. For me it was really worth learning git's key concepts before moving to practice. It's also a good idea avoiding comparisons with svn until you are comfortable enough with these core concepts. Trying to simply map commands from one tool to another can make life harder, mainly because they don't share the same principles.

Consider not migrating the whole repository history. Although the process is not necessarily complicated, it'll probably be time consuming. To give an idea, our 4GB codebase took almost 3 weeks (!) to migrate using git-svn. That's mainly due to the fact it had to magically create git branches (which are copies of the full repository) from svn branches (generally partial copies). If I had to go through that again today I'd probably migrate trunk only, or even consider starting fresh by splitting our codebase into smaller git repositories and keeping subversion just for reference.

Spread knowledge before the final switch. Having the whole team up to speed with the new tool before starting using it on the day-to-day work is a no-brainer. Having a few people willing to train others and help them during the first weeks is also very important to make the transition the less painful as possible.

Accept the fact all version control systems require discipline. Don't expect git will solve all the problems in your project. What I noticed is that most of the problems with version control systems start when people get to weird workflows and forget that their work needs to be in a shared repository. Mixing branches, merging wrong content, losing uncommited changes and trashing the local repository will happen regardless of the system. We all make mistakes sometimes and it's best to learn from them instead of cursing the tool.

Now, almost two months later, I can say migrating was a good decision. Branching and merging feel more natural in git, and it has some cool features that are surprisingly useful, like cherry-picking. There are still some rare cases when a developer ended up having to recreate a local branch or even having to clone the local repository again, but even these operations are simple enough and I imagine they would probably be avoided if they had more experience with the tool and its workflow.

In any case, just the fact of not having to deal with merge nightmares in subversion again makes me really happy.

It’s been a long time since I had to help a new team member to get familiar with a codebase I’ve been working on for a while. And although this process tends to slow development, I’m really liking the kind of feedback that can emerge from this fresh look at our existing code.

After months of pairing the team developed a common understand of the system that makes sense for everyone involved, but can be really hard to grasp by an outsider. What is interesting is that this lack of familiarity seems to become very useful when it comes to spotting strange design decisions, inconsistencies, naming issues or even simplification and refactoring opportunities that otherwise would be easily neglected.

Maybe that’s something we should be doing more: getting someone who never got close to the code we want to improve and let him play with with it for a short period of time. The feedback this scenario generates is very interesting.

The Mythical Man-Month is a great book not only because of its insights about software projects. Fred Brooks also writes about the "The Joys of the Craft":

Why is programming fun? What delights may its practitioner expects as his reward? The first is the sheer joy of making things. [...] Second is the pleasure of making things that are useful to other people. [...] Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. [...] Fourth is the joy of always learning, which springs from the non repeating nature of the task. [...] Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff.

Really worth the reading.

The Pomodoro Techinique has received a lot of attention lately. The reason is simple: it works. It improves focus, removes anxiety because of time and, most of all, help us getting things done. But the greatest benefit of the technique in my point of view is that it exposes all the interruptions and bad habits we have when doing our jobs. And that's my reason to believe it should be used as a learning tool instead of a new way of working. That means using the technique as temporary assistance, not the end solution. Instead of using the tool to avoid the factors that decrease our focus, we use it to make them visible and then find ways to avoid them. After all, do we really need a timer all the time to do our job efficiently?

Another day of coding is over and you produced some beautiful code. Now what? Do you know exactly how long it will take until that brand-new feature gets to its intended user? A week? A month? Never? It's a shame that most code produced out there will park for all that time until is released. Maybe that was normal when it would take days just to compile the whole system. But today, even with all the processing power and automation, new releases are always delayed by deadlines, testing stages, approvals, sign-offs or any other form of bureaucracy. If the code is really good it shouldn't have to wait. Maybe it's time for programmers to stop hiding behind the green bars of their builds and start pushing their code out of the door.

At the Ágiles2009 coding dojo,  instead of trying to explain the whole concept of coding dojo, I jumped straight to a quick list of items that attendees should bear in mind during the session:

• If you know how to code, you should code
• If you're coding, everyone else has to understand what you're doing
• If you're the next to code, avoid breaking the flow
• If you're not coding, don't disturb who is
• If you have an idea, show it with code
• If you're stuck, ask for help
• If you liked the challenge, try it again at home

Interesting how this simple "etiquette" helped to make what I consider one of the best dojos I've participated so far.

It's been exactly one week since I came back from Brazil and now it's time to share some of what happened there. Like I said before, this tour supposed to be a "mini" tour of three days in companies from Florianópolis, city hosting the Agiles2009 conference. Here are some of my findings: It doesn't take long to get to know a company My biggest fear was that the time wouldn't be enough to really get to see people working, but fortunately I was proven wrong. Even in one of the companies where I didn't manage to actually code, in couple of hours I had a minimal knowledge to not feel lost at all. At the end I managed to visit three different companies and enjoy all of them in very distinct ways, which was great. Bureaucratic companies can waste your time The company I had planned to visit on the last day wanted me to sign a Non-disclosure Agreement before stepping into their doors. And although my contact was keen on the idea of having me there, they couldn't get the paper on time (or didn't want, I'm still not sure) and the visit had to get cancelled. Luckily when I got the news I was already in my best friend's uISV office and working with him turned out to be excellent. In the future I'll definitely skip bureaucratic environments. Every company has cool tricks to share The best aspect of this tour was seeing all the interesting stuff those companies are doing in practice, rather than through papers, blog posts or talks. Although I had no idea of what I would see in those places, it has proven to be a very rich experience. Among the things I've learned or played with are:

• Saw a lot of tricks for SEO and how they made a difference for a website
• Participated in a "internal workshop", where programmers have to talk about a topic they decided to study during the week (in that case, it was about SOLID principles)
• Had a chance to pair program using Pomodoros (I had only tried alone before)
• Saw a way to maintain custom versions of a software and incorporate client's specific requests
• Wrote my first lines of production code in C#
• Learned more about web scraping
• Realised that the combination of espresso machine and table football in the office can be very addictive!

Smart companies share their problems too It wouldn't be polite putting here all the challenges these companies face or practices I don't particularly agree with but, trust me, they were really inspiring. What impressed me is that, maybe because of the nature of my visit, all the companies had no problem talking about or even showing the problems in their code/process, or even the short cuts they've been taking to deliver their software. And hopefully my thoughts on these problems can help them somehow. I can't wait to do it again At this point it's pretty obvious that I enjoyed the tour and hopefully I'll be able to repeat it soon. Maybe reserving more time for each company would be better, but even just for a couple of days experiencing a completely different work environment was definitely worthwhile.

Writing check-in messages is normally a reflection time for me. And lately I've been inclined to describe why I changed the code, instead of just describing what I've changed. I know I have to consider that all the time, but it can still serve as a last sanity check. It makes me think: "Am I really adding a valuable change to the codebase?" Do you agree with this approach? Think about it next time you check-in and then let me know in the comments.

Most of recent software development approaches bring code closer to business. According to Agile we should write software with customer collaboration, responding to changes and constantly delivering business value. Lean is all about creating a flow of business value and removing waste. Even Domain-Driven Design advocates having an ubiquitous language between programmers and business people. It's interesting how most of state-of-art approaches to software development are focusing on business, programming itself is still seen by many as a completely technical discipline. In my point of view it's time for this to change. Here are some examples of useful things I believe all programmers should be concerned about these days:

• Understanding the company's vision and the business model where your software is supposed to fit;
• Knowing how to estimate and prioritise work based on criterion like return of investment (ROI) or competitive advantage;
• Learning about the business domain and becoming an expert in it;
• Questioning the business value of features before start coding;
• Being able to collaborate with whoever is envisioning the solution you're creating;

All these skills represent a new challenge for programmers, and learning some of them can be more helpful than hacking the last open source framework out there. The best programmers I've been in touch with lately seem to understand that and can explain not only how good their code is but how their organisations are taking advantage of their tricks.

Tomorrow I'm flying to Brazil and will have a chance to do do something I wanted for a long time: a pair programming tour. The goal is simple: work with people in their companies. Not speaking, consulting or running coding dojos. I want to experience the everyday routine, learning their ways and hopefully contributing with some of my skills too. This idea came from Corey Haines's programming tours and the work of other craftsmen like Enrique Riepenhausen, Dave Hoover and Antony Marcano from PairWith.us. Hopefully it will be an interesting way to learn new tricks. Unfortunately I'll have only three days to accomplish my goal. The good news is that it took less than a day to be contacted by more companies that I'll be able to visit, which shows I'm not the only one thinking this can be a very good experience.