Ivan Sanchez

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.

This week I had the chance to help the guys from the London Ruby User Group running a coding dojo for ~50 people. It was the largest dojo I’ve been involved so far and it was really interesting.

To allow everyone to participate, the attendees were divided in three groups: Ninjas, Pirates and Zombies. Each group would solve the minesweeper challenge using the randori approach and at the end each group had a chance to show their solutions.

Another interesting approach for this dojo was providing a common set of cucumber stories to guide the development. Matt Wynne wrote them and also provided a rake task to help keeping the TDD flow by encouraging people to solve the tests one-by-one (source code is available here). As a result, all the groups managed to solve the challenge in less than one hour, giving them enough time to experiment alternative solutions and refactorings.

Although there was no general retrospective at the end of the session, reading the feedback on the LRUG mailing list it seems like people enjoyed the experience. Personally, I really liked the fact that everyone participated, probably because they’re used to the language and tools and knew each other from previous LRUG meetings. Well, maybe is time to start organising public dojos again.