A Plea for Simplicity – You can't secure what you don't understand. (1999)

https://www.schneier.com/essays/archives/1999/11/a_plea_for_simplicit.html

by raphaelss • 11 years ago

37 6 11 years ago

This was written in 1999, I wonder if his opinion on software engineering practices have changed. I've never worked in industry, but based on what I've read there are some pretty good processes that are supposed to have some empirical support, just not many people adopt them. Like I read a paper from 2002 in which basically no companies would consistently use good processes.

Most of the material in my Software Engineering course is outdated, but I imagine most companies still try to get away with minimum security and slack on good software engineering practices, like code reviews and static analysis and thorough security requirements, or what have you. Using these processes in general tends to force simpler systems. Iterative development with clear thought out implementation per iteration etc.

jpgvm• 11 years ago

It's worth remembering in recent times many companies that write software are not software companies and ones that are don't focus on the quality of software but rather the amount of revenue that can be derived from it.

The only industries that have good software practices are those that are regulated heavily enough for it to matter, see here medical, aviation, military etc.

Unfortunately the vast majority of software is not regulated in this way despite handling data that is potentially just as sensitive from a personal or even financial perspective.

At the end of the day most companies are motivated to produce software quickly and quality is second unless it's causing a reduction in velocity, even then this is simply treated as a debt that is paid down periodically to maintain velocity.

There are exceptions for things like banks that rely on the quality of software to avoid losing money, but we are talking in general here.

A brilliant example of what happens when you have sloppy security/bad incentives AND you underestimate the damage a breach would cause is the Ashley Madison situation. Many companies are in the same situation and have just been lucky enough to avoid a catastrophic data breach.

Sadly velocity is going to be valued over quality (which in turn means security) for the foreseeable future.

eru• 11 years ago

The automobile industry has heavy regulation for their engine (and similar) software, and their code seems to be pretty poor.

The big internet companies, like Google, Facebook etc, have no regulation on their code, yet adopt practices like code review.

Banks have pretty bad software quality, too. (I worked for one bank, and talked to lots of people.) Though that's a generalization: there's lots of places for software in a bank. The parts that directly handle the money tend to have less bugs emerging day to day, but that's more because of low velocity and operating within known parameters (so as not to trigger any lurking bugs in the edge cases).

A Plea for Simplicity – You can't secure what you don't understand. (1999)

Related Stories