• Focus on Rapid Delivery: No one likes to wait for food. No one likes to get cold, stale food. Food is best when its served fresh and hot. The exact same thinking applies to software. If I go to a restaurant and order for starters, main course and deserts, its stupid to expect that I’ll oder everything one-shot and accept everything delivered together. Most probably I’m going to order the starters. Once you get the starters, I’ll see it’s quantity, also taste them and then decide on the main course. And so on. From the restaurant’s point of view,
  • They don’t get nor expect all the requirements upfront.
  • They believe and embrace iterative and incremental delivery model.
  • They deliver food as and when its ready. (focus on throughput). In fact restaurants in India, serve you really fast and they want you to eat and leave as quickly as possible, so that they can server more customers. They really focus on throughput and flow.
  • They keep their customers busy (hooked in)
  • They don’t want to keep the food waiting to be served (inventory)
• Innovation: Profits and Competition are very high and hence restaurants are very innovation driven. They know only good food is not sufficient to keep customers loyal. They constantly do the following to attract repeat orders:
  • Chef’s recommendation and today’s special deals
  • Free Home Delivery
  • Improve interiors and ambience
  • Come up with appealing offers and packages
  • Evolve their menus by adding new items to their menus and food offerings. Constantly try to improve it based on most frequently ordered items
  • Heavy focus on service and customer satisfaction
  • Try to build a personal rapport with each of their customers. Make them feel special when they come.
  • Constantly look at eliminating waste.
    • If plates, spoons, knife, forks and tissues are frequently required, they store them very close to each table. So that they can avoid their movement and hence save time.
    • Try to make their order taking, processing and deliver process more efficient and less error prone (mistake proofing).
    • They divide their responsibilities into various roles like Order taking, delivering food and cleaning up the table. (Same thing might not work well in software because intrinsic knowledge is much higher)
    • The Chefs inside the kitchen learn to keep their work-area clean so that they don’t get caught up in the mess, trying to find things they need.
    • Chefs also do a lot of interesting mistake proofing to avoid confusion between ingredients
    • Restaurants watch food consumption trends and prepare (plan) their food ingredients based on those patterns. For Ex: they know on weekends, they’ll have huge demand, they plan accordingly. (avoid inventory)

We have also seen how a small, really successful restaurant starts scaling by opening franchisees and soon its brand is completely destroyed. Be aware of the scaling black-holes.

My 2 cents, based on personal experience:

• With TDD, I’m a lot more confident about my solutions. If I spot a design improvement, I can quickly jump in and fix it with confidence. When given feedback, I’m able to respond to it quickly. I feel I’m in control.
• It really helps me keep my design and code minimalistic and clean. No bells and whistles. No buy one get one free combo offers. <Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away>
• Turns out that my code is lot more easier to test. Because its designed to be testable. Lots of people argue that they will write tests after writing the code and it would be more efficient. The biggest problem I find with this approach is that the code ends up being something not readily testable. Then either I’ve to spend time making it testable or I skip testing saying its not possible or not required.
• It helps me build a safety net of executable, living, up-to-date specification for my classes and features. Its a great starting point for new team members to understand my software. Tests are a great reference point for someone who wants to use my code.
• TDD is a great teacher. It helps me listen to my code and learn from it. It forces me to pay close attention to what is happening. Its easy to spot bad things faster. Its all about feedback and visibility.
• TDD forces me to slow down and think. It encourages me to take baby-steps. Sometimes I find people are in such a hurry that they spill mess all over the place. It takes soo much more time and effort to clean up the mess they leave behind.
• My tests tend to communicate my design choices much longer after I’m gone.
• I massively reduce the amount of time I spend in the debugger or trying to manually test (monkey test) from the UI. When something breaks, I no longer need to crawl through the logs to figure out where things are going wrong. I get pin-pointed feedback.
• TDD helps me maintain focus on measurable outcome (producing software that accomplishes a concrete objective). I’m not longer drifting down ratholes.
• TDD also helps me reduce the hand-overs between developers and tests and hence the wastage introduced because of all that overhead and context switching.
• And so on…

Having said that, TDD alone is not sufficient to achieve the above. At times you need to spike/prototype things. One needs to have (or at least start focusing on building) a good knowledge of Design Principles and Patterns. Its easy to get lost, having a pair can really help.

Again I don’t want to sound dogmatic. I don’t think TDD is the only way to build great software. There are lots of great developers out there, building amazing software without TDD. However I think TDD is a much easier approach to achieve the same.