A couple weeks ago I was fortunate enough to be able to attend the Software Development and Evolution Conference 2012. Since my formal training is in engineering, I never got the chance to learn a lot of software development techniques. This conference talked about a lot of stuff that falls under the umbrella of “Agile” development. The core idea is to produce quick iterations with tight feedback loops in order to get a working product out the door faster (and of higher quality) than you could if you tried to build the entire product all at once. There are a number of strategies that were introduced and I’m going to log the interesting ones here, largely for my own future reference.

Kanban

The whole third day of the conference, I was at a working shop focusing on personal kanban. Kanban was started in Toyota, and can be summarized as visualizing your workflow and minimizing work in progress. A pretty simple strategy, but it has some interesting effects. We spent most of the day putting together boards that would work for us. This started off with 3 columns full of stickies with tasks on them. The columns were to-do, doing, and done. The idea was that you want to only have a couple items in the doing column or else you will not be able to effectively concentrate on any one thing. Moving things into the done column lets you see how you are achieving things and what your work flow actually looks like. I have built a kanban board on my cubical wall (pictured above), as have my coworkers that were also at the conference, and so far I am liking it.

Test Driven Design (TDD)

I was already investigating this before attending the conference, but there were a couple talks that really drove this home. The idea is that you write unit tests before you write any production code so that you can come up with an effective, minimal solution to your needs that can quickly and easily be verified any time you make changes to your software. I have been using this on my current project at work and so far I am really liking it. I can understand how this would be incredibly useful once your projects start to get really large.

One of the conference organizers pointed me to James Grenning who does a lot of embedded TDD (he literally wrote the book on it) and he has some really great, practical tips.

Pair Programming/Code Review

While not really that related, they share some common benefits. With pair programming, two (or more) developers sit together at the same workstation and work on the same problem together. This can be useful for getting out some quality code as well as transferring knowledge to another employee without spending time on documentation. Code review has a similar goal, but the second person just looks at the code after it has been written (and ideally before it is released) and they can make their suggestions/changes at that time. While not as effective, it can take fewer dev-hours and works to the same goal. We are moving to Git at work, and so I will be suggesting using Git merge requests as a good way to ease into peer reviews; any changes to code should be reviewed and checked in to the main repository by someone else.

Communication

This point was stressed with many different techniques, from stand up meetings to silent brainstorming. Everything sounded interesting, but the core idea was to promote open communication. The one thing that I have been doing already is keeping an IRC channel open with some friends/coworkers where we can chat about any obstacles we come across. I have found this to be incredibly useful and I think I will try to get more of my coworkers involved in that. The thing that I really like about IRC is that, even if you can’t provide an answer to someone, you get to see what is going on and perhaps learn something that you could use down the road. I had one of those moments this afternoon.

There was a bunch of other great stuff going on at that conference too. I hope to be able to attend more events like that in the future.