Code Kata One - Supermarket Pricing

This kata arose from some discussions we’ve been having at the DFW Practioners meetings. The problem domain is something seemingly simple: pricing goods at supermarkets.

Some things in supermarkets have simple prices: this can of beans costs $0.65. Other things have more complex prices. For example:

• three for a dollar (so what’s the price if I buy 4, or 5?)
• $1.99/pound (so what does 4 ounces cost?)
• buy two, get one free (so does the third item have a price?)

This kata involves no coding. The exercise is to experiment with various models for representing money and prices that are flexible enough to deal with these (and other) pricing schemes, and at the same time are generally usable (at the checkout, for stock management, order entry, and so on). Spend time considering issues such as:

• does fractional money exist?
• when (if ever) does rounding take place?
• how do you keep an audit trail of pricing decisions (and do you need to)?
• are costs and prices the same class of thing?
• if a shelf of 100 cans is priced using "buy two, get one free", how do you value the stock?

This is an ideal shower-time kata, but be careful. Some of the problems are more subtle than they first appear. I suggest that it might take a couple of weeks worth of showers to exhaust the main alternatives.

Goal

The goal of this kata is to practice a looser style of experimental modelling. Look for as many different ways of handling the issues as possible. Consider the various tradeoffs of each. What techniques use best for exploring these models? For recording them? How can you validate a model is reasonable?

What’s a Code Kata?

As a group, software developers don’t practice enough. Most of our learning takes place on the job, which means that most of our mistakes get made there as well. Other creative professions practice: artists carry a sketchpad, musicians play technical pieces, poets constantly rewrite works. In karate, where the aim is to learn to spar or fight, most of a student’s time is spent learning and refining basic moves. The more formal of these exercises are called kata.

To help developers get the same benefits from practicing, we’re putting together a series of code kata: simple, artificial exercises which let us experiment and learn without the pressure of a production environment. Our suggestions for doing the kata are:

• find a place and time where you won’t be interrupted
• focus on the essential elements of the kata
• remember to look for feedback for every major decision
• if it helps, keep a journal of your progress
• have discussion groups with other developers, but try to have completed the kata first

There are no right or wrong answers in these kata: the benefit comes from the process, not from the result.

Comments

[collect_the_blue]

I'm trying to teach myself how to program and I just happened to stumble onto your site while I was looking for ways to practice programming. There doesn't seem to be very much out there on the subject. I have a lot of friends that are athletes, artists, musicians, and chess players and I realized that if I want to become a better programmer, I'm going to have to practice much as they do to excel in their fields. I really appreciate this resource, thank you very much.

[Yeon-Seong Sin]

thank you for good info.

[Johannes Brodwall]

Despite the fact that this is not a kata that involves coding, I have found it to be an interesting jumping off point for code dojos (think mob programming with TDD). Implementing discounting rules test-first is very satisfying because each passing test is a product owner requirement implemented. Thanks for an inspiring kata. :-)

[Johnny Kwan]

Ultimately, the pricing model chosen depends on the requirements. I don't have any background in retail, but I would think that it's the accounting requirements for tracking item profitability that drive this decision. Since a retail company's accounting requirements change as it becomes more sophisticated with marketing analysis, the real focus of this kata should be practicing with refactoring between different models, so that the programmer learns how to refactor, and what makes a design easily refactorable.

Great concept with this site and with Pragmatic Programmers and Pragmatic Studio. Now to find a dojo in the Boston area...

[Jose M Beas]

Do you have the solutions? I'm working on this kata hard and incrementally (introducing new requirements and for each new example, I write some new tests) but would like to know which are good solutions and which are not, like if I was reading Fowler's "Analysis Patterns".

Thanks a lot for these superb exercises.

[Dave Thomas]

Jose:

I'm not sure there are solutions per se. I feel that the benefit in this kata is thinking about the issues, rather than arriving at some code. I actually started work on a book for these kata, then put it on hold because I was concerned it would be viewed as "do things this way."

[Jose M Beas]

Thanks Dave,

Although I like the idea of a book with all the katas, I was not thinking in "the solution" but in "the solutions" for this particular kata (the supermarket prices). And I suggested an approach like Fowler's in "Analysis Patterns".

For example, we can start explaining the simplest design we can use to model a price for "this can of beans costs $0.65" (an "Article" has a simple attribute "price" of type "Money"?). Then we can explain how the design must change in order to model more complex prices like "three for a dollar" (probably you can use any GoF design pattern, maybe a Strategy?). And so on...

I know it is not easy but it would be a very valuable learning piece. (For me at least). I suggest the approach made in "Analysis Patterns" because I love the way Fowler explains how the changes (and which changes) in the requirements make us change the model. For example, if I have to model an organization structure now I have a reference to model "my own solution" but being aware of how new requirements can affect my model.

As a software analyst, I'd prefer to learn by practicing in a lab instead of making mistakes at work. Although I'm not fear of making mistakes, I just want to minimize the negative impact of my learning on others.

Thanks again,
JMB

[Jeff Rockel]

Good comments but as an "old" C programmer, I didn't think in terms of "an 'Article' has a simple attribute 'price' of type 'Money'". I also have no idea what a "GoF" is. ("Gang of Four"? So says Wikipedia.) My point is there are points of beginning that are different for each of us. I look forward to Kata #2.