This morning I got hooked to a new band. I’ve heard the band before and I’ve had others praise the band. It was only this morning, when I stumbled upon a particular song by the band and started enjoying it. After that I went and explore the whole album and other albums. Its been 8 hours and I’ve been tripping on their music.

To think about it, software is kind of same. Usually its one sticky (killer) feature that gets people hooked to a new software. Once they experience that feature, without much push, they discover all kinds of interesting features and innovative ways to use them.

As someone building a new product how do you figure out what that feature would be?

I’m aware of 2 approaches that have worked in the past:

• Agile/Lean-start-up philosophy: Build sketches (quick and dirty versions) of a few features, put it in the hands of real users and see what might click.
• Open Source/Eat your own dog food philosophy: Build something that addresses your personal itch and see if others have the same itch.

What other approaches have you seen work?

At the Agile 2009 conference I attended a workshop by Alro Belshee and Jim Shores on “Slow and Brittle: Replacing End to End Tests“. In this workshop they presented a couple of cases where End-to-End checking (testing) became a huge issues as the tests became slow, brittle and expensive. While I agree with them and have seen cases of checks (not just end-to-end checks) becoming a maintenance nightmare. Many times, checks create an illusion of safety, but really don’t add much value.

While some of it can be attributed to the poor scope/focus selection for checking (end-to-end or unit), I also think a lot has to do with poor skills, lack of understanding and rigid/flawed organizational structures.

During the workshop, the group I participated in, came up with following points as reasons why people write end-to-end checks:

• Document the interaction and intent
• Being Inclusive: Testers and Programmers can collaborate
• Scaffolding
  • Good starting point for dealing with legacy code
  • Early win: Easy to show people how to automate checking and get them started
  • Good starting point to learn/explore more about the system
• Freedom and Confidence to Refactor code
• Ease: (sometimes they are very easy to create)
• Highlight Design Problems: If you see duplication in your tests, sometimes it could mean poor design.

I know other teams had several other interesting points. So the question is what other approach can you use to do away with end-to-end checking?

One of my proposals was to look more serious at “Eating your own dog food“. I also very much digg the idea about “Self-learning and Self-testing systems”.