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.

Indeed, as I write this, I see that Microsoft, Intel, and AMD have jointly announced a new partnership to help prevent buffer overflows using hardware controls. In other words, the software quality problem has gotten so bad that the hardware guys are trying to solve it, too.

When it comes to the maintenance and extension of legacy code, and clearing the organizational hurdles associated with the handover of code from one party to another, a reliance on "face to face" communication is very convenient for the first generation of developers, and a chain around the leg of every other developer and organization involved thereafter.

All physical computers are equivalent to finite state machines, due to the fact that their memory is not infinite.

A computer with 64 megs of RAM along with 8 32-bit registers has a total of 536871168 bits of memory. Hence, such a machine can take on a finite number of states, namely: 2^536871168 states.

It's a collossal number of states, but the fact is, all computers with finite memory are finite state machines.

Perhaps you already encountered the situation - you read a bit about some less-mainstreamed language, and ask yourself : How in the world do they write an "hello world" with that?

This is where i want APLC to help. I want to collect implementations in various "languages", for a few trivial algorythms (bubblesort etc) and applications.
I call it an practical language comparison. That said, the "languages" compared should be actual language implementations, for actual platforms - rather "GCC 3.0.4 for Linux x86 using KDE 3.2" than "C", rather "Turbo Pascal" than "Pascal". I'll call these implementations languages from now on.

Kādu source control sistēmu Tu lieto?

Esmu gatavs izsaukt uguni fleimu uz sevi. Bet nespēju nenoturēties un nepaust savu autoritāro viedokli.

Manuprāt Python ir tāda advancēta spēļmantiņa koderiem (scripteriem). Vismaz .lv apstākļos toč.

No otras puses, Python varētu tikt dēvēta par Perl nākamo pakāpi :)

Sue me.

Jaunumi no Tantek — highpass un midpass css filtri.