Pain v. Pleasure

Over the past several years, I have come to the realization that I think about different bodies of work in vastly different ways.  While working for i3solutions, which mainly ran fixed-price, waterfall-style projects, everything was about the specification (and rightly so).  The most important questions we asked ourselves were:


1. Does it meet the requirements as stated?
2. Did we hit all of the delivery dates?
3. Did we fulfill all of the terms of the contract?


All of which are completely valid, necessary questions.  However, focusing on these types of questions often puts blinders on software developers.  The focus becomes the pain-points, because these are the questions that must be asked for the company to avoid customer strife and legal pain.  Answering these questions positively does not always avoid the pain.  A disgusting project once went on for six months after user testing even though it met the requirements, because it didn’t actually fulfill the base need.


While working for several start-ups and on several pet projects, I thought in an almost completely different mindset.  There was always a specification and deadlines, but the focus was shifted.  We continually asked ourselves:


1. Does the product meet the actual need?
2. Is it easy and enjoyable to use?
3. Are we the best solution on the market?


Again, these are completely valid questions.  While harder to quantify than the first three, these questions are necessary because they serve as a litmus test for the project’s experience.  The focus here is on pleasure-points, for both the business and customer.  However, none of these facilitate project completion, and can lead to evil rework.  I am currently on the fourth major iteration of a pet project, all because each previous version failed one of the above questions.


So what have I learned? Most people I have worked with are violently of one philosophy or the other.  Truly dynamic creators believe in the art of balance, and that is what I want to improve in myself.  Where I can see both points clearly, the end result is better.


Have you observed these mindsets in your projects or yourself?  Have you ever worked on a project that was completely one-sided? How did it turn out?