Just because my comment was obvious and logical, didn't make it any less relevant.
I can also count the number of engineers who didn't care about their product on one hand. I don't disagree with you on that point. But, I can also count the number of engineers who'd get out of bed at 2AM to look at a real customer problem on one hand.
There are degrees of "care" can the vast majority of engineers don't care THAT much. Hard to blame them with the current employment situation where the managers will fire good engineers because of poor management decisions at the drop of a hat.
So, I assert that if these good engineers that care, but not that much, are the "best" we can do in America -- then this must mean there's something wrong with BOTH the management AND the engineers. The status quo isn't good, and no one's changing it.
Support people get paged/called, get up, rub the sleep out of their eyes, work all night documenting the problems, prove that it's really broken (which they knew already), and send it off in a ticket system hoping an engineer will fix the piss poor job they did, sometime in the next three releases. Management measures the engineers not on whether or not the customer finds the product acceptable, but by how many tickets they close (that means they had a LOT of bugs) and how much new code they release (buggy, or not).
Usually by the time the release cycle finishes and the bugs are fixed, the "new" version will come out with all new bugs to start the cycle over again.
Meanwhile the customer NEVER gets a product that really works -- 100% correctly -- and has to constantly decide if they can live with the problems. Especially in software products.
For their part, the original bad work by the engineer is rewarded, as well as all future versions, because they're incentivized by management and given bonuses for shipping "new product on time" and "fixing X number of bugs".
My idea: Tie bugs to wallets. No bonus for software that has major bugs. Lower bonus for software with minor bugs.
Until that happens, engineers have only personal conviction incentives for REALLY getting it right the first time. Tie it to whether or not their family gets fed, and you'd have better results.
Additionally, a social problem for good engineering exists. If they DO get it right the first time, both the engineer and the support staff are out of jobs, so there's a natural tendency to ship now, deal with bugs later. Once the "99.9% working" type of system is built, the company usually folds within a few years, after the sales ramp completes its natural cycle.
It's the very definition of insanity, and a never-ending cycle. And people are very used to it. How many times have you seen any computer-related product review say, "It has the usual problems but all-in-all, we give it an 8 out of 10?"
Finally, if you ship a product without any major problems, you have an opportunity to move on to newer and better things, but you run the very real risk that the customers simply won't pay for an upgrade to the old system.
To counteract this, most organizations buffer the engineers from the problems permanently unless they're "critical", so they can just go ahead and create new things without fixing the one released yesterday. "That's not critical, engineering won't look at it, they're busy working on the new system."
The typical American investor even supports this behavior -- by only looking at public companies on a quarter by quarter basis. This is why startups and massively large companies seem to be the only real innovators -- that and companies run by tyrants. Mid-sized "normal" companies are mired in their own financial incentive problems and fiscal paranoia about "growth", constantly.
Einstein states the overall issue better than I can:
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
My point is that binary blobs and other such trickery is unnecessary if the ENGINEERING is done right and the interface is DOCUMENTED.
I know, this went out of vogue in 1989 or so. But it DID work better for everyone when manuals actually had useful information about the product interfaces in them. Hell getting anything more than ten sheets of paper with government or lawyer-required "safety data" with a piece of computer hardware anymore, let alone a MANUAL, is virtually impossible.
I was also pointing out that the argument that "we have to keep people from doing illegal things with their radio modules to get FCC certification" doesn't hold water.
Open interface design and locked-down features easily can be done, together.
All of these tricky little things like loading binary crap into the kernel and other driver trickery done by hardware manufacturers is just a sign of sloppy engineering. This sloppiness is both from idiots in "leadership" pushing deadlines so far back that nothing can be built that WORKS, and engineers who don't care, for various reasons.
The reasons that engineers don't really care about good interfaces and documentation is two-fold: 1. If you develop CRAP, that just barely works and frustrates the hell out of the customer -- you have a permanent job "fixing" it. 2. Why care about making a great product for a company that doesn't care about you at all and will lay you off or dump you to save one quarter's financials and the bonuses of the executives that quarter?
Companies reap what they sow, in the case of #2. It's only natural to act that way if the company doesn't make any effort at longevity or show any effort at being somewhere thinking large enough to look beyond the next three months.
Deadlines are out of control, and good engineering isn't done anymore. Your upset response complete with cussing and stupid personal remarks that were unwarranted, shows that everyone's just used to it at this point.
Some other country and community of engineers will do good engineering once we stop fighting to do things better than everyone else... no worries. That's competition.
Oh come ON. You can easily put middleware firmware between the raw VCO frequency input and power level settings, so that the end-user will be effectively limited to only what frequencies and power levels you wish the end-user to access.
Then you can DOCUMENT THAT INTERFACE.
There's nothing particularly difficult or expensive about doing that. It's just a shim between the driver and the hardware. And done right (e.g. ENGINEERED PROPERLY), you can also save your company from ever having to release anything other than ONE STANDARD DRIVER for all of your hardware -- the hardware can change, the firmware/middleware can be modified to drive the new hardware, and the software/OS level driver never has to change for that type of "service", ever, even if the hardware changes underneath.
Doing that actually makes good business sense for many similar products, too.
Go back to the drawing board and write a GOOD SPECIFICATION for a middleware/firmware abstraction layer. You can even write features into that specification that don't exist today but likely will in future products, and not publish them at first. Or make the specification extensible.
Your comments about "free software" being more appropriate has been discussed at length for more years than "FOSS" has been around, and various problems exist with that phrase. It's been beat to death, so I won't repeat that stuff.
"FOSS" is so common, though, that anyone complaining about its use, shouldn't be.
I have to agree with the other guy here that said, "Don't be a tard."
At least when it comes to nursing, you have virtually no clue what you're talking about.
As the other person mentioned, there are various levels of nursing, from LPN up to Nurse Practitioner, and various levels of education required.
And in today's medical environment, unless you have a major illness, nurses are your front-line care-givers. Doctors just stop in, say hello, take a quick double-check of anything they want to look at momentarily from the chart they wer handed, and then they sign the prescription forms and send you on your way.
Nurses are there from the moment you step through the door to well after you leave, if needed, via home health-care. Doctors don't make house-calls, and haven't for decades.
Trust me that you definitely WANT intelligent nurses in today's medical system -- you really do. Requiring high education standards for the people that spend the MOST time working with you and evaluating your heath, is a requirement. And a correct one.
So pick on whatever you want to pick on that you know little about, but leave nurses out of it. You know NOTHING about nurses.
"Does it work?" is a meaningless question asked by a great many CxO's.
Usually they really DON'T know if it "works" because they don't have any idea what the business needs are.
Does Windows "work"? Does that modem over there "work"? Does the shiny new laptop on your desk "work"? Nope.
They don't "work" unless a smart human makes them either a) Make the company revenue, or b) Save the company revenue.
The real question is:
a) Does it make the company money? b) Does it save the company money?
If the answer to either of the above is "no", then it's not necessary for the business to purchase whatever it is.
IT budgets are usually way out of line with how much money they either make or save the company.
I regularly see tasks being done by large database systems and GUI front-ends that could EASILY be done with two filing clerks at $10/hour and a one-time careful thought process put together for a) the form used, and b) how to get the filing clerk to fax a copy of the filled out forms to anyone who needs one for reference.
"Data Warehousing" really gives me a chuckle. Store shit no one's using, hoping someone, someday, will have time to dig through it for something useful -- in a world gone mad with over-communication and automation of that, but little automation of repetitive tasks, or better yet... ELIMINATION of them.
Ah. Perhaps. I guess I'm the one not paying attention. But Madge makes a lot more than just the token-ring product line. (And much of it sucked big time, last time I was required to use it.)
My 88 year old grandfather plays card games on his PC daily. What's the point of the article or the posting to slashdot? No he's not playing MMORPG's or first-person shooters, but he's on his PC playing a game, every day. Big deal.
Just curious - who came up with the fuel hedging idea? Chairman? CEO? Pilots? Flight attendants? That seems to be a key piece of information missing in your argument. Good point, but still missing the whole picture.
I always wonder what "overly litigous" is. They're our laws, we created them directly or indirectly. If we want lawsuits to lessen, we have to repeal some laws.
Slashdot Mirror
So you're saying that Apple will continue to take market-share from other OS's at a huge clip, by that logic.
You may be right.
Just because my comment was obvious and logical, didn't make it any less relevant.
I can also count the number of engineers who didn't care about their product on one hand. I don't disagree with you on that point. But, I can also count the number of engineers who'd get out of bed at 2AM to look at a real customer problem on one hand.
There are degrees of "care" can the vast majority of engineers don't care THAT much. Hard to blame them with the current employment situation where the managers will fire good engineers because of poor management decisions at the drop of a hat.
So, I assert that if these good engineers that care, but not that much, are the "best" we can do in America -- then this must mean there's something wrong with BOTH the management AND the engineers. The status quo isn't good, and no one's changing it.
Support people get paged/called, get up, rub the sleep out of their eyes, work all night documenting the problems, prove that it's really broken (which they knew already), and send it off in a ticket system hoping an engineer will fix the piss poor job they did, sometime in the next three releases. Management measures the engineers not on whether or not the customer finds the product acceptable, but by how many tickets they close (that means they had a LOT of bugs) and how much new code they release (buggy, or not).
Usually by the time the release cycle finishes and the bugs are fixed, the "new" version will come out with all new bugs to start the cycle over again.
Meanwhile the customer NEVER gets a product that really works -- 100% correctly -- and has to constantly decide if they can live with the problems. Especially in software products.
For their part, the original bad work by the engineer is rewarded, as well as all future versions, because they're incentivized by management and given bonuses for shipping "new product on time" and "fixing X number of bugs".
My idea: Tie bugs to wallets. No bonus for software that has major bugs. Lower bonus for software with minor bugs.
Until that happens, engineers have only personal conviction incentives for REALLY getting it right the first time. Tie it to whether or not their family gets fed, and you'd have better results.
Additionally, a social problem for good engineering exists. If they DO get it right the first time, both the engineer and the support staff are out of jobs, so there's a natural tendency to ship now, deal with bugs later. Once the "99.9% working" type of system is built, the company usually folds within a few years, after the sales ramp completes its natural cycle.
It's the very definition of insanity, and a never-ending cycle. And people are very used to it. How many times have you seen any computer-related product review say, "It has the usual problems but all-in-all, we give it an 8 out of 10?"
Finally, if you ship a product without any major problems, you have an opportunity to move on to newer and better things, but you run the very real risk that the customers simply won't pay for an upgrade to the old system.
To counteract this, most organizations buffer the engineers from the problems permanently unless they're "critical", so they can just go ahead and create new things without fixing the one released yesterday. "That's not critical, engineering won't look at it, they're busy working on the new system."
The typical American investor even supports this behavior -- by only looking at public companies on a quarter by quarter basis. This is why startups and massively large companies seem to be the only real innovators -- that and companies run by tyrants. Mid-sized "normal" companies are mired in their own financial incentive problems and fiscal paranoia about "growth", constantly.
Einstein states the overall issue better than I can:
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
American engineerin
My point is that binary blobs and other such trickery is unnecessary if the ENGINEERING is done right and the interface is DOCUMENTED.
I know, this went out of vogue in 1989 or so. But it DID work better for everyone when manuals actually had useful information about the product interfaces in them. Hell getting anything more than ten sheets of paper with government or lawyer-required "safety data" with a piece of computer hardware anymore, let alone a MANUAL, is virtually impossible.
I was also pointing out that the argument that "we have to keep people from doing illegal things with their radio modules to get FCC certification" doesn't hold water.
Open interface design and locked-down features easily can be done, together.
All of these tricky little things like loading binary crap into the kernel and other driver trickery done by hardware manufacturers is just a sign of sloppy engineering. This sloppiness is both from idiots in "leadership" pushing deadlines so far back that nothing can be built that WORKS, and engineers who don't care, for various reasons.
The reasons that engineers don't really care about good interfaces and documentation is two-fold:
1. If you develop CRAP, that just barely works and frustrates the hell out of the customer -- you have a permanent job "fixing" it.
2. Why care about making a great product for a company that doesn't care about you at all and will lay you off or dump you to save one quarter's financials and the bonuses of the executives that quarter?
Companies reap what they sow, in the case of #2. It's only natural to act that way if the company doesn't make any effort at longevity or show any effort at being somewhere thinking large enough to look beyond the next three months.
Deadlines are out of control, and good engineering isn't done anymore. Your upset response complete with cussing and stupid personal remarks that were unwarranted, shows that everyone's just used to it at this point.
Some other country and community of engineers will do good engineering once we stop fighting to do things better than everyone else... no worries. That's competition.
Oh come ON. You can easily put middleware firmware between the raw VCO frequency input and power level settings, so that the end-user will be effectively limited to only what frequencies and power levels you wish the end-user to access.
Then you can DOCUMENT THAT INTERFACE.
There's nothing particularly difficult or expensive about doing that. It's just a shim between the driver and the hardware. And done right (e.g. ENGINEERED PROPERLY), you can also save your company from ever having to release anything other than ONE STANDARD DRIVER for all of your hardware -- the hardware can change, the firmware/middleware can be modified to drive the new hardware, and the software/OS level driver never has to change for that type of "service", ever, even if the hardware changes underneath.
Doing that actually makes good business sense for many similar products, too.
Go back to the drawing board and write a GOOD SPECIFICATION for a middleware/firmware abstraction layer. You can even write features into that specification that don't exist today but likely will in future products, and not publish them at first. Or make the specification extensible.
"FOSS" has been commonly used for many years now.
Your comments about "free software" being more appropriate has been discussed at length for more years than "FOSS" has been around, and various problems exist with that phrase. It's been beat to death, so I won't repeat that stuff.
"FOSS" is so common, though, that anyone complaining about its use, shouldn't be.
Yes a REGISTERED NURSE. LPN = Licensed Professional Nurse, and is typically a 2-year program.
Learn what you're talking about.
Good points, really. If I could mod you up, I would.
I have to agree with the other guy here that said, "Don't be a tard."
At least when it comes to nursing, you have virtually no clue what you're talking about.
As the other person mentioned, there are various levels of nursing, from LPN up to Nurse Practitioner, and various levels of education required.
And in today's medical environment, unless you have a major illness, nurses are your front-line care-givers. Doctors just stop in, say hello, take a quick double-check of anything they want to look at momentarily from the chart they wer handed, and then they sign the prescription forms and send you on your way.
Nurses are there from the moment you step through the door to well after you leave, if needed, via home health-care. Doctors don't make house-calls, and haven't for decades.
Trust me that you definitely WANT intelligent nurses in today's medical system -- you really do. Requiring high education standards for the people that spend the MOST time working with you and evaluating your heath, is a requirement. And a correct one.
So pick on whatever you want to pick on that you know little about, but leave nurses out of it. You know NOTHING about nurses.
Which disaster would you like credit for?
Every disaster-fated structure or system anyone's ever seen fail, was built by an Engineer.
What do you want it to do? :-)
"Does it work?" is a meaningless question asked by a great many CxO's.
Usually they really DON'T know if it "works" because they don't have any idea what the business needs are.
Does Windows "work"? Does that modem over there "work"? Does the shiny new laptop on your desk "work"? Nope.
They don't "work" unless a smart human makes them either a) Make the company revenue, or b) Save the company revenue.
The real question is:
a) Does it make the company money?
b) Does it save the company money?
If the answer to either of the above is "no", then it's not necessary for the business to purchase whatever it is.
IT budgets are usually way out of line with how much money they either make or save the company.
I regularly see tasks being done by large database systems and GUI front-ends that could EASILY be done with two filing clerks at $10/hour and a one-time careful thought process put together for a) the form used, and b) how to get the filing clerk to fax a copy of the filled out forms to anyone who needs one for reference.
"Data Warehousing" really gives me a chuckle. Store shit no one's using, hoping someone, someday, will have time to dig through it for something useful -- in a world gone mad with over-communication and automation of that, but little automation of repetitive tasks, or better yet... ELIMINATION of them.
Ah. Perhaps. I guess I'm the one not paying attention. But Madge makes a lot more than just the token-ring product line. (And much of it sucked big time, last time I was required to use it.)
My 88 year old grandfather plays card games on his PC daily. What's the point of the article or the posting to slashdot? No he's not playing MMORPG's or first-person shooters, but he's on his PC playing a game, every day. Big deal.
Madge doesn't have a monopoly on networking gear, but thanks for the daily anti-Microsoft troll. It has nothing to do with my comment.
Madge didn't die from TR -- take a look at some of the other crap they produced that never worked right, and you'll be closer to the right track.
That might be the real hidden beauty in the system. It's OPEN.
Just curious - who came up with the fuel hedging idea? Chairman? CEO? Pilots? Flight attendants? That seems to be a key piece of information missing in your argument. Good point, but still missing the whole picture.
Who said I'm trying to convert people? :-)
Format C:\ is the first command I teach all new Windows users.
:-)
They learn early about backups and how hard it really is to install an OS if their vendor doesn't do it for them.
Why not get pissed at mod_security's license and talk to THEM about it rather than get pissed at Debian? Your ire is misdirected.
Or go write a replacement that has proper open source licensing.
Plenty of options. None you like. Not Debian's fault.
Insightful and too "harsh" a reality for most folks, but there it is. Bravo for solidifying it.
I always wonder what "overly litigous" is. They're our laws, we created them directly or indirectly. If we want lawsuits to lessen, we have to repeal some laws.
No, but the kids who videotaped him learned they need one from the next idiots jumping 'round in front of their cameras.
Yeah, they learned to get the idiots doing stupid things to sign release forms whenever videotaping.
How about: A free society must choose to REMAIN free?
Ahhh. I get it!
That sounds good too... I don't see very well without my glasses on, and contacts drive me nuts.