Pain-Driven Development: uncovering the motivation

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.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

5 Responses to Pain-Driven Development: uncovering the motivation

  1. Etzel says:

    I remember when we first set up BPCS software many years ago. The training and learning is such a pain, especially that bosses are impatiently waiting for some productivity in return. It kinda paid back after a few years but then a new software has to be implemented the SAP so it’s back to painful learning and training.
    Would you be interested with entrepreneurship? If you are I’d like to share this site I stumbled upon, the Young Entrepreneur Society from the http://www.YoungEntrepreneurSociety.com. It has great business stuff in the site.

  2. I can’t even count the number of times I took pain killers to resolve(it is not resolving, just hiding) the bottlenecks. Most of them related to design flaws, SCM issues and off course all impacted on the quality. Most of the time, a marginal developer(an ALT.NET terminology) will try to get his business ( software development process) to break even… not worried about ROI and profit. It is the same same place, this pain kills most of us, and in turn calls the need of better thoughts/mid set to overcome these bottlenecks.

    Let’s more people realistically think and propose some common scenarios and solutions/ways to avoid pain killers in software industry.

    Nice starting Jeff. Thanks a lot.

  3. I can’t even count the number of times I took pain killers to resolve(it is not resolving, just hiding) the bottlenecks. Most of them related to design flaws, SCM issues and off course all impacted on the quality. Most of the time, a marginal developer(an ALT.NET terminology) will try to get his business ( software development process) to break even… not worried about ROI and profit. It is the same same place, this pain kills most of us, and in turn calls the need of better thoughts/mid set to overcome these bottlenecks.

    Let’s more people realistically think and propose some common scenarios and solutions/ways to avoid pain killers in software industry.

    Nice starting Jeff. Thanks a lot.

  4. tinsley says:

    PDD I really feel it when fixing bugs in a mega module had handles business logic that changes once a week and is held together by a meandering if statements aka (masking tape). We get it out quick and it works but maintaining it stinks like . Using an agile process how do you convince the team that we need a refactor we don’t live in the past.

  5. Iain says:

    I manage a Development support team, our main job is to enable the business developers to work on there primary business development process. We ensure that servers are running securtiy is correct, builds are done, intergation test environments run smoothly, triage live/test/dev errors to enviromental or devleopment. It works well and our teams are alot more productive.

Leave a Reply