Slashdot Mirror
Yet Another Software Sucks Article
Narril Duskwalker writes "This one's from cNet.
`There's only one problem with software development these days, according to security analyst and author Gary McGraw: It isn't any good.'"
`There's only one problem with software development these days, according to security analyst and author Gary McGraw: It isn't any good.'"
1) Another book plug? What's with you guys?
2) The solution is to take all that online crap and shove it. Forget networked user software except in cases that really need it. You need it for group collaboration. You don't need it for running simulations.
This guy seems to overestimate the real problem.
And popular languages like C and C++ are really awful from a security standpoint.
I wonder what language they wrote the JVM in...
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
IMO, this guy needs to get off his soap box and stop stating the obvious. He makes a lot of valid points, but he stopped just short of saying "comuters run on electricity, and you need to plug them in to use them." I'm amaized at the fact that this artical got published at CNET and that I actually read it. Hell, if I ran this post through a spell checker, I would only be a half step behind him.
I can now say "I got my thoughts published on the internet at a popular news sight." just like him.
Who wants Pork Chops?
The problem is that software vendors get away with using the laughable disclaimer that "this product isn't warranted for any suitability or purpose."
I'm not even sure that the kind of disclaimer above should be legal without a more concise "NOT GUARANTEED TO WORK" stamped across the splash screen.
If a company isn't willing to guarantee that a program fucking does something, why do they keep coming back to it? Because it's got a Madonna song and fluffy clouds in the commercial?
If a company consistently provides unstable software, why do people run to upgrade instead of demanding more comprehensive patches for what they've already paid for? Is rushing toward flashy new features more important than stabilizing what you've already got?
Interesting article, but I'd like to see more specifics. I guess McGraw is (1) trying to sell his book and (2) talking to a wide audience as likely to include managers as developers, but what I really want are some meaty bits that, as a developer, I can directly act upon.
The FreeBSD site has some secure programming guidelines which are worth a gander.
Score: -1, Kick in the Head Obvious
Does it occur to him that software designers might write "complex and hastily" code because expectations are high and time is short. And where, besides software, would computer security problems lie anyway? SCSI cables?
Takahashi Rumiko made beats! DON, taku, DON, taku. . .
"... way more complicated than it used ..."
If someone can't even use the english language "proper", how an earth can they be trusted to use any other language, with out dodgy grammer.
Maybe he was in a rush?
try to make ends meet, you're a slave to money, then you die
OK, so the article is about coding for security, but it's worth considering Tom DeMarco's line in his excellent book Why Does Software Cost So Much ? where, he says, the correct answer is "Compared to what ??".
Kicking those who manage complexity is always going to be easy - but until you can do better then you're not really helping.
The book is well worth a read... if only to shut up all those metrics freaks...
T
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best
For one, who the hell is this guy? What qualifications or experience does he have that make him a security expert? I could care less about his doctorate or his java security book. Security has nothing to do with a programming language. You can write secure, or insecure programs in any language. As Bruce Schneier says, security is a process, not a product.
Let's assume we take all the authors advice and read his book. Write some "secure" software that meet his requirements and for all intents and purposes the software is "secure". Now take this piece of secure software and put it in an insecure environment. With no physical security, no network security, no security policies in place to use the software, etc. Suddenly your "secure" software is not secure anymore. So obviously, the problem is not software. Perfectly secure software will not solve security problems.
Let's use an example. Let's say somebody keeps breaking in my front door. I add locks and chains and somebody keeps getting in. So I go out and spend $10k on a front door that is bulletproof and guaranteed to be secure. Haha, I've got them now. The next day, they break my window and walk climb through. The door was just the easiest way to break in. Secure the door and there will be another weakness. The problem is much bigger than just the software.
In the same way you should not trust a newly invented crypto algorithm, you should not trust some random joe blow's opinion who got published on cnet.
mp3's are only for those with bad memories
software companies to stand by their claims, and take out the no guarantee clause?
Simplicty takes time. Complexity is easy. Early phases of evolution always spawn fantasticly complex structures. Over time these get beaten down into simpler, stronger, and more subtle designs.
This is really a great opportunity for those who would try to dethrone Microsoft from its place as the software vendor of choice for many companies. Provide an alternative, use security as the winning card.
The challenge is to improve the existing structures, secure all the entry points into a network, assume that all contacts are potentially hostile, and generally turn the naive servers we use today into something resembling a real organism: alert, defensive, paranoid. Competition will then do the rest.
My blog
Let's face it, the guy is, unfortunately, right. C and C++ ARE crappy languages, in that they rely on the programmer to ensure there are no buffer overflows. Other languages do offer such protection. OK, they may be different from what you are used to working with, but too many programmers (me included) don't check for overflows. As a result, we get bugs. Some merely crash the program or the system, some can be used to crack the whole box.
Who's to blame? Designers, programmers, consumers? It's tough work to retrofit security into an insecure design -- look at all the work sendmail has required in the last five years. In general, only those programmers who have been bitten by a security bug take the time to put in the extra checks -- it slows down the programming and the program. As for consumers, we'd all rather have the latest and greatest."features." (Like Clippy!) Until you've been bitten, of course; mine came when somebody hijacked my 14.4k dial-up connection to relay spam.
Why don't we return all the software that crashes, like everybody's talking about doing with the new copy-protected CDs? What do you need with the new Office XP that wasn't in Office 95, for example? The new, improved, crash-resistance? ;)
"It turns out that software is way more complicated than it used to be."
[Wow. That's the most blindingly obvious comment I've heard for a long time!]
I feel that poor software quality boils down to (a) inprecise specification (b) incomplete planning and (c) development environments that are to damm fast.
I recall in the good 'ol days of computing having to wait hours for a compilation run to complete. You can bet that the thought behind code changes was considerable and that every line was checked very carefully, dry-running and all that stuff.
Nowadays it's hack, compile, test, hack, compile, test etc etc until it works. Why it works and if it will hold up is a seperate, and largely ignored, issue. And don't point at QA and say it's their job to find the bugs in your crappy code. It isn't -- it's yours.
So, who's for going back to really s l o w compilers as a mechanism for improving software quality????
Rich people are eccentric. Poor people are strange. Me, I'd be happy with odd.
"And the best way to determine how many problems are going to be in a piece of software is to count how many lines of code it has. The simple metric goes like this: More lines, more bugs."
No the best method also factors in competancy of management, competancy of engineers, and the cost of failure.
Lets take as example nuclear power plants than have operation control code behind them - how many lines of code do they have? I'd suggest 10's of millions.
Why don't we see crashes of these systems widely reported?
1) They are safety critical, if an error occurs anywhere the surrounding code must fail closed meaning that it should not result in false results being produced.
2) If you screw up you can't just say "hey we'll fix it in the next version" - if you are lucky you'll simply get your day in court for negligence and you will no longer have a place in the safety critical market. If you are unlucky that still happens but you then get the ass sued off you by the relatives of anyone injured, maimed or killed by your software bug.
You have to admit the second point really is one hell of an incentive not to screw up!