TL;DR — Release products at conferences. The products will be better and you’ll be happier.

Test-driven development is a technique that helps programmers build large applications from small, working components. It has been successful enough to unlock developers’ innate love of acronyms, ranging from ATDD and BDD to MDD and UGG. TDD is important in the industry because it forces a mental shift inside the programmer’s mind. Like most humans, programmers are all too willing to succumb to really lame brain bugs. Instead of falling for the trap of designing and implementing a grand cathedral in one single volcano of brilliance, TDD focuses on a continuous stream of achievable, minor, functional bricks. Conference-driven development offers similar rewards for virtuous choices, but works for the whole product development team rather than just programmers.

Read the rest of this entry »

Last year, my group decided to invest a certain amount (5%) of time to unstructured self-directed activities – we call it “investment time.” We do this on every other Friday afternoon.

This isn’t a new idea. The concept has been widely touted, and according to this post, it has been in vogue, or at least in use, as far back as 1948 (at 3M). There are also many well-documented flaws with this idea; see these comments. The comments on coding horror’s post are full of examples of how this can fail.

But there are good reasons to try: In a client-driven consulting organization, engineering work is tightly constrained: by feature requirements and/or by budget. Often it’s an engineer’s role to be the grownup on a project, reminding everyone about technical constraints that will lead to scope growth and cost overruns. It can be tiresome to always be the person that says “no,” and every now and then we need a chance to think expansively, try new things, and exercise our creative juices.

So the idea isn’t new, and 5% of our time isn’t really enough time to launch major new initiatives: gmail isn’t going to get invented every working other Friday afternoon. But I want to talk about this practice because I think it has had a lot of value for us, we’re a small organization without the resources of a Google or a Microsoft, and this gives us a different  perspective. In these sessions, we have a chance to try out new things, to work with different people, and to think creatively, but it hasn’t necessarily been easy to realize these benefits. I’d like to reflect on how this has worked and not worked for us, and then I’ll describe what we did in our most recent session.

Since we started this six months ago, we’ve had mixed experiences. Sometimes interesting things that provide tangible benefits have happened. We built an XSLT code coverage tool and integrated into our unit tests. We worked through some incompatibilities in our core platform so we could deploy <a href=”http://newrelic.com”>NewRelic</a&gt; to monitor it (which by the way has been a huge help). Other times people drift off and work on their regular work. A few times people have left early. My feeling is it’s OK that that happened because this is an experiment, but we do want to get the most out of the time we’re spending and so we try to learn from the failures as well as benefit the successes. Here’s a quick run-down on what seems to work and what doesn’t:

1. Celebrate success. OK this is just like mom and apple pie, but it’s easy to forget to do. We follow up each session with a report out to the whole company about what happened. It’s a good opportunity to let people know what the engineers are wasting their time on so they can see just how
useful it is.

2. Do it on a regular basis, at a predetermined time. This is really critical: it ensures that it will actually happen. The whole idea is to be open to new ideas, so you don’t know *what* you are going to do exactly, which lends a bit of an air of unreality to the whole enterprise. To combat that, you have to be very concrete and specific about when you are going to do it, who’s going to be involved, and where it will happen. Beer and food help too.

An important corollary is: no Friday releases. If you can make this part of your company culture, you will benefit regardless of whether you also have investment time. Friday releases are bad because nobody tests them until Monday except your customers – nuff said. But it’s especially important to keep releases away if you are trying to reserve some unscheduled time.

3. Have everybody in the same place together. This has been really important: the best weeks have seen a low hum of activity in the office, and significant exchanges have occurred from people spontaneously walking around the office and looking over other folks’ shoulders. However, one thing we need to get better at is involving our remote developers. There’s a tension around encouraging collaboration: some people work better alone; others in groups. We’re still learning the right balance.

4. Don’t force people to be creative if they don’t want to, or feel like they’re too busy. People shouldn’t be made to feel guilty if they’re not inventing a cure for cancer in their spare time.

Also, sometimes there is a monkey on someone’s back that they need to shake. Ideally this shouldn’t happen, but if it does, delaying work you really absolutely need to do just so you can take time out to come up with other freakin’ stuff to do obviously makes no sense.

5. Find a way to encourage everyone to generate good ideas in advance of the investment time. We’ve run an exercise with colored markers and sticky notes that was fun and generated all kinds of great ideas. Sometimes just going around the room and having everyone say what they’re planning to do
is enough.

6. Add competition to the mix. From time to time we like to issue a programming challenge to the engineers at our company. This gets folks thinking about work in new and creative ways, and well – it’s fun. We
strove to build the fastest sudoku solver; we competed in robocode matches. Hilarity ensued: programming chops were rewarded.

The Connect4 Challenge

Recently one of our engineers, Mark LeMay, came up with the idea of a framework showdown. The idea was to learn more about different programming languages and web application frameworks by devising a simple problem, applying various tools to it, and comparing notes.

The problem we chose to work on was Connect Four. This is a simple two-player game, familiar to many. You drop disks into a 6×7 array of cells, where they fall to the bottom of their column with the object of getting four in a row of your color before your opponent does the same. It seemed ideal from the perspective of being easy to program, but would require some server side programming in order to manage the game state, since it must be shared by multiple players.

We came up with a scoring rubric for evaluating entrants that awarded points for everything from “return HTTP OK” to stress testing and unbeatable AI. Pretty ambitious for 4 hours on a Friday afternoon. Yes, well it turns out that 4 hours is not enough to learn a new language, and a new framework, and to code a perfect Connect4 AI that can run while being stress tested by North Korean hacker bots (actually we didn’t try that last one, but I’m pretty sure all the entrants would have failed it).

However, it is almost enough try out some new tools and get a feel for what it might be like to do some real work with them. Here are the ones we tried: Ruby on Rails, Grails, Google Web Toolkit, Node.js, Lux (XQuery), Go and Google Apps, Clojure, Wicket, and Django. Some newish stuff, a lot of stuff that is not super new, but this was an opportunity for folks who don’t get out that much to try out a newer, younger model, um as it were.

A few things people wanted to or suggested trying were but never got to were: Scala, ChicagoBoss/Erlang, and HapiJS. Maybe we’ll check them out later.

I’m not even going to attempt to give you a run-down on all these tools in this post, but in some later posts we’ll cover some of them (we’ve already heard from Robert Hall re: sockets in node.js).