Now I understand why government computer systems suffer so much at the hands of Internet-based attackers. For obvious reasons, I won't point out any specific product problems, nor modes of unsecure programming, nor personal names behind the observed behaviors. But here are some observations:

You wouldn't work on banking software without learning the industry first. If you try, you'll just make a mess of things. And if your employer demands that you try, then you'll serve yourself to go learn the industry as quickly as you can. And you have to assume that future maintainers will do the same. Otherwise, you'll just bog yourself down. You can't hope to program to the lowest common denominator. You have to build good abstractions and then build on the abstractions. Otherwise, you will cause more trouble and re-work than whatever meagre amount of good you may produce.

Software is not fire-and-forget. You don't just send in the twelfth infantry programming division and wait for the enemy to surrender. But there are people who will do the moral equivalent: hire and hope. Some mid-level manager decides that he wants to commission a system, and he has a buddy who cut his teeth writing code to support an abandoned obsolete product in the field. With no formal training and an ego the size of Montana, in comes this dude with two or three programming brain cells to rub together and suddenly people treat him like some kind of god. It all goes to his head as he puts together something which is wonderful in some ways but shoddy in many others. And good luck if he solicits requirements from end-users other than himself.

Scenario A: People will complacently use the new system until the environment changes or some underlying assumption is suddenly violated. Because the dude didn't have abstractions in place, it's not feasable to fix the system in any reasonable amount of time. People have to toss it by the wayside.

Scenario B: The low-caliber programmer from above fails to consider security, and some day some goofball decides to do something malicious. It causes havoc for a few days while people restore from backup tapes, and the goofball eventually gets caught and suffers the consequences. But now an entire division, department, or suchlike has lost a week's work and can't even trust the system they work on to be completely uncompromised.

Scenario C: Someone with a few cents worth of formal training, or the Abraham Lincoln equivalent, joins the effort. Watch out! There will be fireworks. These two people don't get along. One is in fear for his manhood the entire time, and the other is confident and secure in the certain knowledge that long years of research and study amount for something. The former might even have more knowledge of the field of interest, but he'll not dare to divulge that knowledge in the source code or anywhere else for fear of losing some misguided mighty-lingum contest. Therefore, he begins to make counterproductive demands such as "don't add abstractions" and "don't change my code". He questions every decision, and tries to find a way to make it wrong. Eventually, all competence walks away from the project, leaving only the king of an ever-shrinking hill, and the project is back to one of the other scenarios.

Scenario D: The buddy-cum-contractor decides to make the effort it takes to get along with and learn from his new collaborator without ever demanding to be right. This can't happen. Well, maybe it can, but I'll believe it when I see it.

So getting back to the core issue, computer systems are unsecure because the people who create them are not held responsible for doing a professional job. They're not held responsible because their bosses don't know how. And that's because they do not, themselves, understand how to evaluate the quality of work. If it's pretty blue, then it must be high quality. When that's the way systems are developed, it's no wonder that a handful of script kiddies wreak dread havoc on computer systems across the face of the continent.