Study Confirms the Government Produces the Buggiest Software 135
Sparrowvsrevolution writes in with a link to a Forbes story about the lackluster code produced by government agencies."Humans aren't very good at writing secure code. But they're worst at it when they're paid to do it for the U.S. government, according to a study that will be presented at the Black Hat Europe security conference in Amsterdam later this week. Chris Wysopal, chief technology officer of bug-hunting firm Veracode plans to give a talk breaking down a vulnerability analysis of 9,910 software applications over the second half of 2010 and 2011. Government-built applications came out far worse than those created by the commercial software industry or the finance industry. Only 16% of government web applications were secure by OWASP standards, compared with 24% of finance industry software and 28% of commercial software. By SANS standards, only 18% of government apps passed, compared with 28% of finance industry apps and 34% of commercial software. Wysopal and others blame the difference on a lack of accountability of federal contract developers, who aren't held to security standards and are even paid extra to fix their bugs after creating them."
Hiring the cheapest competitor doesn't help either (Score:4, Informative)
The rules for government aquisition don't help. As there isn't any usefull formal metric for software quality, it normaly must settle with the cheapest competitor whoever it is, however it works.
Not susprised at all (Score:3, Informative)
My first job was doing software for the federal government (mainly tools for tracking government property and assets and the nightmare of paperwork associated with them). It was _horrible_. It was a well paying job, great benefits, very relaxed (but political) environment .. but the atrocities committed to the art of software development combined with the painfully slow pace were unbearable.
Everything was always caught up in red tape. Requirements were always wrong, outdated, or both. In a lot of cases there was no clear time frame or end plan for software .. that shit would get figured out when/if the project was finished. And projects were often arbitrarily cancelled. Stuff that was finished and deployed often went unused for various reasons.
There was also an anti-change culture. Anything new was met with extreme resistance. Also there was this feeling that anything that improved our efficiency would decrease our staff. It wasn't entirely unfounded. Stuff was scheduled to take a certain amount of time. If it took less time, it wasn't like there was more work to fill in the holes.
And the code. Wow. I think it's part because the federal government has a lot of co-op/student programs .. and part because most programmers that care about software quality got the hell out of there (like I did) .. but the code that came out of my department was.. terrifying. Thankfully these were internal apps. Database queries involving multiple tables can be complicated.. but it's easy to put the same data in multiple tables! So just create multiple tables with the various data sets you need! Suggest a database view (at least half way to an ok solution) .. the DBA (yes, they had a DBA, a professional database guy, and he allowed this!) won't allow it (he won't reject it, he just offers to "look into it", which if you don't know is office politics for "nope!").
Ok I'm gonna stop and let my blood pressure come back down...
Re:Contractors (Score:5, Informative)
I just retired from a long IT career with a fed TLA.
In all that time, there were two projects that stood out in my mind the most.
For the first one, a division needed software to automate their primary tasks. If such software could be implemented, it would essentially be where 20,000 people a day spent all their time and brought in billions of dollars. The solution they decided on was to survey the end users who were tired of doing everything on paper, find the ones who were the acknowledged computer geeks, then let them design and write the program. They actually turned field civil law enforcement officers into SAs and analysts and coders and let them build what they needed. It took years but when it was done, it was a thing of functional beauty. Actually, it was ugly as hell but it so perfectly met the needs of the field officers that I know of several who actually delayed their retirements so they could spend more time doing a job that was fun again because all the drudgery had been automated away.
Most. Successful. Project. Ever.
The other one I remember was the same sort of thing, a program that some 70,000 would spend all their time in. It was buggy from the start. The people who had to use it hated it. Every upgrade broke reports from the previous version. It was, obviously, done by contractors. At one point, development halted for almost 18 months because someone dropped a dime on the contract developer and their entire staff of Indian programmers with expired visas had to pack up and go back to Asia. The contractor folded up shop and getting another to step in, untangle the mess, and start moving forward was a royal pain.
My point?
Sometimes, coder skill is meaningless. If you have developers and architects and all those other job titles involved in software development who actually work for the government because, at least in part, they are proud to serve their country...then you get better software.
Government software should be created by government employees, not contractors.
Now I'll go back to my place in the 1950s, where I'm sure many of you will say I belong.
Don't blame the contractors... (Score:4, Informative)
This is really about government controls run a muck.
NOT Confirms. (Score:4, Informative)
Concludes, not confirms. Studies do not confirm anything (unless done by Netcraft).
Re:Contractors (Score:4, Informative)
1. See, that's the PROBLEM with the private sector. One you can just fire people, you end up with an entrenched attitude of 'Do what I say or else'. Which is fine for a genius like you, but mostly you end up with a high turn over rate.
Making it difficult mean people can speak up. They can tell a bureau chief why they are wrong and not get fired. THIS is what bring quality, depth of knowledge, and honest opinions and view out into the open.
Contrary to what a lot of people thing, it isn't impossible to fire someone. It make take time, becasue they treat their employees like that are human beings
2. the wages aren't horrible. I could make 30% more in the private sector, but my benis are solid, and I like having a life.
The rest of your post is just ignorant. I've seen peopel get fired. It went like this
1) Bad review with detailed list of whats wrong* I've seen people change the work attitude at this point and become better employees.
2) Verbal warning after 3 months. *again,. seen poeple change at this point
3) written warning - never seen anyone recover from here
4) out the door. 3-6 months, and this includes union.
What really helps is the 9 months grace period. Frankly, if you are lazy, you won't make it 9 months without the become obvious.