Last few days have been really busy for me, nevertheless even in such circumstances I still find some time to read up something - my latest lecture is Eric Ries’es "The Lean Startup" (http://www.amazon.com/The-Lean-Startup-Entrepreneurs-ebook/dp/B004J4XGN6/ref=sr_1_1?s=digital-text&ie=UTF8&qid=1376830687&sr=1-1&keywords=lean+startup). Book seems to be totally awesome (I’m still in the middle of it so can’t tell for sure), but there’s already something I’d like to write about: Genchi Gembutsu.

This Japanese statement means "Go and see for yourself". It’s considered as one of the pillars in "The Toyota Way" - collection of principles that has boosted Toyota’s production system. If you heard about Kanban, you should already know what I’m writing about. If not, get yourself up-to-date ASAP :)

Back to Genchi Gembutsu - it mainly refers to the importance of direct communication and cooperation with clients and users of what’s being developed. It’s about:

  • experiencing the scenarios that are being discussed

  • prototyping “in the field”

  • understanding the constraints and key success factors by learning the everyday activities product-in-progress will aid with

Some call it - Get out of the building” rule. I totally agree with all of that - these are clearly words of wisdom and they should be applied as widely as possible. But based on my recent experience I’d also extend their meaning:


  1. If you’re about to work using the technology / platform you have no prior experience with - start with PoC / go evolutionary. Don’t pretend you can plan it / design it. Having “remote experts” who will make “an estimation” is a waste of time. Put your actual hands on that thing!

  2. Technology can’t be learned in 30 minutes. If you’re making a 2 table (screen / page / queue / whatever)-big demo, you can usually easily create it with a knowledge gained by reading a tutorial on the web. But this doesn’t mean you can do the same with an enterprise-ready solution - it requires practical experience, gained by personally using given technology.

  3. Analogy is bullshit. PL/I developers can’t jump into .NET world “just-like-that” and perform like .NETters, even if they’ve spend 10 years on software development. They need to have hands on experience with the platform they’re going to use (in this case - .NET).

  4. Don’t forget about maintenance - your tech ops are your users as well. Find out personally if the final product will or will not be maintainable at all - sit with them side-by-side and go at least through typical and most burdensome scenarios.

To summarize - “go and see for yourself” - all the "official Point of View presentations" are useful only as a starting point for further read that will prepare you to start practicing. Don’t try to be "an expert" who "doesn’t know the details, but knows how to google them"