I beg to differ with Oracle's CSO

I recently heard Oracle’s Chief Security Officer Mary Ann Davidson saying that most software people are not trained to think in terms of safety, security and reliability Instead, they are wedded to a culture of "patch, patch, patch," at a cost to businesses of $59 billion.
"What if civil engineers built bridges the way developers write code?" she asked. "What would happen is that you would get the blue bridge of death appearing on your highway in the morning."
The pressure to deal with the problem of unreliable and insecure software is building, and the industry has reached a "tipping point,"
I did an informal poll recently of chief security officers on the CSO Council, and a lot of them said they really thought the industry should be regulated.
"Industries don't want to be regulated, but if you don't want to be regulated, the burden is on you to do a better job."
Davidson also hit out at the "hacking mentality," and the incidence of exploits that could cause "a million dollars worth of damage...passed around freely at conferences."
She said there was a major difference between people working in the software business and engineers who "are trained to think in terms of safety, security and reliability first."

Before I start evaluating these remarks from Ms. Anderson, it’s really interesting that this comes from Oracle, which has recently been plagued by insecure, missing and broken patches, and spent years refusing to fix their software despite known security issues.

Now let’s move further and evaluate her remarks.
If she thinks that she’s perfectly right then it goes on to prove that Oracle itself doesn’t hire good programmers or the problem is at the senior level who doesn’t understand how important is the security and can’t define an architecture for the same and if it’s coming from a senior person then the gap is there and the blame is not on developers.

I have been fortunate enough to be on both sides of the development fence – development (Code crunching) and design (Spec creation). How often does a product design start off with one set of specifications, only to be completed with a whole new set of specifications? Such is the nature of development. Software development is an iterative process and iterations happen only in the form of changes or creeps and if what she’s saying matters then there’s no room for Change Request in Oracle. Using the bridge analogy is over simplifying the matter - (I am not a civil engineer, so please forgive me if I hit on anyone's toes) but in my opinion when building a bridge, the specifications are set out and signed off before the project starts. Once signed, that’s it - the specs don't change. What would the bridge look like, if halfway, the engineer decided to change the bridge from a pillar supported to a suspension bridge? Or start a concrete bridge and later change to a steel bridge? IMHO if we stick to the spiral life cycle of software development, the chances of buggy and insecure things can be reduced. Consider a scenario where you are working on a large project which deals with the complexity and your analysts design the architecture of the project but things may go wrong here also, for example: the person who wants to get his project done can’t translate his requirement into the proper phrases and giving a hazy picture of overall project or the person from our company dealing with the client can’t translate his details into a clearly written form which in the first phase itself may result into the requirement gaps.
I’d recommend a procedure in which a scope document is frozen with all plans clearly stated and let the execution phase start but changes are unavoidable which means we should have a policy for changes. Every change asked by the client should go through a brain storming session where causes and effects should be reanalyzed in terms of time, risk and money and send the updated document to the client and seek their approval and only if approved, the project should move further for the changes.

Another way to curb down the number of bugs and handle creeps is to have properly laid out milestones and milestone policies. If project is tested after every milestone then the chances of reducing the bugs and creating security holes will be reduced. Security seldom features in today’s (RAD managers specially) managers and since we don’t have these in document, you can’t expect QA guys to go through those vulnerabilities also.
Development is a predominantly reactive position, where a developer gets spec and creates accordingly - the developer cannot override the specification at a whim. If he consults the designer and if the specification cannot be changed, what must the developer do? Not write the code?
Same for QA guys who can’t override the specification, use cases and test cases and everything of these are totally dependant over the Scope designers.
IMHO, Instead of complaining about buggy code, rather get the original spec, use cases and test cases, and see if the code functions within the required parameters. If it does, then review the code. If it does not, yes, then its buggy code.

One more thing I’d like to emphasize on is that do we follow the methodologies when the budget or the timeline gets tight? BTW when everything is planned in a structured way then why budget or timeline should get tight? It boils down to one fact that software development is an iterative process and if this fact is accepted then have the concrete policies to allow changes and creeps in the projects gracefully and logically.

What you get is not the result of 'mistakes', it is the result of the compromises which were made along the way. If you didn't test enough, it was because someone preferred buggy code over testing. The same with deadlines, budgets, training, skills, and every other resource which was lacking, along with every other corner which was cut. 'We' typically don't want to admit it, but the fact is that the decisions we are making are not 'how do we get good programs', but rather 'what mix of bug free, quick and cheap is what we really want', with a huge dose of wishful thinking and mutual amnesia to hide the fact that we know exactly what will happen if we do 'A', when it would require doing 'B' to get really bug free code.