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

[Nibir Bhuiyan]

thanx for the resource, it will help programmars very much

[szeryf]

I don't agree that the programmers don't do such exercises regularly. Every time you're faced with non-trivial problem (e.g. the above problem or "implement plans (Free, Basic, Full) that allow customers to pay for certain features and also get discounts if they pay for more time in advance"), you should first tackle it in your head and do some experimenting, before you start cranking code. If you don't, well...

BTW. this is a good question for a job interview. Of course, the candidate should not be required to produce some code, but just invent some solutions and discuss their pro's and con's.

[Tetha]

Just thinking about the book. Couldn't you collect the results of readers of your blog (which would include a possible class structure and a though process) and present them, along with a certain analysis, why this might be a good solution in a particular area and why this would be a bad idea in another area.

I think this would amend the issue that the book reads as "Do this.", because there should be a multitude of solutions easily. And I think I'd buy such a book, because exploring very different solutions to such a problem sounds highly interesting.

[John C]

One of the most "fun" parts of this solution are what happens when the cashier rings up 3 items are are $1.50 for 1 but are 3/$1.00? (Yes, I have seen this.) You need to be able to have the register identify that an customer just purchased the 3rd item so that they get the discount.

And then you need to handle the condition where they purchased 3 items then decided (for whatever reason) to have 1 item removed while the cashier is still ringing up the sale.

And what do you do when the customer wants to return an item after the sale.

Fun, fun, fun. :)

[Andy]

Great resource here!

I love the idea of kata and Code and Coffee. I hope to have something around Toronto/Canada too. I am a Business Analyst but I enjoy programming very much, especially enterprise development and integrations.

To this supermarket problem, this is what I thought before. For pricing model in every business, there seems to be no rules guiding the changes happening in pricing models. e.g. business may want to have simple price this quarter and then discounted price based on certain conditions.

I look at this problem in high level. Pricing model is a component in a trade of products or services. What composing the price of the product is a formula of conditions. Conditions can be simply added without reason or they could be triggered by something (e.g. time, other products, etc...).

So it's simply going back to the basic accounting model: Price = Fixed + Variables.

The hardest part here is the variable price. However, if we think about these variable prices are simply results of some conditions, then we could probably allow the business changing the pricing model any time in any way they want without changing the system.

Just my 2 cents.

[rush]

Well i think the main issue that affects the pricing models is the accounting and sales department of a supermarket. I think if a product is not rotating well on sales then they will make some models like "buy one and get one free" like that..just a thought.

[Ambrose]

I think about this every time I go to the supermarket, partly because of the programming aspects, and partly because my wife has me check the receipt.

"How come they're charging us full price for those three-for-two-dollar cans of beans?! We bought three!" "They're not, honey, they put the full price next to each can, then when the total reaches a multiple of three, they subtract the difference."

So, there's one approach.

[Eric Russell]

I'd like to suggest an addition to this kata: limits. While working this kata, I realized that purchase limits are frequently associated with supermarket pricing. And this raised several further issues such as how are limits associated with bogo offers and what happens when limits are reached? Does the method for validating inventory still work with limits in place?

Exploring these issues were valuable to me and may also be to others.

[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.

[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

[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]

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.

[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...

[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. :-)

[Yeon-Seong Sin]

thank you for good info.

[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.