Don't Shoot Me, I'm Only the Software 392
ctwxman writes "How often have you heard about some massive crash and then the blame was placed on the software? "Disasters are often blamed on bad software, but the cause is rarely bad programming." If you've been looking to blame your boss, this article from MSNBC says your ship has come in! Poor planning, poor execution and poor leadership are more likely to blame than bad code when it comes to systems that fail. "
Buck Passers (Score:5, Informative)
I think this little gem [dilbert.com] says it all. Strangely enough, it's today's Dilbert. Thing is, the buck-passers are who protect their own image or the image of those who write their cheques. The result? Too many projects are blamed on interns or programmers, rather than the truth coming to light.
Why? I think it's simple, really. Management often has no clue what they are doing in terms of managing a technical project so they make decisions about things like the exact features, and they often fight to get things a certain way -- unwittingly forcing programmers to code all the way around the block to get to the house next door, leaving problems in the wake.
The best case is when a programmer is given design autonomy. That's why Open Source is such a threat to large companies like Microsoft... because the guys who know what *can* be done, are the same guys doing it -- the result is 1111x better, and cheaper too.
I am so lucky to be working now for a company that allows me to have full autonomy with my projects. They tell me what the customer wants and I do it the way I think is best. Every single project done in this manner has resulted with happy customers and excellent systems.
Re:Also... (Score:3, Informative)
Now of course you are right that some admin forgot the fortnightly reboot and that led to the problems, but I simply can't totally dispute the notion that a server OS that has to be regularly rebooted should at least take a share of the blame.
Hrm...Theres a problem here. (Score:3, Informative)
However, I do take issue with the following quote:
"Another common theme in failures lies in the ranks of employees who actually must use the systems. Often they're not given proper training. There's also a chance that they don't want the project to succeed, especially if they see it as a threat to employment."
Never give the credit so quickly to evil intent if you can chalk it up to simple laziness instead. I doubt many employees conciously try to cause software crashes, in comparison with the number who just dont have a clue what they're doing.
And, naturally, programmer error will always cause a certain amount of crashes...we are human too. Testings just a way of minimizing that.
Link to NIST study (Score:3, Informative)
I've bitched about this before, but why can't news sites provide links to their sources? This is the internet, after all; we have the technology. It would take seconds, and obviously the journalist already has the information. Yes, I know I can search it myself, but I shouldn't have to - the supporting documentation should be provided by the person writing the article. (And, yes, I'm aware of the irony of saying that without providing a link. :) But I'm stating an opinion, not a fact.)
http://www.nist.gov/public_affairs/releases/n02-1--RJ
Re:Bullshit! (Score:3, Informative)
Re:Fuck You Microsoft-NBC! (Score:5, Informative)
The 49.7 days refers to stuff that is not based on Windows NT. IE Nothing to do with the system deployed that was Windows 2000. Second, the versions of Windows that are built this way do not require rebooting at this period, an internal timer turns over and the system continues on as normal. The programmer who designed the system for the FAA msut not have RTFM or designed it very poorly to require this.
Re:MS employees (Score:3, Informative)
Several of my friends spent their co-op terms at Microsoft, starting out in testing, moving up to code monkey, and by the time they graduated and were hired (with 2 years cumulative experience), they were offered jobs as project managers.
My first co-op job was in IT. I very quickly figured out that it was something I did not want to be doing for the rest of my working life. Then it was on to software, which I also didn't enjoy that much. By my 4th co-op term, I landed a job at a hardware design company, and haven't looked back. I graduated with 1 year of hardware design experience, and now happily work at my job designing image sensors.
To anyone out there considering post-secondary education, I heartily endorse programs that allow you to get real-world experience before graduation. Not only does it help you figure out if you're going to like it, and get you the experience that gives you an edge up on your resume, you'll often find that it will almost pay for your schooling too.