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. "
D*mnd if you do and D*mnd if you dont (Score:4, Interesting)
Now there's a mathematical formula (let me see if I can derive one) for each level you go down, the half-life of bad software divided by the software engineer goes up a log base 10 (4 - 95%, 3 - 90%, 2 - 75%, 1 - 50%, 0 - 25%, -1 10%, -2 - 2%, -3 -
mm (Score:3, Interesting)
There may be minor flaws in things that an application relies on i.e. external code libraries or methodologies which have not been proven and tested.
Speaking of tested, how many coders here can testify that they are great programmers, but so many times have not been given appropriate amounts of time or resources to write something that works perfect.
That to me is not bad programming, because many times under these situations programmers do an amazing job of writing amazing code which actually works for the most part.
There's too many managers out there who like things to work 90% and say that the other 10% (which usually ends up being crucial to end users) can be dealt with after the initial release.
Bullshit! (Score:5, Interesting)
Last month, a system that controls communications between commercial jets and air traffic controllers in southern California shut off because some maintenance had not been performed.
As I recall, the system in question has to be rebooted every thirty days, which is a software problem! The very fact that there were ridiculous procedures to fail to carry out is due to the poor software in the first place.
It's really amazing... (Score:2, Interesting)
how many large companies think that they can still be successful by programming their way out of problems.
If you work at a company that places some value on requirements and design development before you start cranking out code, consider yourself fortunate. And for those of you that have a consistent process for development and deployment, you're not that common either. There are still a considerable number of large companies with a presence on the web that rely on individual heriocs to keep their business running.
In most cases, it's management's reliance on a few people within development that keeps them from making any improvements. That and the lack of undestanding that spending some money could make (or save) them significant amounts of money.
Fuck You Microsoft-NBC! (Score:2, Interesting)
The fact that YOUR SOFTWARE shuts down after 49.7 days "to prevent data overload" is YOUR FAULT and BAD SOFTWARE DESIGN, no matter how much you use your pet news outlet to spin otherwise.
You're right about one thing, though. The FAA guys were idiots for deploying your software to replace an (eminently more reliable by all accounts) UNIX-based system. Call it a compound failure.
-Isaac
Re:Buck Passers (Score:3, Interesting)
While I agree with you in principle and acknowledge that stupid managers are
Fuck - isnt it time we stood up and just told the truth - or are we all too scared of being outsourced to India?
Biased View? (Score:5, Interesting)
Translation: they didn't hire enough analysts
Translation: They didn't hire enough consultants from SAP.
"Developers are least qualified to validate a business requirement. They're either nerds and don't get it, or they're people in another culture altogether," said Michelsen,...
Translation: It's not our fault the developers couldn't understand our brick of a business case.
Another common theme in failures lies in the ranks of employees who actually must use the systems.
Translation: It's not our fault the interface sucks - it's the stupid users too dumb to adapt to our software.
Re:Irony (Score:5, Interesting)
Case in point, MS Windows. I actually read a book on programming security from the head of security at Microsoft(yeah, laugh all you want), and it gave some interesting insight to the corprate culture at Microsoft. The talking heads at the top want a shitload of features, and they want it by an unrealistic deadline(which, with the exception of longhorn, they almost always meet), and security gets pushed to the back, and maybe only added in as an afterthought.
Contrary to popular belief here on
I think Linux main security advantage lies not in that almost anyone in the world can look at the code(though that helps) it's that there is no "mono culture", you get a lot of interesting ideas contributed to the kernel, some are good, some not so good. Eventually the bad ideas fade away and you are left with a very solid operating system.
Duh. (Score:2, Interesting)
However, it seems to me that bad programming gives rise to buffer overflows and the like. These are more serious harms because they lead to the exploits. If you programmed well, you'd have a crappy program that would simply suck.
Business Process Broken (Score:3, Interesting)
- software projects are usually done in concert with business process changes,
- business process changes are often poorly managed, and
- the resulting problems are usually not due to software implementation issues
In other words, if you want your software projects to succeed, recognize that the management and executives are where a company's resources should be concentrated. The programmers are usually unimportant to the success of a project, and businesses can safely spend fewer resources on them without negatively affecting most projects.Re:Irony (Score:5, Interesting)
The genesis of the problem was the transition in 2001 by Harris Corp. of the Federal Aviation Administration's Voice Switching Control System from Unix-based servers to Microsoft Corp.'s off-the-shelf Windows Advanced Server 2000.
they violated the golden rule: dont touch the system if its working. and they were punished
wtf? the new system, designed to replace old one, was incapable to deal with data load? why would they "upgrade" it anyway?
Also Reported In... (Score:2, Interesting)
The Pittsburgh Post-Gazette [post-gazette.com] has a closely related story: Software disasters are often people problems [post-gazette.com]. Well, duh: "Garbage in; garbage out."
What I find really interesting is that this story, or various versions of it, while hardly "new," starts popping up on news sites all at once? It sounds like some organization is running a PR campaign, but it isn't quite astroturfing [catb.org].
Not really Irony (Score:2, Interesting)
Re:Buck Passers (Score:4, Interesting)
That does seem to be the case at I company I consult for. As a part of an assessment, we received several unsolicited comments that they would be resistant to changing the way they performed development because the business customer was free to outsource. And it's happened on a few projects when the development team pushed back on timelines and requirements.
As a result, the development staff here lies to their managers, who lie to their directors, who lie to their VP's and on up the line. This points to a breakdown in communication between all levels in IT including the lines between IT and the business.
Re:One of the biggest problems (Score:3, Interesting)
time to marked, deadlines and rushed projects (Score:5, Interesting)
I have, time and again, been asked to cut corners in the design during the implementation phase of a project. The result is, that too much is cut in order to meet the deadline, another project sucks out key resources after the deadline and the product is rushed into production.
Everybody is happy until things start falling apart
44% of the employees (a couple of hundred) in my department are consultants , employed on a timelimeted contract. Some slam things together knowing they are not present when "patch time" starts
Bad testing, bad deadlines and rushed projects is the cause of a lot of evil!
Luckily, I can still express myself in the cvs comments and the random comments in the code
Re:Buck Passers (Score:5, Interesting)
They fucked it up so horribly and it cost so much money that in the end they threw up their hands, wrote off about a million dollars worth of expenses and developed the app internally.
The internal developers (several of which were Indian might I add) finished the app on schedule.
Our company then passed an internal policy that we would insource (bring programmers in to work on a project) but that outsourcing was out of the question.
Re:M$NBC says $oftware is Good! Blame the user. (Score:2, Interesting)
Just curious as to a radical's answer sheet.
Please note that I chose linux over windows for my applications, but I still have an open mind, and am willing to use it for its purposes (yes, it does have its purposes). I am no radical either way as it is obvious that these operating systems each have their own niche. Even OSX, although I've never used it.
Re:Snippet on blaming the developers (Score:1, Interesting)
you get what you pay for (Score:2, Interesting)
from tfa: "It becomes a major role of (management) to kind of herd the cats in and make them all line up in a reasonable way," said Barry Wilderman
yea its becomes much harder when you have to work with people who not only have bad communication skills but may not know the subject matter.
(sarcasm) enjoy the saved cash you paradigms shifting fucks
let alone the fact that many times you dont know if your getting someone who has made 10 hello world programs and count themselves as a pro in each.
ah and the images in tfa of people holding each other watching their software fail was priceless.
Customers & managers (Score:5, Interesting)
In India, software companies treat the customer as God accepting his/her unreasonable targets.. I wouldnt blame the customers alone for it... the managers too are responsible. They agree to whatever the customer says even though the actual development team asks them not to. And then, the normal work timings stretch to 10 AM to 3-4 AM next day... Now, anybody think anyone can write quality code when they are working this timing??
Well, the only advantage that comes here is that we get to read all the
Here it comes.. (Score:3, Interesting)
Actually, now that I think about it, that's probably closer to the truth than anything else...
Re:Snippet on blaming the developers (Score:3, Interesting)
Being a junior developer is irrelevant your problem - if you have a good PM, hs/she should be willing to go to bat for your team, and demand functional and technical specs as needed. If not the project will be in jeopardy. If the PM does ask for requirements and doesn't get them, at least it's a CYA situation - and they can say look "get me the info the team needs, or I can't promise what will be delivered"
When you have a PM who isn't willing to do that you're bound to get screwed. Best thing to do is document all your requests for information, and tell the PM, if you want this to project to succeed, like it or not - I need information "x" and "y". If the project is a crash and burn, you can say you did what you were able to provided the information that was given to you - and you weren't given all you requested.
Any company-organization that considers you and 'idiot' for wanting clarification is looking to burn money on a failed project and/or happy to waste resources on lots of bugs fixes and patching. They should look in the mirror before viewing others as idiots.
blame the users (Score:3, Interesting)
There was then supposedly a program crash and magically the message went out.
I was of course blamed because as the network admin I somehow failed by being unable to bring back all of those e-mails, even though there are a million things wrong with that train of thought.
Clearly they couldn't imagine that:
1) software crashes don't cause mail to send
2) why was she removing names from a group instead of selectively adding them
3) she didn't use the software correctly on multiple counts
4) if she is clearly not competent enough to handle this and it was such an important e-mail, why was she given the task and not someone higher up?
In the end, yet one more reason I hate my job.
So it's the Hardware then... (Score:3, Interesting)
Assuming all my hardware is behaving nicely if a crash occurs that means a piece of software somewhere has failed, be it OS, network or what have you.
Re:MS employees (Score:5, Interesting)
I seem to recall a study, by IBM possibly, into how much young developers really contribute to software projects. The conclusion was that most of the young starters (up to age 25 IIRC) were only good for writing docs and possibly testing. You shouldn't let them near the code, because in the balance of probability, they will be counter-productive overall. Those up to age 30 were found to handle development on a single, focussed project usefully, but no more than that. Those over 30 could handle working on multiple areas at once competently.
Those figures are all from memory, but I'm pretty sure they're close. They're also a pretty damning indictment of the age discrimination that is rampant in the software development industry, and a fairly compelling explanation for why so many projects fail after the management choose to hire youngsters because they're cheap and willing to do whatever to advance their careers...
Re:Buck Passers (Score:2, Interesting)
Supervisors are supposed to watch. And presumably do something if they notice something wrong, like employees hanging out in the break room for six hours straight.
Managers are supposed to manage people and things. Manage doesn't mean 'control', it means 'watch and direct'. They're supposed to watch paper clips and direct them towards a purpose, they're supposed to watch employees and direct them towards some purpose.
There's a reason we don't have 'controllers' or 'directors'. (Well, unless you're a spy or in a theatre, in which case those actually do means 'someone who controls you'.)
Interestingly enough, I can't figure out where 'boss' come form, only that it also means 'knob or protuberance', hence 'emboss'.
Programmers vs. Managers (Score:3, Interesting)
If you're programming with other programmers, you are operating in an environment that has constraints built in. You are constrained by the quality of your teammates, by the amount of time available, by the list of desired features, and so on.
Now imagine that managers are faced with constraints. They have to deal with the insane deadlines imposed on them by the O-level people in the company. Middle managers in particular are often in a very unenviable position, in that they have to try to make impossible demands possible. But just as there are varying levels of programming skill, there are varying levels of management skill. Some managers can push back on their bosses enough to give the project a chance of succeeding, but many are ill-equipped to do so.
Those that are ill-equipped to do so are in this position primarily because unlike the field of programming, where specialized education is seen as a necessary prerequisite to employment (i.e. - "He's got a bachelor's in Computer Science from MIT, we'll hire him") most managers either have no specialized management training, or they have an MBA (a degree that sometimes offers real management training but often provides no practical hands-on management training at all), or even worse, they've been in the same company or types of companies for years, learning the same bad management habits over and over.
What businesses need to do is pay more attention to actual real-world leadership experience and training. "Manager" is a term that reeks of 19th Century automated factories. When you're dealing with abstract concepts, creativity, and continually-shifting requirements, you need to have leadership skills.
You also need to have people skills, and while it's easy to berate salespeople and managers because they often seem defined by their "touchy-feely" capabilities, the flip side is that without those abilities, it's very very difficult to lead people.
Re:Buck Passers (Score:2, Interesting)
It is originally New York State slang, which was previously New Holland, the majority of the population remaining of Dutch descent for nearly 100 years after the British took over administrative control of the territory (with a French majority in the Adirondacks). It comes from the Dutch 'baas', meaning 'master.'
Oddly enough, the 'boss' meaning 'knob or protuberance' comes from the French 'boce,' which can also mean to beat to produce a swelling.
I don't have a reference handy for the Indo-European root of these words, but my sense of the sardonic suggests to me that these two words share the same root.
KFG
278 Million Dollars later it gets cancelled (Score:5, Interesting)
At the U.S. Department of Veterans Affairs, some of the payroll systems date back to 1964 (that's right - no joke, they were bought when Lyndon Johnson was President), so they decided to replace them with a new system based on Oracle Financials. The new system is called CoreFLS. It has been a fiasco [informationweek.com]. So far VA has already spent over $270 Million out of an expected $472 Million total budget for the project. The project has been a failure laregly because of mis-management and plain-old stupidity.
First, they decided to do test trials at one of the busiest hospitals (that's right, they first went live at one of the *BUSIEST* hospitals) instead of a smaller test location. The user training for a critical system consisted of a self-paced web-based distance training as detailed here [sptimes.com]. No hands-on training was provided until a month after deployment and only after problems were apparent because the whole operation ground to a halt. So finally the senior managment decide to commission a $500,000 study from Carnegie Mellon to find out why it failed. The study concluded that CoreFLS was "an exemplary case study in how not to do technology transition." Yeah, they needed to spend a half-million to find the obvious.
Finally Congress got involved and all the senior managers including the Secretary himself were put on the "hot-seat" to testify. Lots of heads rolled (even senior managers like Assistant Secretaries) and lots of people were forced to resign or were fired. Now the place is crawling with federal investigators looking to put people in jail
So now the project gets cancelled. The sad thing is that VA really needed this program to succeed. I suspect that the technology has been made a scapegoat for mismanagement (not that the technology was perfect). Well.. back to 1964.
Re:Buck Passers (Score:4, Interesting)
Our company then passed an internal policy that we would insource (bring programmers in to work on a project) but that outsourcing was out of the question.
But this is also a problem. I've had so many managers who took the approach 'well, it didn't work once so it is now policy that we never, ever do it again' that it ends up biting you in the ass.
My last manager (I quit 2 weeks ago, yay me!) decided that software unit testing was fundamentally bad, because he'd tried to manage a project using XP (eXtreme Programming, not.. oh you know) and that uses unit testing and it didn't work very well. It became policy that we should never do unit testing. I kid you not.
Creating a policy to never do something that didn't work the first time is as bad as not trying it in the first place.
Re:Mod parent up (Score:3, Interesting)
It really does depend on the development team and their management. In many places, you're certainly correct, but plenty of commercial software houses do take pride in their work and/or realise that producing a well-tested, secure product is priceless in maintaining a good reputation. I've known plenty of development shops where security, and reliability for that matter, are taken seriously, planned for throughout the design and implementation, included in the review processes, and tested with enthusiasm. Unsurprisingly, these places turn out good code.
Of course, a lot of this stuff is done by software houses or contractors whose reputation is their livelihood, and it's done for private clients so most people never know about it. Compare and contrast with a major product company like Microsoft or Apple, where if they screw up even once in an enormous project, the whole world hears about how "insecure" closed source commercial software is, and you can see why a lot of people who aren't in the business get the wrong idea.
Re:MS employees - Not only MS! (Score:4, Interesting)
Re:Buck Passers (Score:3, Interesting)
I was somewhat enlightened years ago by the suggestion to turn the org chart upside down, so that we see the CEO at the bottom supporting everyone. The only people *not* in a supporting role are the workers who actually make or do things wanted by customers.
Re:Buck Passers (Score:2, Interesting)
Re:One of the biggest problems (Score:3, Interesting)
You've hit the nail on the head, thought I didn't realize it until I read your comment. The HARD part of programming is dealing with the people. Everything else can be understood logically, which is easy, but dealing with people is an irrational process. Anyone can find the square root of 8 (ie write code) but not everyone can find the square root of an apple (dealing with people).