A key part of Lean Manufacturing and the Toyota Production System (TPS) is the idea that you should go and see for yourself what is happening on the manufacturing floor. When striving for continuous improvement, or maybe more importantly, true understanding (which must be had before improvements can be made) of the processes and problems on the production floor there is no substitute for being in the place, directly observing the people and machine processes, and when possible, putting your hands into the production line and becoming the person that performs work on the floor.  This is also referred to as the Gemba attitude, or the attitude of being in the place that will feel the direct impact of any decisions made.

The idea is that when you are separated physically from the place of concern any information that comes to you to fuel the decision making process is going to be an abstraction of the real thing at best, and at worst, a totally inaccurate piece of information. Whether you are a marketing person talking to a focus group or a developer taking your marching orders through seven layers of intermediaries separating you from your user, you will end up making the wrong decision. You may get lucky and do the right thing once in a while, but more often than not you will find yourself somewhere down the wrong path.

My current employer is an anatomic pathology laboratory. Our lab, doctors, and medical support personnel are all located in New York, and our IT and development staff are located primarily in Florida. Already we are separated by domain expertise (our developers aren't pathologists or histotechnicians) and we compound that domain expertise gap by putting a thousand miles of geography between us. As professional developers, we all know that the domain expertise gap is hard enough to close even if you can walk into one of your users' offices and talk to him, so when you take that ability away, you have put major impediments in place to creating accurate and useful software for your customers.

To solve this problem, I have spent as much time in the lab as I can get travel budget approval for, and I try to take members of my team with me whenever I can. There is no substitute for seeing your software in use, and for seeing the problems that are either not being solved by your system, or worse, being caused by it. These are things that you absolutely must observe for yourself to understand. A conference call will not convey the information well enough. The bandwidth of face-to-face, in the moment discussions simply cannot always be replaced. Further, when you are physically separated from your customer at all times, you will never hear about certain problems that you could easily solve.

Users are notorious for creating manual workflows to reduce friction in the software they are forced to use. To the developer, it may seem like doing excel or paper processes are high-friction, but we aren't seeing these manual processes from the same perspective as those who created them. Only by walking around, seeing excel spreadsheets or post-it notes in use, and seeking to understand the reason they are being used, and the problem they solve, will you be able to gather enough information to properly create a software solution to this problem.

This past week I took one of my newer developers and a business analyst to the lab. The agenda was "walk around, talk to everyone you see, and ask a question every time you see anything but our software capturing data". From this, in just four days, we have come back with several months worth of work that we just wouldn't have known about, ever.

Another benefit of going to see for yourself is gaining not only an understanding of what your users do, but also an appreciation for the work they do. It's all too easy to become isolated behind the code window and respond to a feature request that on the surface seems stupid or trivial, and dismiss the user as "stupid". But when you go and see for yourself, and see that your users have a mountain of work in front of them that doesn't involve a computer, and are barely able to complete that work in a given day, you can understand better the friction your software and user experience choices causes every day. When your software causes friction, users will find a way not to use it. And when you don't respond to this friction because you feel it is trivial, you lose the trust relationship with your users that you need to operate effectively.

The moral of the story is that you cannot develop software in a vacuum. You must go and see for yourself. And if you can't do that, then you need a proxy to do so. The more layers of abstraction you put between you and the user the less valuable your software will be, so bridge that gap with as many straight paths as possible and seek to understand the production floor and then you will be better positioned to create quality.