This month's T-SQL Tuesday is being hosted by Steve Jones (@way0utwest) over at SQLServerCentral.  For some history on T-SQL Tuesday, see Adam Machanic's posts here and here.  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.  I'll share a couple of stories to help illustrate this problem.

Outsourcing

A lot of companies outsource.  A lot of companies outsource and succeed.  But you have to understand the pros and cons of outsourcing to come out on the good end.  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.  In various iterations and under different technical managers, we went with outsourcing work to a prominent firm in Hybderabad.  Sometimes they fulfilled the "Fast" and "Cheap" buckets; sometimes they only fulfilled the latter.  We found that those engagements were much better for Quality Assurance, testing, data entry, and other rote tasks. 

A big problem was that they could only seem to perform very specific and well-laid-out tasks; for anything that required creativity or independent thought, the time we spent either providing further instruction or simply taking what they built and re-working it ended being a wash (or, quite often, worse).  An even bigger problem was that it took us several iterations to learn this valuable lesson.  Now, I'm not trying to generalize or scare you away from outsourcing at all; just sharing my experience with this particular firm, and with a series of managers who kept expecting to achieve the holy trinity.

Outsourcing has worked quite well for a lot of firms, and even for my previous employer, it worked quite well for certain tasks.  But for high-profile development, it just simply didn't measure up.  The alternative didn't always work out either; hiring quality developers, even in a horrible economy, can be tedious and never-ending – and takes even more of the existing developers' dwindling resources.  And by the time you know you need this (see below), it can often be too late.  On multiple occasions, we spent months trying to find the right developer or junior DBA, and in a few cases we actually gave up and just kept trudging away, short-handed.

Requirements

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.

Conclusions

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.