Why do we write code? At one level, we’re trying to solve some particular problem, to add some kind of value to the world. But often there are also secondary objectives: the code has to solve the problem, and it also has to be fast, or easy to maintain, or extend, or whatever. So let’s look at that.

Back to the supermarket. This week, we’ll implement the code for a checkout system that handles pricing schemes such as “apples cost 50 cents, three apples cost $1.30.”

If we’re programming business applications in a language such as Java or C#, we’re used to constructing and using classes to manipulate our business objects. Is this always the right way to go, or would a less formal approach serves us well sometimes?

Just because we need to sort something doesn’t necessarily mean we need to use a conventional sorting algorithm.

A GedankenKata this week: no code needed (although writing short prototypes might help you come to a conclusion).

Counting lines of code in Java source is not quite as simple as it seems.

Trigrams can be used to mutate text into new, surreal, forms. But what heuristics do we apply to get a reasonable result?

Think of binary numbers: sequences of 0’s and 1’s. How many n-digit binary numbers are there that don’t have two adjacent 1 bits? For example, here are the three-digit numbers:

000 001 010 011 100 101 110 111

Five of the possible eight combinations meet the criteria

What is the number for sequences of length 4, 5, 10, n?

Having worked out the pattern, there’s a second part to the question: can you prove why the relationship exists?

How can you tame a wild (and changing) set of business rules?

The rules that specify the overall processing of an order can be complex too, particularly as they often involve waiting around for things to happen.