Is it me or the company I work for?

[s0c0]

Our development department at company XYZ constantly releases bugs, some of these bugs are major and result in loss of money, loss of customers, and for me a demoralizing blow my confidence.  I believe its because this company values speedy releases of features over slower but more quality releases.  I've been working there for a year and we are on our 5th beta tester since I started, there are no guidelines given from management on how the Q/A process should be done, no mandates for test cases let a lone lists of what to test.  This to me shows a lack of commitment to the Q/A process.  Everything is now now now and guess what we just had a major bug because everything was now now now and we had to stay there all night last night cleaning up the mess.

 

Is this the reality of development or this management bass ackwards?

Am I posting this because I am just young and don't understand business?

Is this post a reflection of my lack of experience?

Is this post a reflection of my bitchy attitude?

 

Please advise. 

[neylitalo]

Is this the reality of development or this management bass ackwards?

 

A combination thereof. It's very difficult to make any respectable application bug-free, and your management knows that. There are plenty of companies and organizations that release software with bugs, because there is simply no way to be sure that it's completely bug-free. However, it seems that your management is also taking things a bit too far, and not putting nearly enough QA effort into it, especially if these bugs are so monumental as to cause customers to stop using the product. And, as you said, the lack of guidelines and requirements of tests to be made are indicative of "a lack of commitment to the Q/A process." It seems that the management, in this case, simply doesn't understand the importance of testing the product.

[dbrimlow]

It is without question management's fault. There should be a proper "corporate structure" of responsibility in place to ensure quality control:

 

Manager/Director, Supervisor, Team Leader, Coders

 

Manager/Director instructs the Supervisor of deadlines and requirements, ultimately signs off on the project and when completed reports to the other Managers/Directors.

 

Supervisor instructs the team leader of what is required, oversees the project's overall progress, provides specific guidelines to the team leader and, when necessary, resources needed to move the project along.

 

Team Leader as well as coding, coordinates the other coders - assigning who does what, checks the progress daily, chairs a weekly meeting to determine potential trouble spots and brainstorm any troubleshooting needed.

 

When it is all about "now, now, now", it is more important (and ultimately saves time, stress and hassles later), if the coders communicate at least weekly, and put aside at least a few hours a week to test and help debug each other.

 

Nothing kills my progress more than rushing. When under such stress, I know I personally take quick shortcuts (just to get it working "for now") that I intend to fix later on when I have a little time ... but ultimately I never find the time and it all just piles up until those little quickie shortcuts become a huge integrated mess that bleeds into everything else and requires re-writing nearly everything over again.