To subscribe to my feed, add the following Url:  http://feeds.feedburner.com/jeffreypalermo.

Kevin Hurwitz and I talk at length about pain-driven development.  For those who don’t know, Kevin is my lead architect and .Net Practice Manager at Headspring Systems, and we’ve worked together since mid-2006.  We both have the same mindset about PDD.  If we are motivated to put time into changing some aspect of the software, it has to be related to one or more areas of pain.  For instance, if the build is taking too long, we might look for ways to speed up the build.  If a particular interface has too many responsibilities, it may annoy us enough to break it up. 

Now, we do have a low threshold for pain.  We expect our software configuration management to be frictionless and go completely smoothly, including automatic database migrations; therefore, pain points that pop up are obvious, and we tend to kill the pain by fixing the source very quickly.

The point of this post is to think of pain reduction as ROI.  In business, we might spend money on software for some expected return on investment.  While working with the software, we also have returns on investment, but in the form of productivity.  Pain kills productivity.  Over time, we might learn to live with pain through parts of the process by taking a constant does of <insert painkiller here/>, but that only hides the pain.  It doesn’t cure it. 

Pain-driven development is a mindset where developers react intensely to pain and solve it so that it goes away once and for all.  PDD practitioners don’t just cover up the pain.  We eradicate it.  PDD leads to a completely frictionless software process that is a joy to experience.

Note:  I’m not advocating another XDD acronym, but I wanted to share our mindset.