Slashdot Mirror
Don't Shoot Me, I'm Only the Software
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. "
How ironic that MSN(BC) is pushing a story about 'don't blame the programming'.
Although legitimate in the concept, I would say that poor programming is most definitely a cause for system failures.
If you've been looking to blame your boss, this article from MSNBC says your ship has come in!
I think this little gem 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.
The dangers of knowledge trigger emotional distress in human beings.
I have worked at CIMM level -3 and at CMMi level 5 groups. Starting at level 5, you're about as likely to win the lottery and while on the vacation at the moon than getting fired for bad software; at level 1 your highly likely to get fired for a bad programming mistake; level -3 you try to point the finger for anything.
.01%). Thus, if you want management to point fingers go down in levels but if you want the group to be aware of problems then look for a high CMM level group to work for. Disclaimer this is now way scientific but used as illustrative purposes; objects may be closer than they appear; no left turn on red; do not pass Go.
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 -
This is a double whammy for Billy Gates, it's his software and he is the boss.
The lack of robust testing during and after such a project likely contributed to the Sept. 14 radio system outage over the skies of parts of California, Nevada and Arizona.
As I recall, it also came from a tech who didn't do his job right in rebooting the machine that handled the software.
You can't always blame software; you have to blame the end-users too.
Striking fear in the authors of godawful fanfiction, I am here, appearing in darkness, Tuxedo Jack!
Big projects require organization or shit happens.
Uh, that's it. Thrilled?
Unfortunately, a bug in the ship's navigation software caused the ship to overshoot the dock, killing all programmers waiting for the cruise.
Great.
Bugs and errors do not neccessarily mean BAD programming. Bad means that it sucks and it's of no quality level.
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.
The more things change, the more they stay the same. I fought in the Brain Wars with management 30 years ago, and it was the same thing. The Powers wanted X, but system capabilities were Y. They did not want the issue confused with facts, they just wanted wehat they wanted, and wanted it yesterday. My peers and I coded it as close as we could, implemented it, and crossed our fingers. We kept the app running for about a week (with frequent bailing wire and BandAide patches), but the system eventually melted down due to data overload (fancy-speak for filled up the disk).
Management skated, two programmers fired.
That's why I raise cattle and write hunting articles these days.
Ignorance is curable, stupid is forever.
The article cites as an example,
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.
I beg to differ slightly.
Software projects seem to be primarily constrained by time/money which is usually controlled by management (read: boss)
If one wants to test software properly then you will need lots of the constraints (i.e. time and/or money). Just before a coder is testing his block, he/she will generally say something like:
"I'm finished the block, just need to test it a bit more"
Generally that is not what management will hear, they hear:
"I'm finished"
So they think "its ready". I've seen several first generation projects get hit by this problem (in commercial environments). In the IC design world (where its not generally possible to just flash the firmware to fix a bug) its accepted that at this point - i.e. primary design is finished you are only 50% of the way through. We spend at least half the time verifying the blocks. Management in IC design have accepted that this just as important as the implementation and so don't go off making wild assumptions.
So rather than just pawn off the blame onto your boss, it really is (partially anyway) your fault as well for not highlighting the fact that your block is not as tested as you would like it to be.
The philosophy of open source seems to limit the "its ready" effect to a good degree and hence the better code quality perception. When main stream commercial coding picks up the slack, it should get better as well. But generally a lot of these messes can be attributed to communication (person to person) failure rather than coder/boss failures.
[ Monday is a terrible way to spend one seventh of your life. ]
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.
If you start blaming the programmers, they will lose there self-esteem and move on to other projects. There is only a small percentage of elite programmers that have rarely if ever made a mistake past the prototype stage. This small percentage of elite are not enough to write the programs for everybody. So if we sue/harass/fire all the non-elite programmers, how are we going to make up the deficit?
what does that say about the Father of VMS and winNT then or maybe Gates?
Don't Tread on OpenSource
... OR made by Microsoft. How Windows.* fails and/or is insecure deserves a new whole category for it.
Well, after all, was that company that started the culture that if software fails is something normal and just reboot, and popular culture attributes the problem to the software.
In the other hand, we use to think that software in Linux is so reliable (well, at least Linux itself) than if something fails, must be users or hardware fault, while that is not so true (again, at least for non linux-kernel software)
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
I am not a lawyer, and this is not legal advice. For Entertainment Purposes Only.
Sorry Microsoft, it's the software. When I go to the local airport and see a kiosk displaying a Windoze 2000 screen saver instead of information, something is wrong with the software running the kiosk. I'm sure that the kiosk owner followed all of the directions given and the stupid thing did not work anyway. A box that has to be restarted once a month and crashes when it's not has a software problem. Having two of them will simply multiply the problem by a factor of two.
How am I so sure that software not people are to blame? It's easy, I started using non Microsoft software and most of my problems went away. I've got the same old hardware, it just works better under Linux. It does more for me too.
Why is that? It might be that there's no nasty registry that's designed to keep me from "stealing" software. It might be that sane networking models really do eliminate most problems with worms and viruses. It might be that free software really works to make better code. Who cares?
The bottom line is obvious. No amount of blame shifting will change it.
Friends don't help friends install M$ junk.
[noselasd@labsrv noselasd]$ flight_control
Segmentation fault
"Damn you, management!"
Such disasters are often blamed on bad software, but the cause is rarely bad programming. As systems grow more complicated, failures instead have far less technical explanations: bad management, communication or training.
Really? So the buffer overflows, et al occur because people are not properly trained? I believe the buffer overflow is one of the more prevalent causes of vulnerabilities. The SANS Top 20 list text contains 24 instances of the word 'overflow'. Hmmm.
"In 90 percent of the cases, it's because the implementer did a bad job, training was bad, the whole project was poorly done," said Joshua Greenbaum, principal analyst at Enterprise Applications Consulting in Berkeley. "At which point, you have a real garbage in, garbage out problem."
Perhaps we need an additional step in here: garbage processing.
I want to drag this out as long as possible. Bring me my protractor.
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.
Support more choices in goverment-Vote 3rd party.
is that IT tasks have been highly compartmentalized - to the point where coders are actually versed in a limited set (or 1) coding language.
And coders cannot be designers, DBAs, or possess much business knowledge. Interaction with the end user is done with a 'business designer'.
As with the childhood game of post office, some of the information gets lost for every node in the SLCD (sftwr life-cycle design) chain.
One of the best fixes is to allow direct interaction of coder/end-user, and merge the designer/developer roles for a better industry understanding.
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.
Its not the software that goes bad, its my fault? You can only whip an Indian so many times before he starts writing hate comments into the code! Besides, whenever I write code and it doesn't work, I march right into my boss' office and let him have it! I tell him exactly what I think of his poor leadership skills and that my poor code-writing ability is his fault; not mine! That'll teach the lil bastard.
-- Game Developers: Stop porting badly-textured games from crappy console systems!
I always thought it was the code that was the problem, turns out I just write poor code.
Well, no shit!
Was there ever a time the code was to blame? This is like blaming the newspaper, the actual peice of paper, for spelling mistakes.
From the article: "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,"
I used to think this. Then I realized that at least the developers knew one end of it -- they knew what the software can do. The other end, what the customer wants out of the system, is usually not known by anyone. Not management, certainly not sales, and not the customer either.
A customer with an existing system will often try to write requirements which amount to "do exactly what the existing system does in exactly the way it does it", which is not what they want or they wouldn't be replacing the system. Or, whoever is providing the business requirements will be so out of touch with their own business that the requirements will be incomplete or wrong. Or on the flip side they'll be so familiar with the system that they'll leave out things which are obvious to them -- but so obscure outside their field that no one on the software side will even notice the omission.
Of course, these problems will be discovered very late in the development cycle, resulting in a scramble to redesign and redevelop, a bunch of fingerpointing, mandatory overtime, and a host of other ills all of which lead to bad and buggy software.
No
You get good software from good teams of business people and developers. Every successful project I've been on has been successful because of a good team comprised of users, "business" people, and developers. Add to a good team a good software development process and you have a better chance of success.
...isn't actually the fault of MS programmers? In that case, given that leadership is one of the factors, then I can legitimately blame Bill Gates personally. So that's alright, then.
But I just blame my employees!
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
Suppose I worked at a store where the use a cheap PC based POS ( Point of Sale, not Piece of Shit ) system that uses basic networking, a central database and the basics POS stuff with electronic payments handled externally. Sounds decent you say? The central database was an MS Access 2000 database, the basic networking meant that every cash register would have to use Remote Desktop to get into the "central" database. I doubted the system but because the store was small ( Just 2 POS ) and the Access database itself came across as stable enough. Mind you, we had to log in to Access and use and internally scripted GUI to access stuff. Horrible idea and I never know wether it was a success or not, I worked with that system for just two weeks or so.
However, the point is, that system was also available for larger stores. Now a store with 2 POS I can imagine. I'd guess the system would be decent enough for 5 POS as well, but anything above that would be ASKING for problems. In that case, the software can not be blamed, it is management who should have known better then to use Access related crap.
Never attribute to poor programming what can be attributed to irresponsible users.
Hate me!
The planning and stuff hurts the usability of the program. The UI, the basis of the program itself. Sometimes, it could give rise to Internet Explorer's tight integration with the OS.
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.
A NYC lawyer blogs. http://www.chuangblog.com/
Not surprsing that a CEO would make this remark. I can't count the times I've asked the business community I'm working with for clarification of a business rule or requirement, and then get a 'sigh' or other look that says - "I'm too busy to worry about this".
And on the contract I'm working on now, they consider a 30 min phone meeting enough information to build a full blown app - trying to get documentation is like pulling teeth. And of course we know where the finger will be pointed if there's any issues.
To say we're nerds who don't "get it" is just an asinine, condescending remark; a) I'm perfectable able to learn about the business involved, b) If you explain the rules properly most developers I know have no problem at all coding the solution. I find most of the developers I work with brighter than the business community they're working with. The CEOs remark has a dilbert-like quality to it imo, and this guy's one of the 'experts' on the problem in the article... ha!
'The unexamined life is not worth living' - Socrates
But I still have to try.
Linux? Woops, my mistake. I forgot, EOL for Linux typically runs in the 12 month range.
Sport? So buck passers are Australian now are they? Streth shiela, didja here that? grab skippy and flipper, I am off croc hunting for the savo, they got me riled up, pass me a tinny, and put some prawns on the barbie.
MSNBC report that is isn't the softwares fault, but the person who wrote the software... erm... so this is Microsoft trying to make the masses docile again.
It isn't windows fault that it crashes, but erm, our, because, erm, we have poor planning, poor execution and poor leadership. But our code is top notch! not a security flaw any... where....
the result is 1111x better
The latest OSTG figure is 1111.9x better [sorry gotta be bleeding edge on stats]
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
Don't you mean the horse's a$$? After all look at what comes out of each of them......
- 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.Remember Mythical Man Month?. Again, another news org realizing the importance of stuff written light years ago.
(And CNBC had a slew of business folks yesterday saying how tech was "on the outs" again this year--and that it's construction, oil, and old econ that's en vogue. When your down, they just keep hitting ya...)
The Pittsburgh Post-Gazette has a closely related story: Software disasters are often people problems. 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.
The software works great, but dupes, typos and bias are plaguing the system.
Contrary to popular belief here on /., MS does not hire idiots to write their code
Amen to that. I don't know where this idea that MS doesn't hire skilled people to design and develop software came from, but it's wrong.
It has always appeared to me that MS hires top students from the very best schools.
bhj
Irony would be if MSN(BC) blamed windows. For instance, here they were saying that the problem with the FAA UNIX to windows migration was not software (windows) but the lack of testing and maintenance. They say that the system required regular maintenance (in windows I think this means rebooting) but I am sure there is probably more to it than that. However, I don't see that MSNBC is being Ironic - there is nothing anti-Microsoft or anti-windows that could be taken from this. In fact, it is right on the correct spin factor you would expect. Here they are saying the recent bad press associated with a public outage from a UNIX to windows migration was not a problem with buggy windows but a problem with management of the system.
It is indeed a collaboration. An outside developer cannot step into a business environment and understand workflows and their operational requirements without the customer doing their job as well. So if something fails just as the success of something is shared so is the blame. Poorly conveyed requirements hand off to poorly constructed code which hands off to a poorly tested app which hands off to buggy or clumsy results which finally hands off to an unproductive business environment.
This article shows the results of a lack of career planning & training for managers in IT.
All too often, an IT manager is a programmer whose technical skills were weak or out of date, and so got pushed into middle managment. They then are responsible for making decisions that affect the success of the project. All without any additional training on how to be a manager. It's a situation just waiting for the Peter Principle to kick in.
Everyone agrees that managing programmers is like herding cats, so throwing these people in there without any training or mentoring is just asking for trouble. Sometimes it results in money being wasted. In the case of an air traffic control system, it results in dangerous flying conditions and possible loss of life.
Chip H.
Nevertheless, it's those poor planners, poor executors, and poor leaders who are in charge. You really think they are going to take the blame? No, of course not! It's so much easier, more fun, and better for your career to tell upper management that it was just the programmers who couldn't follow their instructions correctly.
Programmers will then get blamed, the poor managers will get a bonus for "correctly" identifying the problem, and corporate America will sail on as it always has: giving the big bucks to the managers and sales folks, while ignoring the programmers.
Who me, bitter?
Perhaps the software was never designed to be used for that task, so it was still poor management? That's what I would guess...
If I make some application that's never intended to be used in a mission-critical, always-on setting, is it my fault if some administrator decides to use it for that purpose, with disastrous results?
...that's the reason why bad code is written and why systems crash.
.. patch time!
..
:-)
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
just poor planning and a lack of leadership!
DON'T PANIC
Having been on both sides (technical and management) I can assure you the truth is somewhere in between.
...) get a demo copy of a technology and run with it, proclaiming how the new software is close to the second coming, the manager looks at it and takes the word of the technical staff and voila, instant gulf in knowledge created.
You're right in that often technical managers don't have a clue about the technology being implemented and often "manage what they know" and force programmers into coding inside a new platform using methods the manager once used in an old platform.
That said, I've often seen programmers (and network administrators, and DB admins, and
Why? The manager's juggling two balls, one of learning (and actually) managing people and projects, as well as trying to keep up with the latest technology.
And as you move higher up the management chain, the less "hands on" time you have with the actual technology, and the gulf grows wider between what a manager knows (or knew) and the actual details of the technology they are being called upon to manage.
So, it does cut both ways. It's as much the programmers responsibility to "educate" the manager on new technologies as it is for the manager to "learn" them. Remember, managers don't have as much "keyboard" time as you do. Cut them some slack.
"We're sorry, but the website you're trying to reach has been disconnected."
The article is a bunch of malarky. Well, I suspect it is, but i stopped after the first couple paragraphs, after I read this:
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.
Yeah. That maintenance they failed to perform? It was their mandated once-a-month reboot of their windows system, because it locks up after 43 days.
This was the result of bad programming.
Anyway, as a QA guy, I can assure you that bad programming abounds. It's my job to make sure you never see it. Part of that job is trying to drill into programmer's heads the concept that performing to spec when used as directed is not sufficient.
This is just like television, only you can see much further.
IT budgets are still shrinking....
We need to hire MORE managers.
Considering that you deal with users who don't really know what they are doing in the first place I would have to place the majority of the blame on them. However you could also retrospecitvely place the blame on IT for not having the systems locked down in the first place but then you would have to blame the CEO and the board for not putting more technology in the budget. Yea we won't go there.
They bought a Yugo (windows) to do the job of a truck (UNIX). The Yugo needed more maintainence than the truck, and they had an accident. They fired the 'state of the industry' execs who decided to replace trucks with a Yugos. This is actually good news, in a way. Now all they need to do is get the trucks back.
Hmm... I wonder if the execs running nuclear power plants have finished installing windows to run them....
Better yet, we can put windows in charge of the ICBM fire control systems. We'll be *so* state of the industry.
Last week, my WinXP box locked up in the middle of a game. It was so bad, smoke poured out of the case. The software, probably WinXP but maybe the game, had overused one of the RAM modules so hard that two of the leads were charred black.
%^$#@& SOFTWARE!!!!
I've always wanted to design a system that gets nastier every time a user repeats an error.
In the generic sense, it would start with "Could not do xyz. Please check what you intended to do and try again."
Then, it would progress through "I can't do that. Try again." "You're starting to wear on my nerves. Can't you do anything right?"
Then, it would start to get more down to the source of the problem, beginning with "DOES NOT COMPUTE" and ending, finally, with "You fucking moron, my program works, read the manual before i cut you."
Stupid users always bothering me with crap.
ACs are modded -6. I don't read you, I don't mod you, I don't see you. Don't like it? Don't be a coward.
It's the same in software land.
No good saying "it's windows fault for requiring a reboot every 49 days" when IT IS YOUR FUCKING FAULT for picking the WRONG TOOL TO DO THE JOB!
I see this everywhere nowadays, and it all boils down to everyone trying to evade personal responsobility for things that they are involved it.
Fuck it, not my fault, must be someone else's, so lets sue them.
Oh look, my lawyer agrees with me that I have a case so I MUST be as innocent as I claim.
bullshit.
http://slashdot.org/~GuyFawkes/journal
I had to follow your link, as I thought you were referring to Peter Gibbons from Office Space. That seemed appropo as well...
In my opinion, it's not an administrator's job to frequently find his/her way to actively prevent problems, that are actually caused by poor software design. It's the job of the software designers and/or programmers, to provide administrators and users with robust and reliable software.
A program, that by design frequently causes a problem that makes it unusable/unavailable to users, is poorly designed.
You see, the $ replacing the S's in the words means that Microsoft is a buisness that tries to make more money than it spends. This implies that it is evil, as every buisness should be losing money, inorder to screw the stockholders and employees out of their life savings. Well, I guess your brillant commentary on the evils of money and awesome display of your creative use of the $ has proven whatever point you were trying to make that hasn't been repeated 50 times before. Truelly, you are our savior. Please, Tell us more about you that we might worship our god better!
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.
My Windows (even when I ran ME) has always been very stable, (comparatively).
I can go weeks without needing a reboot, I can run the programs that everyone else say are buggy. (FarCry on my ATI, for example)
My Father who has a PC that was a clone of mine has nothing but problems and his computer self destructs constantly.
I've always likened it to a horse. "If you show fear, the horse will take advantage of it, but if the horse can tell that you are confident and in charge, it accepts that at behaves." heh.. something like that.
--Welcome to the Realm of the Hawke--
One major thing that comes inbetween coding near-perfect software (Perfect software is never going to be possible) is also the demand the customers place on the team.Of course, they know very less about the technology and so cannot blame them totally.
/. stories
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
I was under the impression that Microsoft used the cycle design pattern (based upon a 3 month cycle IIRC) wherin the product was ready to ship at the end of any cycle (in case the competition was about to release their version). When did this change?
"Disasters are often blamed on bad software, but the cause is rarely bad programming.
In 90 percent of the cases, it's because the implementer did a bad job, training was bad, the whole project was poorly done," said Joshua Greenbaum, principal analyst at Enterprise Applications Consulting in Berkeley. "At which point, you have a real garbage in, garbage out problem."
Can we stop with the splitting hairs here??? You're saying that problems are rarily caused by bad programming, then turn right around and cite poor training and the whole project just being shit. Crap in, crap out. 'Out' being bad programming maybe? Just maybe? Due to bad training? An overall botched job? Not saying it's entirely their fault, but lets stop with the Dibert style of news here.
You need a FREE iPod Nano
"Microsoft owns MSNBC, so this is clearly an evil plan to blahblahblah.."
Actually, now that I think about it, that's probably closer to the truth than anything else...
Not a Twitter sockpuppet... but I wish I was.
Management pressure.
"/Dread"
Like any good Philosophy 101 course. Be like watar; become the cup. Garbage in, garbage out. Virus in, virus out. Worm in, worm out.
Poor training is a valid cause. Not everyone is an engineer; there are still peons in this world.
I blame God.
This is why Free Software tends to be more secure. The project managers tend to be programmers, not non-techy businessmen. They understand the concepts of "still needs work" and "not ready yet" even if a product is late. Commercial software vendors would rather release a program on time and hide any last-minute security flaws that pop up (to be fixed in some patch, which is perhaps another profit generator). Open Source projects, lead by the programmers themselves, will usually prefer to hold back a new version if they feel it's not reliable enough for release. Besides, that's what developer versions are for.
If it weren't for fog, the world would run at a really crappy framerate.
We have a user here that sent out an e-mail to 30 people that were definitely not supposed to get it. This came about because she opened up a distribution group and was pulling out the three names from that list and adding them to the e-mail message. But in the process of all of this, she also added the group as a whole (double-clicked to open it, even though that adds it to the message, but a button opens it to retrieve names).
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.
There are some odd things afoot now, in the Villa Straylight.
IF you are not actually finished with the project, and your ninnyhammer PHB responds to any sentence with "I'm finished" in it, why on earth would you ever use those 2 words in any sentence. That's a programmer fault for sure (because they CHOSE to set the PHB "finished" flag).
I'd love to help you out -- which way did you come in?
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.
I boycott signatures
When non-tech people manage a tech area, they don't necessarily know what information to give or what parameters are important. It wasn't an engineering or manufacture problem that caused the Hubble to be "near sighted" when it went up. It was a program manager that didn't take into account that if you give Americans an engineering job, there is still a strong likelihood that they will use the Imperial or English system to do it in.
No, it wasn't poor maintenance that caused the control tower failure. The maintenance guy was "improperly trained" according to the reports. That is, the manager explaining the duties didn't tell him what he had to do and why. Of course, he had a maintenance task solely because of poor programming...
And many security exploits are from poor input checking. Is that because the coders don't know how to check input? Or is it because the project managers don't specify acceptable inputs, so the programmers have to allow for anything in order to not exclude valid inputs?
Learn to love Alaska
This research is especially relevant to electronic voting. The latest news of Diebold insecurity, for example, shows that the counting server insecurity allows an operator to switch the secure counter to an editable one for the official count, using a hidden field in the GUI. That serious defect was apparently introduced right after a convicted embezzler, with outstanding blackmail liabilities, was hired by Diebold at the top of their programming staff, in a position to introduce and retain that hole through several revisions of software and notifications of its retention. Apparently adequate programming in the service of truly bad management.
--
make install -not war
And judging by the NullPointerException, it sure as hell *is* bad programming :)
Oops, sounds like they didn't rotate the logs.
Yeah. That's rich coming from Microsoft ...
A mission-critical system should be interrupted exactly when you want, not on a schedule dictated by a calendar. The original "BS!" poster was right: if there are memory leaks, garbage collection problems, etc., then that's evidence of sloppy design work.
Saying you need regular reboots is the same as saying you need a firewall to protect against viruses: both show flaws in the design of OS.
And as far as "fscking their disks every day" goes, that's more sloppy design. You shouldn't have to do that. Fsck fixes file system errors resulting from poor application behavior, environmental problems, and (sometimes) hardware troubles. You shouldn't have those every day in mission-critical systems, but even if you do then putting in place a system of daily fsck is not the way to fix it.
I've had a production application server running for the last 288 days. It's due to come down for OS updates, but it will do so on my schedule, not because its operating system is poorly designed.
sigs, as if you care.
You didn't get what the article said at all did you? It was the people who failed here, not the software. Bad planning and performance of the people. You seem to look for any crack you can find and stuff a 'Caused by Microsoft' flag in it. There are things that MS can be blamed for, but when you poke EVERYTHING at them, your arguements lose their validity. People implementing, setting up and managing the systems are the problem more often than not.
Whee, good old IT, where everybody wants to take credit for the good stuff and blame someone else for the stuff gone wrong.
It's NOT the management, it's NOT the programmers, NOT the admins, NOT the testers. It's the whole fucking group that doesn't want to act as a group. The problem is people don't listen to each other, managers don't listen to programmers but just as badly, programmers don't listen to managers. They each talk in their own language and refuse to learn the other's.
No... The blame is on EVERYBODY, because nobody wants to talk and co-operate with the people in the other "camps".
Recognizing that free alternatives to Microsoft have a lower pain of ownership does not make a person "radical". Remembering that Microsoft has sued public school systems, paid people to lie and disrupt "competitor's" discussions, PR firms to forge letters to public officials, and routinely breaks other people's software and blames the victim takes nothing more than a brain with a memory. You might not like what I say, but I don't see much reasonable refutation.
Free software works, M$ does not, the details are less important than the big picture. Here are my answers to your little quiz and a question of my own:
1. Who most likely wrote the software? A) Ground-breaking AI B) People C) Monkeys
People. They write free software that works too.
2. A user always reads and follows instructions. A) True B) False
The software should work anyway, like Knoppix does.
3. Windows' registry was designed for software protection. A) True B) False
I don't care. It breaks the system.
4. Which OS is the most compatible with today's hardware market? A) Windows B) Linux C) OSX D) Other...
Linux. Once free, a driver lasts forever. There are now more devices that run under Linux than any other kernel. Just look through any company closet for the pile of devices that made "obsolete" by an OS upgrade to know this is true. You can also look at the number of ports to different hardware. FreeBSD does that well, but it does not have the device support Linux does.
5. Name one piece of software that is perfect: ______________________
Any software that has been qualified for nuclear license evaluation. It's amazing, you can write complex software that does what it should and is verifiable.
6. In windows, you can turn off a screen saver. A) True B) False
Sure you can, until a service pack turns it back on. Who cares? The thing still has uptimes of less than a week and is prone to worms and full of bugs.
7. Microsoft _tries_ to make their code better. A) True B) False
Failure: when your best effort is not good enough. They don't have the time or resources to compete with free software. No one does.
Here's a question for you. The Bill Gate's method of software creation, stated here is:
A. Wrong.
B. Obsolete.
C. Greedy.
D. Stupid.
E. All of the above.
Long live M$ BASIC. Opps, they are pulling the plug on that one for .NET
Friends don't help friends install M$ junk.
In my experience, coding (understood as feature development) is but a small fraction of the man hours spent on creating a piece of software. And it should be that way. I agree totally that if because of bad management a project spends most of its time on coding, then it will be bugridden or completely broken. And it's not the code's fault.
There are two things which spell good software: thorough and precise requirements and testing. A lot of time must be spent with the clients (and/or by the engineering team) to define exactly what the software is supposed to do. Creating prototypes and documenting use cases (or business events, etc.) is essential for the success of an application. Otherwise developers will spend half their time thinking "should the software do this or that" and in most cases they will improvise something which the client doesn't want. With good requirement specifications, the design and coding is almost a breeze. Finally testing the whole application not only for code bugs but against the requirements is essential. Without proper testing you can have no confidence that the software (a) works, (b) does what it's supposed to be doing.
Microsoft says: It's not the software, blame your boss!
OK let's hope the guys at Redmond do what they preach! ):D <-- evil face
There's three general areas that can cause a failure in a software system.
1. Bad requirements.
2. Bad design.
3. Bad implementation.
The programmers generally have good control over #3, but even if they keep all the "*/wow I am so drunk" out of the code, and implement every line according to the design, the system can still fail horribly.
Programmers may or may not have control over #2. Design elements that make the software inherently unstable or insecure can be imposed from above. Dependencies on other software packages that have their own flaws can bring you down. Trying to use a component that was designed to handle a user's own files to display an untrusted document off the Internet is a classic example of bad design.
And the requirements can impose a bad design on the system. "You must develop for this platform" or "you must develop in this language" or "you must depend on this program and not our competitor's".
There is a line between computer "users" and the developers.
In no circumstances should a 'user' be the one who directs the developer. All that's needed from the 'user' are the requirements.
Most of the managers are these "user" who think that because they can run cracked versions of software, they know computer science. Heck, I've been told bluntly, that they aren't looking for computer science solutions to building the software (I'm a CS grad myself.)
What they don't understand is that nearly all the problems they face now are precisely because they didn't have a CS person doin the work.
In my previous job, the boss was a CS grad, and never did we face the kind of issues like here - simply 'cos they account for every possibility in a logical way, rather than a "hey, we need this feature, let's have a checkbox here, and if the user checks it, they get taken to the new feature".
Idea #1: specialize.
60M transistors in a CPU, billions in RAM, 200M in
the videocard, and they all work great! Why? Because your RAM is just RAM. It does it's job, so it can do it's job extremely well.
Idea #2: assume the user is going to do the dumbest thing on earth.
You can buy USB sex toys, coffee mug warmers, and light up ducks. If you f' up the wiring on a USB port, you won't blow the port, and the OS will most likely never see the device.
Idea #3: assume the user is going to try to hurt themselves in the process of doing the dumbest thing on earth.
Take a look at your PC, consider the number of ways they've protected you against hurting yourself short of dropping it on you. Where does your finger fit? Pretty much nowhere. There's some high voltage in your PC, as well as high current. But you can't get to it.
Idea #4: have a plan, and get people that can stick to it.
There is a new videocard generation every year, and a sub-generation half way through the year. Don't tell me that short deadlines are impossible.
Idea #5: standards are there for a reason.
UL, ISO, CE, and other standards are in place for safety. In the end, they help designers know what NEEDS to be there. Going off and saying "it doesn't apply because we don't want it to" doesn't work.
Idea #6: your compiler does not check for a bad design.
No amount of CAD programs will check to make sure that the engineer at GM put the pedals in the right order, that's the engineer's job.
Idea #7: take responsibility.
In the end, most every hardware engineer knows that they are responsible for making sure thier design works. Most feel quite bad when something goes wrong and usually spend long nights finding the best fix.
Idea #8: if it's advertized as secure, MAKE SURE IT'S SECURE!
Kryptonite locks are being replaced at the manufacturer's cost. Anyone wanna bet how often this is going to happen again? I'll give you a hint, it's not the 2nd tuesday of every month.
If you think education is expensive, you should try ignorance -- Derek Bok, president of Harvard
I had to manage to check whether the time of day had changed from midnight to the next day. It was a TINY CHECK ROUTINE!!
I don't understand how Microsoft couldn't have done that with their OPERATING SYSTEM.
Let me repeat.
*Clears throat*
*mi mi mi mi..*
*Tests echo*
It was a _TINY_ CHECK ROUTINE!!!!!
I have a boss who is an absolutely horrible programmer. He has talent but has some technique problems that really anger the rest of the team.
For exmaple:
A. he never follows our coding conventions or uses our libraries. He always writes his own libraries that do the same thing even though we ask him not too.
B. He never uses descriptive variable names. In fact, he will use only 1 letter variable names, namely, i, j and k.
C. He never comments a sigle line of code.
D. He never lines up curley brakets
E. He will have nested if statements sometimes 15 to 20 levels.
F. He writes functions thousands of lines long that duplicate tons of code.
G. He never checks user input. For example, if a textbox asks for an IP address, just put in the name "bob",and you can crash the whole application.
H. His excuse is "first get it working, then get it working right". the problem his, he releases this code as production code to our customers.
Recently, I had to spend a month away from my family out of the country rewriting all of his code, every single line. I removed all he dupicate libraries and brought everything into the step with the project.
We have tried to talk to him but he won't really listen. He says we are babies and coding conventions are for pussies. He says he never needed any of that stuff with Fortran. He is constantly trying to get involved in writing code but people would rather stay late and work rather than have him do anything.
Should I go above his head to his boss?
The report I read stated that the "data overload" was caused by the PC, which was running Win98, needing to be rebooted every 30 days because if it wasn't it would crash at 49.7 days, which is what happened.
The 49.7 day crash is caused by Microsoft's 32 bit millisecond counter filling up (which takes 49.7 days) and crashing the PC.
Was media reporting it as a "data overload" the results of Microsoft influence or reporter stupidity?
...do it the BOFH way and arrange for him to have a little, *ahem*, accident in the server room.
I am NaN
Okay, I'm missing something here. The article is saying not to blame the software for being bad, but to blame the people who made the software bad? Isn't that by default what any fucking intelligent person does, is blame the ass who made the software? If my car breaks down, I might scream at my car for a bit as therapy, but I ultimately blame the manufacturer for the problem.
Or maybe I'm not any fucking intelligent.
"All great wisdom is contained in .signature files"
I only partially agree with this statement. Software of MS provide such magic traps that programmer is bound to commit mistakes. And I thought that MS Softwares will be better now with .NET, but the trend continues
Yeh, look at Duke Nukem forever....
tm
Support TBI Research: http://www.raisinhope.org
This is a reoccuring problem all over the place in the industry. Management and the board see no capital value in the Design or Implementation or Testing phase of product development so therefore it has lower priority than things like Support. Management continues to see the entire process of Software Engineering as a "list of stuff to do to create something" instead of a continual process.
I've seen this all too often: management demands we must have something out the door even if engineering discovers a serious flaw in the current design. I'm not saying that management should always bend to engineer's time lines but it seems that almost every medium to small company has it as a "one way street".
This is really why software fails. The engineering team is just not sure the stuff works right but management sells it anyway.
"The Mythical Man Month" should be required reading for every six figure mouth breather out there. Of course, it's thicker than "Who moved my cheese" and can't be purchased in an airport gift shop, so I suppose there's no hope...
*** Sigs are a stupid waste of bandwidth.
I agree that none of this would have happened if the guy had rebooted the system, but that's like blaming somebody for tripping on an uneven sidewalk -- the sidewalk shouldn't have been made uneven in the first place.
The real problem has nothing to do with Windows; it lies in the fact that somebody decided to assume that a 32-bit integer used to store the number of milliseconds since the system was started wouldn't roll over to 0. Of course Windows will readily provide you with that information, but that doesn't mean you should write a program that would endanger peoples' lives if you misuse it!
The real problem here was the management. Even if the programmer didn't understand what he was doing, there should be risk-mitigation processes that audit code to figure out where and how they could fail. When they come up with "will fail ever 49 days" and decide the solution is "reboot before 49 days", it's clearly management's fault for accepting that.
Alternatively, you could wonder why a radio system would critically rely on the number of milliseconds since the system was rebooted. Management should have never allowed that in the first place. ANY 32-BIT MILLISECOND COUNTER WILL OVERFLOW AFTER 49 DAYS! If they really needed hi-res intervals, they could have used QueryPerformanceCounter() (a 64-bit counter from a 1.19MHz timer chip) or a couple other similar methods. Odds are the programmer just didn't feel like dealing with 64-bit ints.
Again, management should have understood the implications and made sure this didn't happen. If the programmer didn't know any better, management should have hired a better programmer.
aQazaQa
the system had to be rebooted every 30 days because of bad software. namely the os had to clean itself up. now to me that is bad software - they had unix before and probably never touched it and it just worked. what an upgrade.
The assumption that MS hires "idiots" is unfair to be sure. However, those in the know who have seen some of the colossal kludges in MS software, and recently almost all Windows users who have been impacted by the repeated, massive virus/worm attacks base their knowledge on the only thing they know about Microsoft--their products.
It has always appeared to me that MS hires top students from the very best schools.
That is true--unfortunately they have been known to hire them AWAY from the best schools too (ie. before they graduate). It doesn't matter if they are top five percentile students--if they have zero practical experience and are thrown into a situation beyond their capabilities the result can be less than ideal. Nonetheless, I think that by now MS has figured out how to select and place recent grads and students hired before graduation. I think the problem is now deeper than that.
Microsoft triumphed over other tech companies that were prominent in its early days because BillG learned it had to become a marketing company (the same reason Apple still exists today--Jobs knew that from the start and Gates is a very quick study). Other tech companies remained software companies--they toiled away to make their next killer app the best it could be and marketing was an afterthought.
At Microsoft, from 1980 on at least, has been a marketing comapny first, with software development second. The most important technology it markets was invented elsewhere and merely extended by Microsoft. Only in the company's latter life have they been truly serious about research. The long time "thinkers" are brilliant but historically little has come out of Microsoft's research that has been commercially successful given the potential funding power MS has had.
Therein lies the problem. The article is right--software isn't the root cause of the vast majority of failures (even when the failure is the direct result of a software bug). At Microsoft, software design is driven by marketing--time deadlines, customer requests for features, backwards compatibility/legacy support etc. The result is the house of cards we build our systems upon today.
That result is unavoidable without EXTREMELY skilled planning and throttling the pace of change. Unfortunately, The MS Ship sails where the winds take it, and the pace of change has been rapid and relentless until now. I once thought the problems with MS products were because too many drop-outs were running the show. After seeing this blog I can see what the development teams have had to cope with. They have to do the impossible and try to get it done before the deadline slips yet again and MS market cap slips a few million and BillG comes down to yell at them. In some cases you have to be brilliant just to survive at MS.
So anyways, I think software bus are the immediate cause of a lot of disasters, but the ROOT cause definitely is poor planning and project management that leads to unstable system development.
ERP implementation 1: At this place, there was something, let's call it the TPS report. It was supposed to be an automated replacement for a number of things that were manually generated from database extracts and number crunching. So, an interview with, oh, let's call her Suzy goes something like:
Me: so why don't you use the numbers from the computer?
Her: they are wrong, I use the spreadsheet from Fred instead.
Me: so what is wrong with the computer numbers?
Her: If I use the numbers from the computer, then the TPS Report will be wrong.
Me: so what is wrong with the numbers in the computer?
Her: well, the sales guys all get commissions based on what is in the computer, but that is not what actually got sold. Jeff places orders for customers, and the customers send it back for credit (called channel stuffing). So Jeff gets credit for the sales, but not penalized for the returns. And the VP, Ed, he just makes up numbers to meet the monthly quotas.
ERP implementation 2: At this place, the (mis)manager, let us call him Bob, decided that he wanted to keep 4 sets of books. Set 1 was the one that the IRS got to see. Set 2 was the one that the board of directors got to see. Set 3 was the one used to show to investors and the stock market. Set 4 was the real set of books. I told my boss that I wanted nothing to do with this Enron-wannabe. I won't work for SPECTRE, nor will I work for Enron. I had to quit to get away from the project. I understand they wasted over $8,000,000 trying to implement this evil piece of stuff. And they never understood why the numbers did not match. There is a solid reason for Sarbanes-Oxley, there are still a lot of companies who succeed at getting away with this sort of business.
As long as the people putting bogus numbers into the system had more political power than the people putting the computer system in place, the system was never going to work. Corruption and cronyism are not exclusively endemic to government. Most programmers are naive, they lack an understanding of the power that politics have over the way that work really happens. Stuff like the above 2 samples are why older programmers are cynical and sometimes bitter.
If you hear of a "failed" implementation of some ERP/CRM system, dig deep enough and you will see things like the above samples.
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.
Read the EFF's Fair Use FAQ
No, obviously the CEO needs a raise.
"Be silent, program! Or you'll be killed!"
There you are, staring at me again.
As a contract software developer, the client calls all the shots. If no matter how many times I explain that a properly designed system will be faster to build, cheaper to build, and be more stable when finished. They still seem to think that the phrase "Go ahead and get started, and I will get back to you on what I want." works nowadays.
Currently I have a client who does nothing but come to me with a revolving set of requirements.
Client: "Oh I just thought that this would be a nice feature."
Me: "Yes, yes it would. But would require me to spend 1 or 2 months to rework that into the design and make sure it works. BTW, when is the system going to be used?"
Client: "Two weeks from now."
Me: "Ok then we work it into the next version then."
Client: "No, no go ahead and get started on it and I will get back to you."
Me: "You know that it won't work in two weeks then?"
Client: "Why not?"
.
.
.
Me: "Well its your money, whatever you want. I will see what I can do."
-Two weeks later-
Client: "Is the system ready to be used?"
Me: "No."
Client: "Why not."
Me: "Well, you remember..."-interupts-
Client: "Oh I have an idea what about adding this?"
What the client wants he gets. And when its crap thats what he gets. He wants to pay me for it. So be it! I have to fund my own projects somehow.
- my $.02? - you can't have it...it's all I have!!
They knew the theory but getting an actual working website was beyond them. I don't know if this also applies to "real" programming but I can imagine there is such a thing as to much theory not enough practice.
I also did some work in backend systems and there I could spot a definite lack of real world experience in the IT people that had years more IT knowledge then me but no experience as an end user of the systems.
Simple example, one system had a query to tell you where a product was stored in the warehouse so if you where stocking it or taking it out it worked fine. However in real life sometimes things go missing and it would be nice to know exactly what was is supposed to be in location X. The system did not support it. The IT guru had never been in a warehouse and had never thought of the situation where it was required (like say someone knocking over the containers (english word for it escapes me)).
Very recent example? Order picking. To pick an order consisting of 1 article it took you maybe 20-30 seconds to pick it, that is after a 3-4 minute wait to get the order. And that is if there weren't to people requesting a new order or both would get the same one and one would have request a new one.
Also the system happily produced orders to be picked for customers with blocked accounts.
The software itself worked well enough. The design behind it SUCKED. Once again, I a self thaught moron with a bit of coding skills had to improve on the work of a university graduate.
Hiring top graders is the lazy way out. All grades prove is that you did well in school or to be more precise that you have learned well to give the answers the teacher wants to hear. It had little to nothing to do with how well you will do in real live.
Wouldn't bad management (or whatever) still translate to bad coding? The coder's themselves may not be at fault, but the code its self is still a problem.
If you want to know what a true fiasco is like, just Google "CoreFLS" and read the results.
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. 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. 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.
It would appear due to twitter's responses that he
A) Doesn't know basic computer knowledge and
B) Doesn't Care that he doesn't know.
Check out: Anatomy of Insanity? for more on Microsoft's warped "values"-based thinking.
Seems that what the article is saying is that poor programming comes from a lack of business process analysis and programmers talking to customers directly.
Which describes Microsoft completely...and to a lesser extent, any given offshore outsourcing company.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
To paraphrase Field Of Dreams (1989) I say software development can be as simple as:
If you can 'see' it, you can code it.
Let me explain.
If you are a good enough programmer and intimately familliar with your programming tools, and have a library of small bits of 'single-purpose-single-function-like' code that has been previously proven to work, you can literially 'build' a correctly working program according to the design specifications in a short amount of time with NO need for flowcharts or other non-productive busywork. Just add the program documentation to the program itself as a comment block. In lieu of a flowchart, comment the program profusely so it's method of operation is clearly known to all who read the source code for it.
If you cannot 'see' it, you will have difficulty as a programmer because it will be difficult or arduous for you to grasp both the 'big picture' and the 'fine detail' required for all non-trivial computer programming projects.
Sounds to me like you are trying to sit on both sides of the fence. When you buy Half life two and it runs like s#?t on your PC because it needs better hardware to run on, are you going to blame the coders again? Even the most excellence code has requirements that need to be met for the code to run optimally. It is more often the implementors fault for trying to 'save' and scrimp on hardware or other items that hobble the code's ability to perform it's task. More often than not, as a coder myself, I find myself trying to add code to overcome the problems caused by people not following directions. If I write code that uses a AMD64 instruction set and I require it and someone installs it on a pentium4 PC, is it my fault it didn't run or the person who couldn't follow directions and read the software requirements. Now tell me what the difference is between reading the software requirements and the instructions on it's proper use. There aren't any. People think they can take their lawnmower and trim their hedges with them and end up in the hospital all of the time, (or dead). I suppose you are one of those people who sue the lawn mower manufacturer because it was their fault somehow.
More like, the plane was known to continuously leak oil and/or other safety fluids to the point where it became dangerous or unreliable. They could have either replaced the plane or fixed the problem for greater cost, but chose to ignore the problem until one day missing that critical oilchange caused a near crash.
This isn't about a standard maintenance procedure, since a server should not have to be rebooted constantly in order to maintain. stability/functionality. That's like saying it's ok to swap the oil every second flight because it's cheaper than fixing the actual problem (that there's a leak in the first place).
And actually, considering that many earlier windows problems were caused by memory leaks... not such a bad analogy now...
I hardly ever see good code being written.
I have worked at a couple of closed-source firms, and the code was horrible. I have looked through many opensource projects' code, and most of the code is bad to horrible.
I have seen very little good code in very rare occassions.
I do blame bad code for failure, but maybe my standards are just too high.
...obviously, the CEO needs a raise... Slashing costs is a good way to get a raise.
Sure, let's change the oil during flight to correctly put in your analogy.
Moron.
Life critical support functions in the airplain should NOT go down at any time, for any reason due to "maintenance" or "standard procedures". That's like shutting off the engine.
Back in the late 60's and early 70's Texas Instruments started hiring lots of new college graduates to help them stay abreast of the latest technology. The object was to put them on a project with lots of unpaid overtime, work them at new-hire salary for four years and then, if they didn't leave on their own, gently "boot" them out the door and hire fresh, new replacements. After four years and lots of unpaid overtime, a lot of well trained engineers were ready for better jobs at other companies, taking TI's technology with them. TI trained a lot of engineers. By the mid 70's they realized what was happening and the policy was reversed.
And here I was worried about them being all biased and stuff. Good to know I was overreacting.
Why yes, I AM a rocket scientist!
5. Name one piece of software that is perfect: :( ;)
Hello World! At least it was, until I added a routine that asks your name, and it buffer-overflowed.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
The point of the article is to draw attention away from the fact that once again the love of PHBs for Microsoft has eclipsed other concerns. The two key paragraphs are near the end:
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.
By most accounts, the move went well except the new system required regular maintenance to prevent data overload. When that wasn't done, it turned itself off as it was designed to do. But the backup also failed.
In other words, a working Unix-based solution was replaced by a dubiously reliable Windows-based version. The phrases "regular maintenance" and "data overload" are not very descriptive, but a more technical summary,
The servers are timed to shut down after 49.7 days of use in order
to prevent a data overload, a union official told the LA Times. To avoid this
automatic shutdown, technicians are required to restart the system manually
every 30 days. An improperly trained employee failed to reset the system,
leading it to shut down without warning, the official said[,]
makes the issue clear. Unix-based solutions do not require being restarted every 30 days to avoid "data overload". Unix-based solutions could restart automatically if they did. The question people should be asking is: why was an obviously defectively designed system allowed to replace a working system. Doing so put 800 planes worth of lives at risk.
I am wasting brain cells reading more propy from msnbc? The "software" on the airport problem was Microsoft and i'm sure was related to the company as well :(
(TROLLING)
You didn't get what the article said at all did you? It was the people who failed here, not the software. Bad planning and performance of the people. You seem to look for any crack you can find and stuff a 'Caused by Microsoft' flag in it. There are things that MS can be blamed for, but when you poke EVERYTHING at them, your arguements lose their validity. People implementing, setting up and managing the systems are the problem more often than not.
Actually, there are two sides of this failure. One, a software vender consistantly producing bad software. Second, people not setting standards relative to their own needs. Instead, standards relative to the perceived marketplace were chosen as criteria, rather that standards relative to what they actually needed. Uptime isn't very important in the marketplace, obviously. Uptime should have been to an airport. Or a nuclear powerplant, or a missle fire control systems,
Systems the *need* to be rebooted constantly when there is not real problem have some other kind of problem. Systems that come *out of th box* that way have an even more serious problem.
So, just limiting the issue to the people involved is a narrow way to look at the problem.
Twitter, you're a petulant cock-gobbling sycophant to Linux Torvaldyos! Quit taking DP from ESR and RMS's feculent cocks and why don't you try to stop sucking quite so much? Get out of your parents' basement and see the real world - maybe then you'll see how pathetic you sound, with your neverending stream of bullshit about how Microsoft is stalking you. Wasn't it you who said that Microsoft believes your insane ranting is actually a threat to them, so they PAY PEOPLE to reply to you on Slashdot? No sir, I don't get any money. I do it for the love. Someone has to go up against your paranoid whining. So get back in your cage and shut the fuck up already.
Twitter, you're a petulant cock-gobbling sycophant to Linux Torvaldyos! Quit taking DP from ESR's and RMS's feculent cocks and why don't you try to stop sucking quite so much? Get out of your parents' basement and see the real world - maybe then you'll see how pathetic you sound, with your neverending stream of bullshit about how Microsoft is stalking you. Wasn't it you who said that Microsoft believes your insane ranting is actually a threat to them, so they PAY PEOPLE to reply to you on Slashdot? No sir, I don't get any money. I do it for the love. Someone has to go up against your paranoid whining. So get back in your cage and shut the fuck up already.
I think the more fundamental issue is that nobody really knows how to properly design large scale software projects successfully. The whole concept of software development is extremely new in terms of any sort of science or engineering study.
If there was reliable and tested evidence and procedures about how to design and develop any software perfectly and effectively, you could bet that people would be doing it. There are things that definitely work and they often get ignored or looked over, but that's as much because the profession still hasn't developed enough to know who should be in what places, what they should be doing and how they should do it.
This is undoubtedly one of the reasons why so much software is built in such dodgy circumstances, because realistically nobody accurately and decisively knows how to do it any better with formal and properly tested evidence. You can certainly argue that programmers doing it themselves could produce a better product, but there's still more to the process than simply developing a product that doesn't crash. It has to be the correct product, it has be sold to someone (usually), it usually has to be done on time, there's normally money involved and often lots of it.
We're still in very early days, but hopefully it'll improve over time. Don't be surprised if it takes on the order of decades rather than years, however.
Twitter, you're a petulant cock-gobbling sycophant to Linux Torvaldyos! Quit taking DP from ESRs and RMS's feculent cocks and why don't you try to stop sucking quite so much? Get out of your parents' basement and see the real world - maybe then you'll see how pathetic you sound, with your neverending stream of bullshit about how Microsoft is stalking you. Wasn't it you who said that Microsoft believes your insane ranting is actually a threat to them, so they PAY PEOPLE to reply to you on Slashdot? No sir, I don't get any money. I do it for the love. Someone has to go up against your paranoid whining. So get back in your cage and shut the fuck up already.
75% of the crashes that occur in every corporate/business environment I have participated in, are due to poor programming. Many crashes are literally scheduled for. Every heard of Mail Order Manager, Starship, and the literally millions of apps sold to small to medium businesses that fit their budgets more than their needs? Of course not because they are crappy software that fit a niche (cheap and "full o features" that may or may not work). The study is bullshit. I call it like I see it.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
I used to write code for a small company that directly competed with SAP in a niche market for particular activities of (often small) governments. It was started and run by some former government employees who knew what they were doing from past experience inside out.
Every time our marketing consultant came back from overseas, he'd be ranting for days about how moronic the SAP marketers were and how unsuitable their product was. This wasn't market-speak, it was coming from an expert in the business who'd taken on a marketing role in a small company. SAP would attack government officials and essentially shower them with FUD and aim to sell them a system that was 10 times bigger than what was actually needed and one that didn't really do the job.
Because there were often small governments and didn't always have the necessary expertise, they'd often simply cave in to SAP, pay millions of dollars and regret it later.
The SAP quote in the article might be right in that they needed more SAP consultants to help make a big transition to using SAP software. I wouldn't doubt it for a second. On the other hand, SAP probably never developed the software appropriately in the first place for what was actually needed.
-- but the FAA maintains there were no "near misses."
Bwah?.... You mean ALL the planes crashed into each other and not a single one missed any other?
Wow..that's got to be the worst aviation disaster in history. Funny, I haven't heard anything on the news about it.
Fucking Windows 98!! Get Bill Gates in heah!
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
..to validate a business requirement"
This is an incredibly stupid thing to say. Programmers may not be the best people to determine if a requirement is CORRECT but they are certainly amongst the best people (probably much better than the BAs) to determine if a requirement is VALID. The BAs tend to be remarkably good at devising specs that have giant logical holes. On the other hand, an experienced developer is going to almost instinctively spot those areas where the requirements just don't parse. I have personally had several occasions where, after looking at a spec for less than a minute and with only slight exposure to the underlying business, I been able to identify the approximate location of a "project doomed" level flaw. Typically it then takes me about a day to fully understand the nature of the issue and about a week get the BA to understand it too.
There are three options in the design of a system:
- How the boss would do it
- How the developer would do it
- The way that actually works
Choose two.now we need to go OSS in diesel cars
"If your Windows XP crashes, it's *your* fault, not ours!"
Chris Mattern
The symptom is: Inability to heed recommendations.
When the send this work into 3rd world countries and the quality level is down what can you expect? They dont care about a quality product. I quanity not quality in this day and age.
People are completely to blame. Whoever at microsoft decided it was okay to ship faulty software and tell everyone its good, and the fools who believed them.
this article is just a spam press release sent by iTKO.
That's so much my last employer. Hire 'em green, and work them until they're too cynical to hang around. Can't say it's done them much good either. Still, it was fun while it lasted.
http://shit.slashdot.org/article.pl?sid=04/10/05/1 250209
Comment removed based on user account deletion
The GNU debugger has more than 80 contributors and is excellent because of it. No one can pay that many people to work on any single non-free code.
KDE is a tremendous project and is excellent. There are probably more KDE programmers out there now than there are people who have looked at VB. Gnome is right up there too. Both projects have been ported to more languages than Microsoft can afford to have their core office software ported.
It's because people realize that the Microsoft way of doing things has problems that can't be solved. Sure, you can still make money with your programming skills but you won't be able to do it long the closed source way. Your company does not outsource your job but it won't matter, whatever it is you work on will be eclipsed by a free program sooner or later. The Microsoft monopoly put a lot of people, like Netscape, Word Perfect, etc. Free software is payback.
Friends don't help friends install M$ junk.
Structured programming. Pascal. Formal verification. Ada. CASE tools. Object-oriented programming. Object-oriented analysis. Cross-platform development. Design re-use. Extreme programming. Program management professionals. Cross-functional teams. TQM. Each has valid and useful points. None is magic. Nothing can replace experience, motivation, and doing work you're proud to put under your name.
Under your name...one of the unsung strengths of open-source development! Nobody outside the company knows who put the bugs in closed source software. Open source developers sign their work for the world to see.
The bottom line is a manager has to know how to manage, otherwise they are entirely useless. If they can't organise anything they have no business being there - so they have to be able to arrange for people to handle the details.
The most obvious example I have ever seen (fortunately from a distance) is a manager of a non-destructive testing crew who was so clueless about the procedures that he did not realise that the work had to be carried out at night when there would be no-one on site (people generally object to being exposed to enough gamma rays to penetrate a couple of inches of steel and put an image on film). He was going to get the contract no matter what the bid was, but didn't budget for night work, so made a loss. He attempted to get the radiographers to work at night at flat day rates to try to make up for his mistake. Some basic knowlege of his field of responsibility or a few questions would have been enough for him to retain his job, and would have prevented his subordinates being laid off for a time until after new management in that area got things running again. It was a shining example that sales graduates who do not attempt to communicate should not run anything that was not covered by their university exams.
More security personnel to make sure nobody gets out of line.
That about covers the progress in todays "booming" economy--more jobs below poverty line; more dollars for the millionaires; nobody in between.
Each has valid and useful points. None is magic. Nothing can replace experience, motivation, and doing work you're proud to put under your name.
Under your name...one of the unsung strengths of open-source development! Nobody outside the company knows who put the bugs in closed source software. Open source developers sign their work for the world to see.
That's what I said. He said it must be because I am a lazy idiot (not paraphrased). I quit. You can't work with managers like that, and much less work for them. I put up with it for a VERY long time before an opportunity came up, but when it did I was out of there. They can't understand why employee loyalty is so bad.
Twitter, you're a petulant cock-gobbling sycophant to Linux Torvaldyos! Quit taking DP from ESR and RMS's feculent cocks and why dont you try to stop sucking quite so much? Get out of your parents' basement and see the real world - maybe then you'll see how pathetic you sound, with your neverending stream of bullshit about how Microsoft is stalking you. Wasn't it you who said that Microsoft believes your insane ranting is actually a threat to them, so they PAY PEOPLE to reply to you on Slashdot? No sir, I don't get any money. I do it for the love. Someone has to go up against your paranoid whining. So get back in your cage and shut the fuck up already.
Apparently, someone got the great idea to make the cdrom drive update the firmware when ever it got a command to check the hardware type. CDROM drives are not supposed to have any command to check the hardware type, as this is a common function reserved for CD-R/DVD drives. Well, Mandrake Linux 9.2 was the unlucky operating system to first exploit this bug.
Eventuly, LG discovered they had angered the general Linux community and released a firmware update that fixed the problem. Unfortunetly, the firmware update refused to fix cdrom drives on some computers. It's a shame, really. I fried two perfectly good cdrom drives that way...
Do you know why it needed to be rebooted? Because they used a beta version of an MS OS that timed out. YOu reboot the machine, reset the clock and you can get more time out of it. I suppose that it is MS's fault for them misusing a product that wasn't even meant to do what they were using it for. What a moron.
So, if someone at an airport deploys a beta version of software that fails, this make me a 'moron'?
Congradulations for lowering the discussion to personal insults.