It's too cheap to quickly pump out code, then run it by QA. You don't even need a shoddy programmer to do it...just pile too many high-priority near-deadline tasks on a good programmer. (Which is all too likely...if you build a reputation for getting things done, you'll get landed with a workload that would put a tech-support guy in a funny farm.)
Re:Uhh.. (Score:5, Insightful)
by C.Batt (715986) on Monday June 28, @02:12PM (#9552708)
(http://uberzeugung.net/)
As one of those "good" programmers with a reputation for getting things done, I must concur with your statement. In fact I've observed that the first thing cut from most project budgets, if it's even included in the first place, seems to be adequate technical QA. There's lots of emphasis on meeting business requirements/application feature goals, but very little on engineering quality under the hood.
Part of the problem is that enforcing best practices and doing techincal QA is both time consuming, and expensive, not to mention boring as all heck. So there isn't much motivation to do it. Bad, bad attitude and we're paying the price.
BINGO! (Score:4, Insightful)
by sterno (16320) on Monday June 28, @02:51PM (#9553155)
(http://www.bigbrother.net/)
The problem is that QA and development of good specifications prior to a project have a huge impact on the quality of the product that results. Having said that, QA and specifications are never seen directly by the outside world.
Most programmers I know WANT to write good code but have the odds stacked against them. They aren't given the time and resources to do the job well. When it's crunch time, security and quality are the first things to go because they are less likely to get canned over a bug than over a completely missing feature.
|