Agile Zone is brought to you in partnership with:

Gil Zilberfeld has been in software since childhood, writing BASIC programs on his trusty Sinclair ZX81. With more than twenty years of developing commercial software, he has vast experience in software methodology and practices. Gil is an agile consultant, applying agile principles over the last decade. From automated testing to exploratory testing, design practices to team collaboration, scrum to kanban, and lean startup methods – he’s done it all. He is still learning from his successes and failures. Gil speaks frequently in international conferences about unit testing, TDD, agile practices and communication. He is the author of "Everyday Unit Testing", blogs at http://www.gilzilberfeld.com and in his spare time he shoots zombies, for fun. Gil is a DZone MVB and is not an employee of DZone and has posted 76 posts at DZone. You can read more from them at their website. View Full User Profile

Not A Problem

07.09.2013
| 1762 views |
  • submit to reddit

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.

Published at DZone with permission of Gil Zilberfeld, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)