EDS do a lot of systems that don't work, or don't work properly, or run massively over schedule and budget, here in the UK as well.
Maybe those systems just do exactly what the customer's contract specified. And if those projects did anything differently, like actually work, the contractor would have been sued for non-compliance?
We build highways, bridges, and the like. We do the vast majority of our work under low bidder contracts. More importantly, we deliver the product on time and of a high quality.
And how do you deal with the customer whose specs say (in effect) "just throw a log across that creek because all we need is a footpath for the weekend" and subsequently declare your work an extension to the InterState Highway System and in non-compliance (substandard) of rule Blah, section Blah-blah, part Blah-blah-blah, paragraph Blah-blah-blah-blah?
From the article: The pilot was not designed to become a national system, however. The INS had intended to examine its results and then build something new, school officials who participated in the test say. It was a "throwaway project," says Johnson. "It wasn't supposed to become something bigger."
This is one of the most common causes of failure that I have seen over the years. A refusal by management to see the difference between a "proof of concept" project and a "production" project.
Attention programmers. Learn this now and learn it well. There is no such thing as a "quick and dirty" project. Anything you write for hire can and probably will be pushed into production. And if you "assumed" that you could "get by" with single user code with (for example) no record locking, error testing, logging, transactioning, or provision for remote monitoring or backup, you just screwed the pooch. The minute you check that code into CVS, it's heading for production with hundreds of incompetent users who will expect 100.000% uptime. And management will quickly point you out as the author of the failing new product and your reputation is shot, your future with the company is shot, and you have given programmers everywhere another black eye. Gee, thanks.
People, what it is, is that every piece of code that you write for hire has to be the very best you can create. Because, while your customer may have only asked you to throw a one-log footbridge across the creek, s/he is expecting an eight-lane interstate highway structure.
A low-speed version of this was installed at the old Dallas airport (Love Field) when the third terminal was opened in the late 50's. Three endless loop belts carried people and their carry-on baggage from the lobby to the three boarding areas which _seemed_ to be a quarter-mile away. Or farther, if you actually had to carry your own bags.
A few people may have gotten hurt in accidents over the years, but I don't remember ever seeing a report of major incident in the newspapers.
Obviously the lowest-common-denominator are able to adopt new technology; slidewalks, automobiles, Slashdot.
... why the hell don't they just constrain the language...
Because when language developers constrain the language to what they want users (application developers) to do, you wind up with something like dBase II; primitive, non-extensible, and extremely frustrating.
Not really. Gliders avoid most of the expense of other aircraft by not carrying onboard engines. (Most of the expense of flying is gas and engine maintenance.) Your actual fixed expenses amount to annual inspection, insurance, and hangar/tie-down fees. Partner up with one or two friends and you're looking at only a few hundred dollars a year. You'll pay more than that in rental if you're flying regularly.
Variable expenses are basically tow/launch fees. Those are the same whether you fly your own bird or rent and are probably the biggest cost. But you only need one ten-minute tow for a flight that can last for hours. (If you're good enough.)
And here's the best part. When you decide to sell after a few years, you'll probably be able to get your original investment back. I sold my bird after four years for 30% more than I paid.
And, getting back on topic, no office chair (even with Homedic 10-motor vibrating massage pad) will give the same thrill as circling in a 5 m/s thermal or... Naw, you just gotta be there.
The ASK-21 (1) sailplane shown in the sim photos is a fiberglass younger brother of the Schleicher Ka-7 (2) (proven steel tube & fabric technology).
Although prices fluctuate during the summer soaring season, there was a Ka-7 for sale this spring (in England) with an asking price of GBP2500. Less than a third the cost of simulation. Both birds can be found in the USA. Price and availability vary according to present owner's situation.
Rent an aircraft. To do this, you'll have to show pilot's license, current medical certificate, and your log book(s). Absent these credentials, you won't be renting and the owner may take it upon himself to call the local law enforcement about "the terrorist".
Buy an aircraft. The seller will want to see your credentials so he knows he isn't selling to either a suicide or "a terrorist". If he does, he's in trouble.
Steal an aircraft. At least for this, you don't have to show paperwork. But you will be wanting to (at least) buy gasoline and, once the theft is discovered, every airport in the country will be watching for a plane stolen by "a terrorist".
Without the experience gained while earning a license, and no matter how much sim time you have, your first landing will probably be spectacular enough to have someone asking to see your license. And refusal to produce your license is like refusal to take an breath-alcohol exam; automatic guilty.
Smart mouth works right up to the point of endangering the lives of others. Past that point, there are real, not simulated, consequences.
So many taxpayers would be pissed that it would be a major political blunder to de-monitize a bill or series of bill. So the old bills remain legal and the old-style bill patterns remain vulnerable to copyists.
So, again, how does introducing a new pattern reduce the vulnerability of the old patterns?
What problem is solved by adding another new design?
The two previous designs are still legally in circulation. Since they were / are apparently counterfeitable (is there such a word?), adding a new design does nothing to make the older designs un-counterfeitable.
Unless the older designs of currency are de-monetized, new designs do not solve a problem. (Older readers with military service may remember the MPC[1] script coversion days[2].) Yes, eventually almost all paper money will wind up being captured by banks and turned in for destruction. But it takes years to remove most of a type of bill and the remaining copies are still legal money. So the older patterns are still vulnerable.
[1] MPC - Military Payment Certificates. See google or eBay. [2] Script conversion days - A twenty-four hour period during which all personnel were required to exchange their MPCs for the same value in a new series (new colors, new pictures). At the end of the conversion period, old series script was worthless and had value only as a colorful curiosity. Failure to exchange meant that you lost. No excuses, no make-ups, see the chaplain.
OK. I've tried asking before and never gotten a straight answer. Maybe you can/will provide one. What's wrong with r* and.rhosts?
I grant that they are problems in shops with low-give-a-shit about password sharing and other such social problems. But are the r* commands technically insecure?.rhosts means that they don't send passwords so what's the technical problem?
...but they can hardly be used in an offensive way, right?...
Well, General Motors managed to get very offended when an NBC news program assaulted a Chevy pickup (and the truth, generally) with model rocket engines.
Given that machines which are running Linux/BSD operating systems do not need a Microsoft operating system and, furthur, that Linux/BSD do not directly support business applications which require Microsoft operating systems, what legal justification does the Business Software Alliance have for demanding purchase of Microsoft software licenses for machines which run Linux/BSD? What is an appropriate defense against such claims?
Please don't forget the learning aspect. Even a "clueless" type can teach you something.
One of the professional bass-fishermen (Jimmy Houston, if memory serves) once observed "I learn something from everybody I fish with. Sometimes all I learn is that I don't ever want to fish with that person again."
You only need to stay 15 minutes ahead of the others for them to think that you are a genius.
Several things you can do:
Create a small version of your development environment at home and spend time doing little proof-of-concept projects there before announcing your design ideas at the office. Even if people find out that you are proofing at home, you can get points for having a Give-A-Shit attitude.
Write up your thoughts/notes on the current project and give them to the new kid in the group. S/he will become conditioned to come to you for answers. Which will force you to learn.
Call meetings of the programmers to talk about shop standards, techniques, "how to use GDB", etc. Nobody else is trying to form the herd into a team and you will look like a leader. Which will force you to become one.
Teach classes to the other programmers. Managers love to get department training for effectively nothing. An AS400 jockey could try to explain OS400 (is that the right name?) to UNIX jocks. A UNIX type could intro Linux to the 400 jockeys. You really find out what you do and don't know when you try to teach someone else.
Get a copy of some presentation tool (power-point equiv.) and learn to do simple presentations. Ten pages or less; outline form; major bullet points. Then use those techniques in your peer meetings. Scare the bejeezus out of your manager by using a formal presentation to explain why you HAVE to have some new tool in the department. You'll know you have "arrived" when your boss uses your presentation to go to his boss for more budget money.
Get the idea? Learn by doing privately and learn more by teaching. To be really great, you need more than coding skills. You also need writing, teaching, leading, and public-speaking. But most of all, don't try to do it in a vacuum. You can learn from others while you are teaching them. You can't get there overnight, but by constantly picking at it, one little piece at a time, you will get there.
Downside is that marginally-abled management will see you as a threat to their jobs.
p.s. For goodness sake, learn to punctuate and use a spell checker. (No touchbacks.) You don't get points for looking professional; you lose for not.
...you too can be one of the last people to be laid [sic] by your employer
Yeah, maybe. But you won't be the last. Because management will have to keep a handful of really good programmers to cleanup your cruft. And they will tell ten friends, and they will tell ten friends,...
Been there; used the t-shirt to mop up the mess. Still telling stories at the local user group.
Re:Nice read, one thing that is missing...
on
How to be a Programmer
·
· Score: 4, Funny
...deployment is really neglected.
Maybe, maybe not. Very often the programmer is not a part of the deployment process.
In very small companies, the owner waits until the programmer is not in the office and then copies executables from the wrong directory on the development machine onto a floppy/tape and starts sending out copies in order to make good on the ridiculous ship date the programmer refused to accept. This complicates the finger-pointing to come, since the marketing/sales manager did the same thing three days earlier. [If you haven't experienced this, you simply haven't worked at sufficiently small companies.]
In very large companies, programmers can't be trusted anywhere near the QC, release, or production environments. At best, the programmer is allowed to create a release document listing the files to be compiled by the "build-meister" in the sterile build environment and then tar-balled for delivery to the sysadmins. Who will "install" by dropping the tar-ball into/usr/local/bin, turning off their pagers, and going home. [If you haven't experienced this, you simply haven't worked at sufficiently large companies.]
Slashdot Mirror
EDS do a lot of systems that don't work, or don't work properly, or run massively over schedule and budget, here in the UK as well.
Maybe those systems just do exactly what the customer's contract specified. And if those projects did anything differently, like actually work, the contractor would have been sued for non-compliance?
And how do you deal with the customer whose specs say (in effect) "just throw a log across that creek because all we need is a footpath for the weekend" and subsequently declare your work an extension to the InterState Highway System and in non-compliance (substandard) of rule Blah, section Blah-blah, part Blah-blah-blah, paragraph Blah-blah-blah-blah?
From the article: The pilot was not designed to become a national system, however. The INS had intended to examine its results and then build something new, school officials who participated in the test say. It was a "throwaway project," says Johnson. "It wasn't supposed to become something bigger."
This is one of the most common causes of failure that I have seen over the years. A refusal by management to see the difference between a "proof of concept" project and a "production" project.
Attention programmers. Learn this now and learn it well. There is no such thing as a "quick and dirty" project. Anything you write for hire can and probably will be pushed into production. And if you "assumed" that you could "get by" with single user code with (for example) no record locking, error testing, logging, transactioning, or provision for remote monitoring or backup, you just screwed the pooch. The minute you check that code into CVS, it's heading for production with hundreds of incompetent users who will expect 100.000% uptime. And management will quickly point you out as the author of the failing new product and your reputation is shot, your future with the company is shot, and you have given programmers everywhere another black eye. Gee, thanks.
People, what it is, is that every piece of code that you write for hire has to be the very best you can create. Because, while your customer may have only asked you to throw a one-log footbridge across the creek, s/he is expecting an eight-lane interstate highway structure.
Because your second cousin "stole" some of your DNA at last Christmas' family party and left it at the scene of the crime?
Hmmm ...
A low-speed version of this was installed at the old Dallas airport (Love Field) when the third terminal was opened in the late 50's. Three endless loop belts carried people and their carry-on baggage from the lobby to the three boarding areas which _seemed_ to be a quarter-mile away. Or farther, if you actually had to carry your own bags.
A few people may have gotten hurt in accidents over the years, but I don't remember ever seeing a report of major incident in the newspapers.
Obviously the lowest-common-denominator are able to adopt new technology; slidewalks, automobiles, Slashdot.
Because when language developers constrain the language to what they want users (application developers) to do, you wind up with something like dBase II; primitive, non-extensible, and extremely frustrating.
Guidance? ... Guidance? ... Hello?
Not really. Gliders avoid most of the expense of other aircraft by not carrying onboard engines. (Most of the expense of flying is gas and engine maintenance.) Your actual fixed expenses amount to annual inspection, insurance, and hangar/tie-down fees. Partner up with one or two friends and you're looking at only a few hundred dollars a year. You'll pay more than that in rental if you're flying regularly.
Variable expenses are basically tow/launch fees. Those are the same whether you fly your own bird or rent and are probably the biggest cost. But you only need one ten-minute tow for a flight that can last for hours. (If you're good enough.)
And here's the best part. When you decide to sell after a few years, you'll probably be able to get your original investment back. I sold my bird after four years for 30% more than I paid.
And, getting back on topic, no office chair (even with Homedic 10-motor vibrating massage pad) will give the same thrill as circling in a 5 m/s thermal or ... Naw, you just gotta be there.
The ASK-21 (1) sailplane shown in the sim photos is a fiberglass younger brother of the Schleicher Ka-7 (2) (proven steel tube & fabric technology).
Although prices fluctuate during the summer soaring season, there was a Ka-7 for sale this spring (in England) with an asking price of GBP2500. Less than a third the cost of simulation.
Both birds can be found in the USA. Price and availability vary according to present owner's situation.
Notes:
1. Schleicher ASK-21
2. Schleicher Ka-7
There are three ways to get aloft:
Without the experience gained while earning a license, and no matter how much sim time you have, your first landing will probably be spectacular enough to have someone asking to see your license. And refusal to produce your license is like refusal to take an breath-alcohol exam; automatic guilty.
Smart mouth works right up to the point of endangering the lives of others. Past that point, there are real, not simulated, consequences.
And that's just during rush hour. You don't want to think what they are doing after 11pm.
This is a very good point. Can court records in Germany be sealed away from the public? Can we please have some response from Germany?
1 m/s ~= 197 ft/s
Exactly the point. Or rather, the attitude.
So many taxpayers would be pissed that it would be a major political blunder to de-monitize a bill or series of bill. So the old bills remain legal and the old-style bill patterns remain vulnerable to copyists.
So, again, how does introducing a new pattern reduce the vulnerability of the old patterns?
What problem is solved by adding another new design?
The two previous designs are still legally in circulation. Since they were / are apparently counterfeitable (is there such a word?), adding a new design does nothing to make the older designs un-counterfeitable.
Unless the older designs of currency are de-monetized, new designs do not solve a problem. (Older readers with military service may remember the MPC[1] script coversion days[2].) Yes, eventually almost all paper money will wind up being captured by banks and turned in for destruction. But it takes years to remove most of a type of bill and the remaining copies are still legal money. So the older patterns are still vulnerable.
[1] MPC - Military Payment Certificates. See google or eBay.
[2] Script conversion days - A twenty-four hour period during which all personnel were required to exchange their MPCs for the same value in a new series (new colors, new pictures). At the end of the conversion period, old series script was worthless and had value only as a colorful curiosity. Failure to exchange meant that you lost. No excuses, no make-ups, see the chaplain.
You tell 'em, Mohammed Saeed al-Sahaf.
OK. I've tried asking before and never gotten a straight answer. Maybe you can/will provide one. What's wrong with r* and .rhosts?
I grant that they are problems in shops with low-give-a-shit about password sharing and other such social problems. But are the r* commands technically insecure? .rhosts means that they don't send passwords so what's the technical problem?
What am I missing here? Please?
If he can't get a job here with his college skills and winds up as a telemarketer, would it have been worth it?
Maybe the Golgafrinchams were on the track of a good idea; "Mars for Tele-marketers".
DRA = ?
Well, General Motors managed to get very offended when an NBC news program assaulted a Chevy pickup (and the truth, generally) with model rocket engines.
Sounds more like a recipe for flash-fried orange popsicle.
Mmmm... popsicle.
Given that machines which are running Linux/BSD operating systems do not need a Microsoft operating system and, furthur, that Linux/BSD do not directly support business applications which require Microsoft operating systems, what legal justification does the Business Software Alliance have for demanding purchase of Microsoft software licenses for machines which run Linux/BSD? What is an appropriate defense against such claims?
Please don't forget the learning aspect. Even a "clueless" type can teach you something.
One of the professional bass-fishermen (Jimmy Houston, if memory serves) once observed "I learn something from everybody I fish with. Sometimes all I learn is that I don't ever want to fish with that person again."
You only need to stay 15 minutes ahead of the others for them to think that you are a genius.
Several things you can do:
Get the idea? Learn by doing privately and learn more by teaching. To be really great, you need more than coding skills. You also need writing, teaching, leading, and public-speaking. But most of all, don't try to do it in a vacuum. You can learn from others while you are teaching them. You can't get there overnight, but by constantly picking at it, one little piece at a time, you will get there.
Downside is that marginally-abled management will see you as a threat to their jobs.
p.s. For goodness sake, learn to punctuate and use a spell checker. (No touchbacks.) You don't get points for looking professional; you lose for not.
Yeah, maybe. But you won't be the last. Because management will have to keep a handful of really good programmers to cleanup your cruft. And they will tell ten friends, and they will tell ten friends,...
Been there; used the t-shirt to mop up the mess. Still telling stories at the local user group.
Maybe, maybe not. Very often the programmer is not a part of the deployment process.
In very small companies, the owner waits until the programmer is not in the office and then copies executables from the wrong directory on the development machine onto a floppy/tape and starts sending out copies in order to make good on the ridiculous ship date the programmer refused to accept. This complicates the finger-pointing to come, since the marketing/sales manager did the same thing three days earlier. [If you haven't experienced this, you simply haven't worked at sufficiently small companies.]
In very large companies, programmers can't be trusted anywhere near the QC, release, or production environments. At best, the programmer is allowed to create a release document listing the files to be compiled by the "build-meister" in the sterile build environment and then tar-balled for delivery to the sysadmins. Who will "install" by dropping the tar-ball into /usr/local/bin, turning off their pagers, and going home. [If you haven't experienced this, you simply haven't worked at sufficiently large companies.]
It wasn't funny at the time.