There certainly can be value in a prototype/demo. The question is whether that value is greater than what could be achieved by instead building a thin slice of functionality “for real.” In the anecdote I use in the post, we might have discovered the same thing with a prototype, but we would have then had a lot of code to throw away by the time the prototype could have been complete enough to discover it. Because we were developing the real product, only incrementally, we had very little that was actually thrown away.

In my mind there is no quantifiably right answer to how much should you prototype vs. digging into the real product. An agile/lean mindset tends to tell me that prototyping should be as minimal as possible. That said, recovering from problems when you are building the real product can be risky, especially if you do not trust your design/architecture to be resilient to those kinds of changes.

My own preferred tactic would be to do whiteboard or paper prototyping of key features before green-lighting the project. Then, just in time, do similar paper prototypes of the features when defining acceptance criteria. That said, every project/product is different.

I do not think that our most sacred responsibility is to make technology make sense to the non-technical. It is to make technology that is of value to users. That the users (technical or non-technical as they may be) must be able to understand it to get value is key, but is still corollary to the main goal. In other words, users don’t have to understand TCP/IP to use their web browser.

That said, a team (including stakeholders) will fail if they cannot communicate. And in places where I have worked, this has been a key aspect of the interview process. In fact, there is usually an entire session with the explicit goal of evaluating “soft skills” even for the most technical of resources.

So… who recommends working on communication skills? Certainly I do. And I think that is one of the precepts of a lot of the camp that was saying the only way to save your technical job is to learn (and be able to communicate to) the business.

I read the CodeBetter post this morning, and I was thinking that one of the aspects of Agile that the author ignored almost completely was communication.

We love to talk about technical risk until we are blue in the face. I wonder how often failure to communicate is masquerading as “technical risk”.

“We don’t know what we don’t know” seems to be a problem endemic to software development. Sometimes it kills projects, others it simply makes them late or arrive with less than expected functionality.

Many people strongly advocate prototyping the high risk pieces of your architecture early on in a release. I think this is just good engineering practice. Who recommends working on your communication skills?

I am almost constantly surprised at my capacity to leave my wife looking at me with a strange and distant expression when the conversation turns technical (always my fault). Obviously we are capable of understanding each other. We’ve been in a relationship for over 7 years. We can clearly express our wants and needs one to another.

Why does technology entering the picture constantly befuddle conversation both at work and at home? It seems like there is a missing skill in the technical trades, how to make technology make sense to the non technical. Shouldn’t this (not prototyping or whatever other engineering hoopla) be our most sacred responsibility and central job function?