When is a problem not a problem?

• When there is a solution
• When there seems to be a solution.

If a problem wasn’t solved, we’d  see all kinds of talks around it, ideas of solutions, discussions (wars) about different possible resolutions. Once we have a solution, bingo! The problem went away. If you apply Cynefin to this, we move from the complex to the complicated (or even simple) domain. We might not have a best practice for resolving the situation, but a good one will do.

Let’s take an example of a topic that was all the rage years ago, until it was resolved by a good enough solution: Object relational mappers. For years there have been discussions about how to do this correctly. Then came Hybernate, and after a few cycles of porting and development the war was over. The how-tos were published and there was no more discussion, because the problem was solved. Think about it: when did you last read a new book, or saw a session in a conference, or even seen a blog about ORM, that is not relegated to a how-to using a tool?

Does the solution mean no more problems, though? Or have we over-simplified the question?

Another example: unit testing. It’s similar to the ORM story. It was all the rage for years, now nobody talks about. I mean, you’ll see the occasional TDD talk (like mine at Agile Testing Days), but no talks in sight in either development or agile tracks anywhere. You don’t hear any news about unit testing, because frankly hasn’t been any since JUnit.

Search online for “unit testing in .Net”, and you’ll get these topics first:

Step right up folks! All you ever needed to know about unit testing is there: Writing tests, tools for testing and mocking, how-tos. Once the answer is “here, use this tool”, there’s no need for discussion anymore!

But that’s not the situation, is it? If it was everyone would be using these tools. Yet how many people actually write tests? Industry standards talk about ~20%.

Unit testing seems like a solved problem, and that’s why there’s no buzz around it. It’s not ATDD or kanban or continuous delivery, where it seems there’s so much to explore and learn. It’s just plain, boring tools.

“Gil, you have a marketing problem, so you’re whining”.

I used to do that, I’m over that now.

I do know that unit testing tools are part of the solution, and the rest (which adds up to 80-90%) is things you learn by practicing. Long time practitioners know this, too.

Next time you have a question, the simple solution might looks very valuable. It may look like it solves all your problems. You’ll be surprised how many times it doesn’t.