Why Katas

The Merriam-Webster dictionary provides the following definition for kata

Kata

a set combination of positions and movements (as in karate) performed as an exercise

Most people are probably familiar with katas as they are used in martial arts (come on, admit it, you liked the Karate Kid).  My introduction to katas in software was through the Software Craftsmanship movement, where they are often used as training exercises.

It is important to understand with coding katas that the idea is not to do the exercises the same way every time.  Katas are a great way to experiment with different techniques and styles.

• Can I provide more descriptive naming
• Does a terse syntax make the code easier or harder to understand in a particular place.  Would a more verbose, explicit approach be better.  For example, in the case of a complex ternary operator, would an explicit structured if/else construct be better?  Worse?  Try them out and decide for yourself.
• Experiment with different syntax, e.g. the unless keyword in Ruby.  More or less readable?
• Should I use a defensive programming style checking for nil/null in several places or a more confident programming style?
• How am I naming my tests (yes you should be writing tests as part of your katas)

There are no right or wrong answers to these questions, the goal is to experiment and try out new ideas.  Understand where an idea works well and where it doesn’t work well.  Try a variety of approaches.  And the great thing about a kata, unlike your code base at your real job, is that you can blow it away when you are done and do it a little different the next time.

Katas and Interviews

I’ve been using pairing as a key part of the interview process for several years now, but a consistent challenge is to what to pair on.  It is unrealistic to assume that most developers are going to walk in the door and instantly grok your code base.  No matter how awesome you are or how descriptive the tests are, it’s just not gonna happen. Instead pick a problem set that a candidate can quickly get their head around and that you can discuss different design and implementation choices.

Katas and Pairing

I had an awesome pairing session yesterday with someone I had never worked with before, and we did some katas as a way to get to know one another, discuss approaches to coding, good naming, refactoring techniques.  It was a blast!

And the really great thing about katas and pairing is that it can be challenging to think of different ways to try something on your own.  But with a pair you have different perspectives baked-in.  And what you can learn may not be strictly code related: it could be keyboard shortcuts, different IDEs or editors, maybe even a wacky keyboard.  Don’t be afraid to experiment.

Resources for Katas

Cyber Dojo
Great resource for ideas for simple exercises.  Even if you don’t use the online collaboration tools, it has a great list of problems that can be used for a kata.  I used this yesterday for my leap year kata in Ruby

Dave Thomas’s Katas
This is the blog post that kicked off a lot of the talk about katas in the software craftsmanship movement. Again, great problem sets that you can get your head around quickly, but with enough meat for some interesting challenges to address.

Your Friendly Neighborhood Software Craftsmanship Group
Here in Boston we have Boston Software Craftsmanship. Great group, someone’s always willing to pair.  Find your local group, or start one yourself.

Another Developer on Your Team
Ask someone on your team if they’d be interested in brown bagging it some day and do some kata’s together.  You should do this especially if you are not pairing now or are not doing TDD.  You may find that you should really be pairing and you really should be doing TDD.  You should.  Really.

CodeRetreat.org
I had a great time at last year’s Global Day of Code Retreat.  Check it out.  Conway’s Game of Life is a great coding exercise.  This also introduces some great constraints and pairing ideas that really get you thinking.

Now get out there and start coding…

Startup Lessons Learned Conference

Yesterday was the Startup Lessons Learned Conference in San Francisco.  Although I heard it was a beautiful day in SF, I enjoyed the conference from Cambridge, compliments of the Lean Startup Circle – Boston.  It was a great day, met a lot of interesting people in Cambridge, and heard a lot of interesting folks via the simulcast.

This was my first time at a meetup of the Lean Startup Circle in Boston and I really enjoyed it.  The group may gravitate a bit to the entrepreneurial side, but that is not unexpected.  Still I would like to see a broader spectrum of people and industries embracing the ideas of lean/agile, but it is a movement and that will take some time.  But thanks again to Matthew Mamet and John Prendergast for putting the event together.

Keynote – Eric Ries

Eric Ries kicked things off with the keynote.  The takeaway for me here was the definition of a startup:

A human institution creating a new product or service under conditions of extreme uncertainty.

It has nothing to do with the size of a company, what industry it is in, how it is funded, etc.  We need to develop practices that are geared towards managing and responding to that uncertainty.  He talked a lot about the Build, Measure, Learn loop (which Kent Beck later turned around to the Learn, Measure, Build loop), ways to fail fast, and knowing when it was time to pivot.  If you follow Eric’s blog there was not much new here, but he was setting the table for the presentations and case studies that would follow.

Build, Measure, Learn – Kent Beck

Kent Beck followed Eric Ries.  Kent was part of the Agile Manifesto and invented test-driven development and pair programming.  As a developer, TDD and pair programming are two of the most powerful tools/practices I have seen in all my years.  As I mentioned earlier, Kent talked about the Build, Measure, Learn loop, which makes sense from an engineering/development point of view, but by running the loop backwards, we are pulling the build (from Lean Manufacturing‘s concept of pull) from what we learn.

Kent also went through other aspects of the Agile Manifesto: people over processes, collaboration, accepting change.  He was preaching to the choir, so he didn’t go into too much depth.    He did go into some depth on knowing when to live with a simple solution to get a product out (he used the term “hackery”) and when you need to refactor.  As an example, he cited Amazon Dynamo.  At the scale they operate at now, this is an essential service, but if the had tried to start with that, they would have ended up in the scrap heap.  As a developer, I have seen many projects get behind by over-designing or over-engineering early on.  Getting out there early allows you to see if you have a viable product and as you learn more about usage/features you can refine your design and implementation.

Agile Development Case Study – Farb Nivi

A real highlight for me was the Agile Development case study at Grockit, by Farb Nivi.  Farb went into a lot of great info about accepting change/chaos, how to write good user stories (make them narratives, not “to do” lists).  He talked about an Agile planning  tool they use called Pivotal Tracker that I need to take a look at.  His presentation also had a very cool feel to it and was done with a tool called Prezi.

The thing that really caught me about Farb’s presentation was the development culture and the way they have embraced pair programming.  The interview process at Grockit is simple.  Candidates come in and pair program with one of the development team.  I can’t think of a better way to get to know whether a candidate is someone I would want to work with and has sound software engineering skills. I have had a few posts on the value of pair programming and the challenges in getting more developers to adopt it, so having this question about a candidate answered up front is invaluable.

Grockit’s philosophy on languages is simple and straightforward too.  They don’t care what languages or tools you have used, if you have good skills and work well as part of a team you will be able to produce good code in whatever languages they are using.  That is an incredibly refreshing and enlightened attitude (although on their website they say you need to have programmed in Java and Ruby for at least a year.  Jeez, Farb which is it LOL).  Developers at Grockit spend 70-80% of their time pairing, with the reminder spent on spike’s or some other stand-alone tasks.

Getting to Plan B – Randy Komisar

After the break, Eric Ries sat down with Randy Komisar in a talk titled “Getting to Plan B“.  This was a great back and forth discussion between Eric and Randy.  Randy talked about answering the “Leap of Faith” questions.  These are the questions that you need to answer, that if you don’t know the answer to will kill your product.  They can be technical, marketing, whatever.

Randy also talked about the importance of a “dashboard”  to guide you and track your progress: are you measuring the right things to answer your leap of faith questions.  I found some interesting articles with the Sloan Review and Sramana Mitra that touch on a lot of what he talked about.  When the presentations go online I strongly recommend watching this presentation.

In Closing

There were several other good presentations, more than I can write about.  When the presentations go online I strongly recommend checking them out and finding the things that hit home for you.  And thanks again to the folks at the Lean Startup Circle – Boston for putting on the simulcast and giving a place for people to get together and exchange ideas.

Update: The videos from the Startup Lessons Learned conference are available on justin.tv

Convincing Developers on the Value of Pair Programming

Something that often comes up when discussing the topic of pair programming is the notion of convincing management of its value. Am I paying twice as much to have two developers to work on a task instead of just one?

My experience with convincing management of the value of agile and XP methods has been if you deliver software on time and with few defects management will accept whatever practices get them those results.

The problem I often face and find much more challenging is how to convince other software developers of the value of pair programming. Getting comfortable with pair programming can be a challenge. The evolutionary nature of software development in an iterative, TDD environment means we don’t have all the answers up front. That can be an uncomfortable feeling. Nobody wants to look like they don’t have a clear vision of where the design is going or be uncertain about the best way to implement it. My advice is to get over it. The other person you are pairing with is in the same boat. When you switch seats and they are at the keyboard, they are going to be leaning on you to see the big picture and help guide the design.

Some people advocate code reviews and feel they can serve the same purpose as pairing. That is true in a sense, but one of the problems I have with code reviews is grasping the subtleties of the design and what trade-offs went into a particular design decision. With pairing you are intimately involved in the design, coding, and testing. You talked out the trade-offs as you went along. The tight feedback loop in pairing also reduces the likelihood of having to make a major refactoring that may come out of a code review. I am not opposed to code reviews, I just think pairing provides a better mechanism for good design and coding practices.

A lot of successful pair programming has to do with the two engineers developing a good working relationship and respecting one another. Talk through alternatives, try different implementations, write good tests, listen to one another, and learn from one another. My pair programming experiences have been some of the most gratifying development experiences in my career.

Pair Programming Follow-Up

In my last post I described some of my early impressions on my first pair programming experience. Still no complaints, although a few additional observations.

I am surprised at the end of the day to find that I am a little mentally drained and I think that is a good thing. The effort that we are putting in is sustainable, but it is also very focused. There is little down time since at any given moment at least one of us is “on” and good progress is being made. Even when we are at a point where we are stuck the ideas are still flowing and we are both mentally engaged in the process.

Given the focus that we both have on the task, I find it beneficial to take breaks from time to time to check email, grab coffee, and even read a few blog posts. It would be a tough pace to maintain continuously and I think the occasional 5-minute break keeps both of us fresh.

We are doing a good job of share time at the keyboard, and I see a real difference in the approach I take depending on whether I am at the keyboard or not. When I am at the keyboard my focus is on the details of programming: variable names, style, and yes…just being able to type with someone looking over my shoulder. When I am not at the keyboard I seem to see the big picture better: are we repeating code, what is the complexity like, is this code easily testable.

I just started reading James Shore’s The Art of Agile Development and I hope to learn more about the mechanics of pair programming and tips/techniques to be more successful at it. Mike and I are pairing well together (I think), but I am also looking forward to pairing with someone else on our next iteration , getting a better understanding of how they work and how we can work together.

Pair Programming

I’ve been doing some pair programming this week and have found the experience to be extremely productive and informative. I am pairing with a guy named Mike, who is someone I have worked with in the past and really enjoying working with. We are in the midst of a fairly significant refactoring effort for a particular component.

Although Mike and I often bounce ideas off each other when we are working individually, I think the quality and flow of ideas is significantly better now that we are pairing. That only makes sense I guess. Even if it is code that you are familiar with, when someone asks you a question while you are working on something else it is difficult to grasp the subtleties of the problem. During this pairing effort we are both intimately familiar with the underlying problems and can quickly comment on strengths and weaknesses of a particular approach. The design is really coming along well and we have been able to address issues regarding complexity, IOC, and enhanced testing.

Speaking of testing, this component has a good suite of tests and that is a real blessing when you are refactoring. I feel a lot more confident after a significant change to see “All tests passed”. I have been using NUnit/MbUnit for about 3 years now and I am trying to remember what programming was like before I had these tools. We are trying to work incrementally and each time we get to a stable point we are checking in the changes.

I have to admit that at times pair programming was tough to get used to. On the first day I found myself saying things like “if you want to go work on XYZ I can run with this for a bit and we can get back together later”. Usually this would happen when we hit a snag and I needed time to think though the problem. I was uncomfortable not writing code in front of someone else, even though when I am working alone I recognize this non-coding time as part of moving forward. Something about not having an immediate answer in front of someone else made me feel very uncomfortable.

There have been a lot of positives to the effort, and so far no negatives. I am sure that some of that is due to that fact that Mike and I work well together and have similar beliefs about software development. That is not to say we have always been in agreement, and indeed have had some spirited discussions. We have come up with a design that is stronger than either of us would have come up with individually. We are pushing each other to develop and maintain good tests, and also to push back with the occasional YAGNI criticism. We are also sharing productivity tips, comments about programming styles, ideas about new tools, blog posts, etc, etc.

One unexpected benefit of this pair programming effort has been that people have been less willing to interrupt us when we are working together. Maybe it is seeing two people working productively and enthusiastically that makes people hesitate before interrupting. There have been interruptions but they are fewer and we have also been more willing to say “let me finish up what we are doing here and I can swing by in 30 minutes”.

I am really looking forward to doing more of this. Based on the quality of the code and tests and our overall productivity I would feel confident defending the use of two developers for one task to management. I would also like to try pairing up with other members of the team. I am sure we will go through some of the same awkward startup moments but I think there is a lot to be learned and shared.