On Twitter yesterday,
Amy Hanlon asked everyone
for lists of short self-contained programming projects, and I realized I’ve
been collecting one of those in my head for the past few years. Time to
get it out of my head and onto a blog!

Energy level permitting, I try to spend a lot of time practicing my development
skills. And because of my priorities as a developer – integrating early
and often, responding to changes, not building what’s not needed,
incremental delivery – I prefer projects with a real UI
that can work end-to-end, rather than narrower things like math
problems. For me, a good exercise project has a few key features:

Short: I can see interesting results within a few hours, and some
results even sooner.

End-to-end: The project produces real software with a user-interface
(even if it’s a simple one like a command-line script).

Expandable: Once I have some working code, it should be easy to
think of new features.

Variable: There should be room to change requirements over time in
ways that break my assumptions and test my code’s ability to evolve

Fun: The problem should be something I can care about enough to stay
engaged.

My List

With all that in mind, here are some of the projects I’ve found myself
coming back to in my years of practice:

A Simple Blog: This can be as small as one page to list posts and
another to write them, but it’s got lots of room to grow. A few ideas:
Support multiple users! Let people edit blog templates! Change how posts
are stored (in memory? in a SQL database? NoSQL? Text files?)!

A Simple Wiki: How simple can you make it? How do you make it more
powerful without sacrificing the beautiful simplicity of its interface?
Also great because there are a lot of existing examples to compare your
code to.

Conway’s Game of Life:
This is a favorite at code retreats for a reason.
There are interesting design puzzles in how to implement the rules, and
there’s room to grow in interesting ways to. Consider: working with an
infinite board; making a simple ASCII-art UI, then moving toward a
graphical one later; changing your algorithm to something like
Hashlife.

Recruiting Puzzles: Some companies give interesting coding puzzles
as part of the process when you apply to work with them. I’ve probably
written a dozen versions of the Cyrus
code test over the years. You might need to apply to get a copy of it,
but then, maybe you should!
ITA Software used to do this, and still has a
big library of puzzles
online. I’ve had a lot of fun with their Instant Search puzzle.

The BSC Messaging Exercise:
This is a problem some of us developed at
Boston Software Craftsmanship
to experiment with different design styles. It tries to tackle some
realistic integration problems, while faking out enough complexity to be
doable in under an hour.

James Shore’s Architectural Design Challenge:
A conscious attempt to invent a tiny toy problem that’s still a useful
tool for thinking about software architecture.

Uncle Bob’s Payroll Example: I don’t have a great link for this one.
Agile Software Development: Principles, Patterns, and Practices,
by Robert C. Martin, includes an extended example of a small payroll
system. He details a bunch of use cases for it, and describes how he
would implement it, which means there’s a great opportunity to try it
for yourself and then compare.

The AuctionSniper example from GOOS:
Growing Object-Oriented Software, Guided by Tests
is one of my favorite programming books, and contains another extended
code example. I haven’t tried doing my own implementation of this one,
but I bet it’d be a great exercise.

Moar Lists

This isn’t the only list of toy projects! There are a bunch of others out
there that are similar in spirit. A few I know of:

The Ruby Quiz: Speaking of Ruby, the Ruby
Quiz has a big list of small programming problems. Mostly smaller than
the ones I tend to look for, but good if you’re learning the language.
(And some of them aren’t that small!)

Code Katas: These are short coding exercises
intended to be done repeatedly as a form of deliberate practice. The
ones on that site are good, but it’s also a good term to Google for if
you’re looking for more exercises. Despite the
somewhat problematic name, they’re a
pretty useful learning technique.

Project Euler: This is a huge list of
small programming problems, that become progressively more complex. The
problems tend to be very mathy, and emphasize exactly the set of skills
that my own list underemphasizes. Good stuff!

Finally…

Many thanks to Danielle Sucher for
pointing out
that my Twitter spam on this topic yesterday would make for a good blog
post, and to Amy Hanlon for bringing it up in the
first place. This was apparently just the encouragement I needed to start
blogging again!

So, how about you? Do you have any favorite programming problems you use
for practice? (Oh yeah, I’m also experimenting with having comments here.)

A week and change after I intended to, I’m ready to write up some notes on
the Haskell coding challenge I started a little while back. Since I don’t
have a lot of specific points in mind, I’m going to try to do this in a
sort of Agile-retrospective-for-one style.

Background

So Justin Searls wrote a great post the other day on
The Failures of “Intro to TDD”,
and then Bob Martin wrote
a great counterpoint to it.
Both the posts are well worth reading, though these days I find that the
latter of the two is closer to my own practice. But what I really want to
talk about is Angela Harms’s response, calling attention to the way Bob
Martin’s article is shaped by working in languages with strong refactoring
tools:

In the last year or two, I’ve been pushing myself to limit the length of
my TDD cycles. In particular, I’ve been trying to spend no more than five
minutes writing a test, making it pass, or refactoring from one passing
state to another. I went in skeptical, despite having heard this advice in
one form or another from several people I respect, but I’ve been
astonished by how much it’s helped me improve my work.