❝ I want give users access to their own data, do I let them have it with the lot? Or offer a fat-free alternative?
Ambition
Last year I finished up running a BBQ for a local sports club. Four years of Saturday morning planning and preparation. [0] Wake up, pack my kit. throw it in the car and drive to the local oval oval. Then ready myself and a volunteer team to prepare and cook. And cook we did. From early in the morning we cooked Hamburgers, plain and with the lot. If customers didn’t want a Hamburger then it was hand-made sausages from a great local butcher. We worked like dogs from nine in the morning till two o’clock in the afternoon. From the cool mornings of spring through the heat of summer. Preparing, cooking, selling, cleaning up. Repeating this pattern until we either ran out of food or time. Effort paid off and we made more money than we spent. [1]
The next year we got a bit more ambitious. Enthusiastic after a long break we decided to add a raft of new additions to the menu. Bacon and eggs until we run out. Usually before 10 o’clock. Hamburgers with the lot would now include onion, bacon, cheese, lettuce, tomato. You could even order pineapple and beetroot. Instead of plain sausages you could choose from spicy Italian, beef or plain. Nothing was too much trouble.
Complication
Then an unexpected additional constraint. We moved venues. Changed days from Saturday to Friday. Now instead of mornings we had twilight. Instead of feeding people who skipped breakfast, we are feeding people coming home from work, hungry.
Nightmare
Right about then we, I should have realised it was not going to work. We created our own twilight zone. A nightmare combination of heat, fading daylight and hungry crowds. I’m pretty sure if Chef Gordon Ramsey [2] was to pop in, it would have gone something like this ...
GORDON So Peter. I finally got some of those sausages. Great stuff. Local produce, plenty of onion, selection of sauces. Then I had a Hamburger with the lot. Well cooked. Cheese under the meat. Good meat. Lettuce, onion, eggs. I noticed you’d even put beetroot on the menu.
PETER We are working our legs off but everyone wants their food now! (So far so good. He didn’t order the pineapple? Hope he didn’t notice the wait. It’s an awfully long queue!)
GORDON These bl@@#! people haven’t been served? Why? Customers, customers, customers. Service is too slow. You’re loosing customers to the F@$!#% re-heated dim sims and Hot Dogs over there. Talk about going to the dogs ...
PETER We’re being slammed ... (We are pro’s. Everything under control. Too many customers at once)
GORDON Why did I wait a bl@@#! hour to get a F@%$#! feed? It’s too complicated. Simplify the F@%$#! menu. Reduce the load on the cooks and service staff. What do you think?
PETER Ahhh, ‟Yes Chef” ... (Oh he noticed)
What just happened?
We made what customers wanted. The price was right. We made a good profit. The consumables, high quality. But I made a classic mistake. The overly complicated menu with it’s combinations and additions was not workable. The front-end was stressed taking weird orders. The back-end cooks could not keep up with demand. Hungry customers waited in winding queues. Add to this a change in venue and increased demand. Chaos reigned. The menu was too complicated. Unsustainable.
GORDON Now what I suggest is, stream-line the menu; cut the extra Hamburger additions; let the customers have the cheese and onions. But for F@%$#! sake, get rid of the beetroot and pineapple.
And so we did. As soon as we simplified the menu, the stress disappeared. The simplified ordering made it easier. We still had the crowds. We sold even more, made more money and sold out early.
Simplify
What has this got to do with technology, software and making product? Well, I’ve been doing some research for a new product I’m working on. I want users to have the power of access to their data. But before today, I fell into the complexity trap I just described above. I’d forgotten the hard earned lessons of simplicity.
Make something users want
Maybe it was because it was dinner time and the smell of the Sunday roast bought back memories of those sausages and hamburgers on the BBQ. A more likely reason was the article I happened to be reading at the time by the ‟Gordon Ramsey of the programming world”, Douglas Crockford. The paper compared the merits of encoding data in JSON to XML. [3] Reading the article I realised my stupidity. I could still give users access to their data. But without spending the extra three months working on a ‟ground breaking” standard to achieve the same aim. Earlier in the day I had also read how the Microformat design process really works. [4] The only way standards succeed in the open source world is through a consultation process. Preferably with users who know through experience what problems they face. How can you solve users problems if users themselves are left out? Skip a step. Make a mistake through lack of consultation or insight and failure will follow. Worse still, you might be trying to solve a problem that does not exist. So to I’ll repeat it again. If you want to build a standard the right way make sure you at least look at the recipe of successful standards. A recipe something like:
❝ problem statement → research → discussion → proposal → draft → standard
The standards cooking process takes time, effort and participation. [5] But the outcome is worth it. But I don’t have the time to build a standard. I don’t even know if users really want it. Once I realised I was biting off a bigger problem than I could solve. I quickly simplified my approach. Why not kick out the complicated XML, DTD’s and schema’s? Why not give users access to their data without the cruft?
GORDON So Peter. I’ve been away 3 months now. How’s the choice of technology going? Has it worked? Will it move your product closer to demo?
PETER We’ve stuck with the much simpler JSON instead of the complicated XML schema. The users will be happier because they get the data they want without the extra fat. I’m happier because it means I can get on with building the product instead trying to build a standard nobody will understand, use or want.
GORDON Well that’s gone down well. Simplifying the technology means it’s lighter, with a faster development time. Customers still get to edit their data. I’m really impressed with the flexibility in thinking. Developers can use JSON libraries with lots of other languages allowing them to build their own data processing tools. F@%$#! me. I think it’s the smartest choice because, ‟While there are transformations which allow XML to express these structures, JSON expresses them directly!” [6]
So I chose the ‟Fat-free” technology alternative. JSON instead of XML. Giving users direct access to their data not some overly complicated format.
References
[0] I twittered about my last day. Looking back it was a lot of work: ‟After three years, 22 meets per year, I’ve sourced, moved, cooked (along with others) approximately 660Kg snags (sausages), 3,300 hamburgers, 3960 buns, 10,560 slices of bread, 132 Kg bacon, 42 tins of beetroot, 132 Kg of onions, 3,200 slices of cheese, 44 lettuces, 66 Kg of tomatoes, 70 litres of tomato sauce and approximately 2000 eggs. It’s getting a bit rough. I’ve only missed 2 meets in 66.”
- http://twitter.com/bootload/statuses/9910271
[1] The idea behind doing this was simple. With some resources, a bit of effort make something and sell it to people and see what happens. I made a lot of mistakes. Had some success.
[2] It’s interesting watching the slew of Ramsey shows on TV. It shows the step up required from technician to entrepreneur.
[3] json.org, Doug Crockford, ‟JSON: The Fat-Free Alternative to XML”, [Last Accessed: Wednesday 14th May, 2008]
- http://www.json.org/fatfree.html
[4] Microformats.org, ‟So you wanna develop a new microformat?” [Accessed Wednesday 14 May 2008]
- http://microformats.org/wiki/process
[5] Microformats.org, ‟So you wanna develop a new microformat?”, Iterate, et.,al.
- http://microformats.org/wiki/process#Iterate
[6] This is great quote lifted from the ‟JSON: The Fat-Free Alternative to XML”. There is a postscript. I posted the article to HackerNews and had a nice discussion on the merits of JSON vs XML.
- http://news.ycombinator.com/item?id=187124
A couple of days later this article, ‟XML: The Angle Bracket Tax” at Coding Horror appeared. No ‟angle bracket tax”,
- http://www.codinghorror.com/blog/archives/001114.html
