Slashdot Mirror
Insecure Code - Vendors or Developers To Blame?
Annto Dev writes "Computer security expert, Bruce Schneier feels that vendors are to blame for 'lousy software'. From the article: 'They try to balance the costs of more-secure software--extra developers, fewer features, longer time to market--against the costs of insecure software: expense to patch, occasional bad press, potential loss of sales. The end result is that insecure software is common...' he said. Last week Howard Schmidt, the former White House cybersecurity adviser, argued at a seminar in London that programmers should be held responsible for flaws in code they write."
Let's see: do we hold employees at an auto factory responsible when unrealistic timetables means shoddy workmanship, or do we hold the employer who chooses speed to market over quality responsible? If that failure means the death of someone, do we sue the manufacturer or the guy who made the poor weld?
Large software companies have more in common with factories than they do with law firms or medical practices, two places where the liability *is* on the individual. The employees don't get to choose how much time is spent designing quality and security into the product, nor do they get to choose how much quality assurance is done on the back end (although that is a lesser solution to quality code, it is still necessary).
The day that every programmer is licensed the way that doctors and lawyers are is the day I will reassess this position, but for now programmers are *not* in the position to make the decisions that lead to quality code. I'm not convinced that licensing would ensure that, but without licensing coders are nothing more that code churners cranking to the beat of the employers drum.
Sig under construction since 1998.
Having been involved in software development I can confirm that most companies are more concerned about cost than the security of their code.
They would rather get the product out there quickly in order to produce revenue rather than hire more and better developers
to secure the code.
It is very sad....
Too bad you have to click through the EULA before you can test it, suckers!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
The real article by Bruce Schnier is in Wired:
. html
http://www.wired.com/news/privacy/0,1848,69247,00
Its more interesting than the sound-bite-full ZD-Net summary.
-dZ.
Carol vs. Ghost
Most other free software licenses also have something similar:
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
Quality code CAN happen... but first things must change...
Right now the environment in the business world today prevents truly bug-free programming. A lot needs to change:
1 - Fire all the programmers and developers that can't program. We all know which ones in the group fit into this category. Unfortunately our bosses don't know. They're the ones that cause the majority of the bugs. They came into the industry just for money (pre-2000 bust) and they have no real feel for programming yet they know how to email the boss. Keep the ones that are naturals. The real code warriors. The good ones know when to code new source, when to copy old source, and how to clean up old source when they copy it into their new modules.
2 - Get rid of the bosses that don't know tech people. (i.e. the ones that don't know the difference from #1 above) The boss doesn't need to know tech (it does help) but they do need to know their people. They also need to know how to keep office politics and beauracracy away from their people.
3 - Get rid of separate New Development and Maintenance groups. People will code better when they know they will have to fix their own code when it goes into production. They will care more about stability instead of features. Also, a programmer learns the difference between good and bad coding techniques when they are forced to maintain both. When you are maintaining programs you learn how to right code that is easier to fix or modify later; if all you do is new development you will never learn this key concept.
4 - After the requirements are requested and the specs/design is created don't let users change them. I can't change everything just because a user changes their mind. If I have to change, the release date is pushed back as if I just started the design today. I can't complete a program until you are done knowing what you want it to do.
5 - Procedural vs. Object Orientated programming. The huge developement debate. I admit I am biased toward Procedural programming. However, you should use whatever works better for your project. A GUI works better when you design using OOP, but when you need to crunch numbers on 10 million records procedural will work a lot better. I know a lot has been said about the poor code quality of OOP in particular, but if you get rid of the idiots in #1, the logic should be easy to follow.
6 - KISS - Keep It Simple Stupid - I used to work with someone very intelligent, but his code was terrible. He would program elaborate functions just to add two numbers together. My honest belief is that he tried to impress us with his "coding ability." If someone needs a simple program give them a simple program, don't redesign the wheel.
7 - Shoot and KILL everyone that sponsors or participates in a unreadable source code competition. (sorry personal peeve) We need to promote legible code with indenting and good, clear, and relevant variable naming.
8 - Quality. CMM, ISO, TQI. These are nothing more than BULLSH!T. While there some occasional insights coming from these "Quality" initiatives I disagree with most of the methods. Unfortunately, most of this initiatives are nothing more than feelgood bs for clueless management. Commenting and documenting your code is a good thing. However, these "quality" processes can also cause over-documentation. If you spend more time documenting your code than it will take to rewrite your system, you have documented too much. No one will sit through reading 50 hours of documentation to fix a small bug. When your documentaion helps explains why your code is doing obscure things to save the time of the person after you (or even remind yourself months later) you have the proper level of documentation/comments. I honestly believe that some of these initiatives create tons of documents so consulting/contracting companies can increase billable hours.
9 - Admins and Tech Writers. Hire all the good ones back. The improve our ability to code by letting us
Looking for a job?
Want your resume written professionally?
DON'T USE TUNAREZ!!!