This month's T-SQL Tuesday is being hosted by Steve Jones. The topic this time is summarized as: "What issues have you had in interacting with the business to get your job done?"

Over the past 13 years, I've worked primarily on Software as a Service (SaaS) applications. A good portion of my day-to-day grind involved improving or pre-empting scale, but the next largest component of my job involved new feature development. One of the hardest parts of new feature development, at least from the development team standpoint, is knowing when to push back. Everyone loves new features, but managers – particularly product managers where I've worked – have a real hard time with any type of cost / benefit analysis of said features. They often forget that development costs time and money, and can steal opportunity cost from other development.

Early on in my career, I learned a very important formula, which I'll express here in pseudo-T-SQL (don't try to run this, it won't compile):

SELECT TOP (2) [x] FROM
(
  SELECT [x] = 'Fast'  
  UNION SELECT 'Good'  
  UNION SELECT 'Cheap' 
) ORDER BY @Priority;

Basically, for any substantial chunk of development work, you have choices between Fast, Good and Cheap, but you must only pick two – the holy trinity, as I like to call it, is very rarely attainable.

One thing common to most of the product managers impacting my career is that they can be quite horrible at building proper requirements. Sure, they can build a wireframe or a bullet list, but they seem either unwilling or unable to formulate clear, concise requirements that a developer can respond to with accurate estimates. The requirements our development team would typically receive would have far more questions than answers, and the back-and-forth would continue through much of the development phase. Push back? Of course. But sometimes no amount of push back can fix stubborn, inadequate, or whatever the problem on the other end might have been that week. So we'd have to develop blindly, based on assumptions that were usually good (since we understood the business) but could often be wrong – in a very "do-that-over-again" way.

An even bigger problem that comes of this is setting unrealistic expectations and committing the development team to failure before they even begin. When a product manager doesn't fully understand the ramifications of his/her requirements (and the effort needed to fulfill them), then goes off and tells the sales team that feature x will be ready on date y, guess what the sales team is going to start telling their hottest leads? Time and time again we would fall into this trap, and either miss deadlines, or ship inferior or incomplete features, and sometimes both. We couldn't get it through the sales folks' heads that they should under-promise and over-deliver, not the opposite.

Some companies have it right, and don't hit these issues. I suspect they have technical enough folks in the appropriate departments such that they can work together, help each other, and learn from each others' mistakes.