QA

A problem I've come across more than once is scheduling of QA during the initial development cycle.

It's not that I don't think QA isn't useful - QA generally will catch many, many things that we developers skim across in an effort to get from one test condition to the next.

Honestly, I'm not even saying that if QA is scheduled, they shouldn't be testing; hey, go for it.  The thing is, I don't want to hear anything QA has to say until after we, the developers, have been over the first pass.  That is to say, bugs in pre-alpha code are not only to be expected, but generally just an artifact of yet-to-be-implemented stuff.

The fact is, though, if you have QA scheduled well before the first pass is over - say your manager thinks it might be "streamlined" to break the project into phases, each of which is QA'd after your team has had at it - you should push back hard.  QA will complain about bugs, and your team will be expected to break off resources to deal with them.  This will cripple you as you strive to meet your timeline for an Alpha RC.

This will be difficult.  Your project managers are pressured to deliver projects ahead of time; they want to earn a reputation for being efficient; they want brownie points from the next man up the ladder, who has the same incentives as he.  Your job, in this case, is to explain carefully why this model will not work - that preemptive QA is, at best, a needless distraction - and at worst, a labor vampire.  Explain that it's better to actually schedule out time, post-alpha, for the QA <-> Dev cycle to occur.  This, along with an honest assessment of the normal expected environmental difficulties, and an allowance for unforseen events*,  makes the initial timeline realistic - and any overtime inevitably result in the coveted early delivery.

Now, I understand that it's not always possible to get the deadline you're after.  We've all been in a situation where the expected completion date is reported as March, and the PM, or their boss, or the client demands something earlier, say November.


First, as a freelancer, I never stood for this; the client can demand any date she wants, but the site described by the resultant SLA would be far less than the client wanted.  When the client noticed this (as they usually would), I would explain that the more complete site carries with it the deadline I had originally proposed, and that if you want it sooner, you will get less.

Second, if a PM agrees to a date that is significantly earlier than the dev team estimates, that PM should not be allowed to retain their position: a manager who flatly ignores the advice of their primary resource is, failing any better word, incompetent.

Third, if you find you are a developer in a position such as this, craigslist has many, many open positions.  Look into them.