Oh, please. First you agree that Groklaw "does indeed focus on legal commentary," and then you complain that not every commentary is footnoted legal discussion. Make up your mind.
My personal opinion of Groklaw is irrelevant, but here it is: PJ is a talented commentator on legal issues and has been a catalyst for the necessary and useful anti-SCO mobilization that was (and is) required to send them back to the hole they crawled out of.
PJ's other opinions are much less useful, although I am interested also in the software patent work she is doing.
Go back under your bridge. If you read Groklaw, you know that it is hardly a "blowhard blog." Rather, it is a collection of commentary and court documents on the SCO/IBM case and on other legal issues affecting the FOSS community. If you don't like the commentary, you can add to it -- thoughtful comments from any point of view are welcomed.
Furthermore, PJ has been quite forthright about who is paying her (nobody), and she's already defended herself against far more clever attacks than your silliness. The simple basis for her credibility is the fact that every commentary she posts is heavily footnoted from court documents, all of which are carefully documented and archived for posterity. If you don't agree with her commentary, you can argue from the facts, which are helpfully provided for you right on the site. There is a strong reason why Groklaw is heavily trafficked by both IBM and SCO attorneys -- and that is that it is an informational site of high value to both parties, as well as to interested observers, which you, apparently, are not.
Bottom line: PJ's identity is irrelevant, and so, my little snowflake, are you.
You say: "If these people have a need for more complicated applications we should provide them the tools and training so that they can build them themselves..."
I really don't think they will become programmers, do you?
Then you continue: "...or fund the projects so technicians, like me, can build such applications for them."
I am not aware of any company that has been successful with such an approach. In fact, I can think of several that have crashed and burned spectacularly. It doesn't work in practice, because the analyst is not able to communicate completely enough or effectively enough to the programmer. Typically the analyst him/herself doesn't fully understand the scope of the problem. Which is part of why Excel is such a neat tool for them. It is exploratory in nature.
So let's focus on the problem, and pretend for a moment that you are one of these analysts. You have something you need to deliver. The only tool you know is Excel. What do you do? You can't run down the hall to some development group, which is already way over their heads trying to meet the existing schedule, and ask them to build something custom for you; they'll just laugh at you. Your only choice is to get the job done with the tool that you know.
So, here are some practical suggestions to help wean these people off doing bad things with Excel:
1)) Give them an Excel back end to your app. That way, they can customize the output, and take it farther. You know they will end up doing this anyway, typically by painfully dumping data from your database and loading it back into Excel manually; so why not make this easy for them, and take all the manual errors out of the process?
2) See if there are VBA type things that they do over and over again that can be pre-packaged for them, so that these constructs work out of the box and are bug-free. Make them a nice toolbox and train them on it. This is kinda what the original book we're supposed to be discussing is trying to do, isn't it? Um.
3) There are plenty of Excel-based collaboration tools that manage Excel use across multiple people. Find one and introduce it to the company.
Are these things hard? Some of them are, especially creating Excel interactions with web apps, unless you go ActiveX which is a disaster. But there are other ways to do this, which I will (arrogantly) leave as an exercise for the reader.
So IMO it is possible to make the situation better. But sitting back in our developer's chairs thinking that we can do something about it by trying to write enough apps to cover all the bases for these people isn't a practical point of view.
You complain that your customers -- financial analysts all -- are building stuff in Excel. According to you this is bad. I kinda line up on their side of the fence on this one, sorry. You'll have to rip Excel out of their cold, dead fingers, or replace it with something much, much better. And that ain't Calc, which is a me-too, not an evolutionary step.
I would think you'd be happy at seeing someone try to help these people build manageable Excel models and simple Excel apps. Let's face it:
1) They will continue to do this, it's fundamental to doing their job. If they need to analyze something quickly, they can't wait for a bunch of quiche-eating Java weenies to argue about the object model for the next six months. 2) There's nothing you can do to stop them. 3) Really. Nothing. 4) So you might as well help them to do what they do, only do it better.
Reminds me of a Steven Seagal movie:
"Well, if I can't control you, I might as well use you, right, son?" "That's affirmative, sir."
But that's probably too practical a viewpoint for this forum.
True, nobody forces anybody to read or view anything, but you have to admit that stadium scene was really grim.
Quoting Eric Raymond,
"The difference between Heinlein and Pournelle starts with the fact that Pournelle could write about a cold-blooded mass murder of human beings by human beings, performed in the name of political order, approvingly -- and did.
But the massacre was only possible because Falkenberg's Legion and Heinlein's Mobile Infantry have very different relationships with the society around them. Heinlein's troops are integrated with the society in which they live. They study history and moral philosophy; they are citizen-soldiers. Johnnie Rico has doubts, hesitations, humanity. One can't imagine giving him orders to open fire on a stadium-full of civilians as does Falkenberg.
Pournelle's soldiers, on the other hand, have no society but their unit and no moral direction other than that of the men on horseback who lead them. Falkenberg is a perfect embodiment of military Fuhrerprinzip, remote even from his own men, a creepy and opaque character who is not successfully humanized by an implausible romance near the end of the sequence. The Falkenberg books end with his men elevating an emperor, Prince Lysander who we are all supposed to trust because he is such a beau ideal. Two thousand years of hard-won lessons about the maintainance of liberty are thrown away like so much trash.
In fact, the underlying message here is pretty close to that of classical fascism. It, too, responds to social decay with a cult of the redeeming absolute leader. To be fair, the Falkenberg novels probably do not depict Pournelle's idea of an ideal society, but they are hardly less damning if we consider them as a cautionary tale. "Straighten up, kids, or the hero-soldiers in Nemourlon are going to have to get medieval on your buttocks and install a Glorious Leader." Pournelle's values are revealed by the way that he repeatedly posits situations in which the truncheon of authority is the only solution. All tyrants plead necessity."
Full text at http://armedndangerous.blogspot.com/2002_11_10_arm edndangerous_archive.html
As far as the quickie test goes, yeah, sure, they have a Libertarian axe to grind. However, the site really did get some rave reviews from some big political wonks. The two axis idea is interesting.
Of course, are there only TWO axes? I rather doubt it. Let's see an N-space version with a more elaborate questionnaire, minus the Libertarian commentary.
Many political columnists and major newspapers would disagree with you. The test has been called "brilliant."
With regard to Pournelle's Axes,
a) there's no fun test to take b) you "think" you know where you stand already, so "finding" yourself on Pournelle's coordinate system isn't very interesting c) And may I say, Pournelle pisses me off, and so does his militaristic fiction. Anyone who can "solve" a planet-wide social problem by killing an entire stadium full of malcontents, even in a work of fiction, should be placed in his own "Nazi" designation. But I guess that proves Pournelle belongs in the Baen stable, along with Weber, who routinely kills off millions of intelligent sapiens, human and non-human, in the Honor Harrington series (and elsewhere) without an eyeblink.
Neither "conservatives" nor "liberals" necessarily believe in freedom. Each camp attempts to limit different kinds of freedom to accomplish its objectives.
The political landscape can be dumbed down to a simple Cartesian coordinate system: personal freedom on one axis, economic freedom on another.
Whereas a liberal will tend to deprive you of economic freedom in order redistribute wealth and fund social programs, a conservative will tend to deprive you of personal freedom in order to control your behavior.
If I'm one page ahead of you in the manual, I'm a genius. If you're one page ahead, you're a genius.
But we both know that neither one of us is a genius, and anyone with half a brain can memorize a manual. So thanks for helping out, but look for "respect" somewhere else.
Talk about antagonizing your big money corporate sponsors, including the guy who built the new building around the corner on Vassar St. Gutsy move, but not a terribly bright one, unless self-immolation is their next plan.
Re:Capability Maturity Model
on
QA != Testing
·
· Score: 4, Insightful
Let's also not forget that the DoD has had a number of programs over the years that attempt to determine whether such methodologies work, and/or attempt to determine what the best methodology might be. Of course, everyone using such a methodology invariably reports that it works fantastically, either because they want the next deal, or because they want their particular methodology to be King of the Hill.
I worked for a DoD contractor for a while, so I've seen it from the inside -- and, I'd say that using DoD-funded development projects as a measure of anything is ludicrous. Years after my DoD experience, I remember interviewing for a lead hardware engineer. I needed a guy who could build a Z80-based microcontroller board. I had one tech to give him, that's it. And, I needed the board laid out and working in 4 months. I knew this was possible, because I had worked with plenty of hardware engineers who could do this in their sleep, with one layout and no rework. Remember, this is 4mhz, folks. Crosstalk? What crosstalk? Hell, armed with a book and help from the vendor in the form of boilerplate designs, even I could have taken a stab at it, and the last time I hacked hardware was years ago in a college course.
Anyway, this guy was from a large defense contractor, R******n. Turns out he was PART OF A TEAM that had built a Z80 CPU board over the last 18 months. His particular responsibility had been the DRAM circuit. According to him there were 20 other hardware engineers on the project. Yup, he said TWENTY. That's right. T-W-E-N-T-Y.
The $64,000 question is, what the heck was this guy doing for those 18 months? I was stunned. So was he, when he realized what was expected of him in the "real" world. I don't care how MIL-spec'd his board had to be, or how much vibration and radiation testing they had to do, or how many $22,000 toilets they had to flush it down to test it, 18 months and 20 people is ridiculous. Period.
I found someone else for the position. He built the board, delivered it ahead of schedule, and it worked fine. And while he was doing that, in parallel he designed and built another board for an RF hand-held. I guess he wouldn't have fit in at R******n. Nothing against R******n, though. Largest employer in the state. Love you guys. Keep everyone working.
Hmm, I think the sales guy was trying to tell the customer that it's no big whoop to fix something that the customer wants fixed. The sales guy is deliberately minimizing the importance of this to keep the issue under control. So, he's minimizing what the coders do as well, in order to make his point. What would you have him do instead, make a Federal case out of it?
"Oh, well, goodness, we'll just consult one of our Senior Programming Architects about that, Mr. Customer. I'm sure with his vast knowledge of the computer sciences, he'll be able to straighten this glitch right out! Oh, wait a minute, look, we have Chester Nerdbrain sitting right here, one of our finest Senior Programming Architects. Chester, take your finger out of your nose and explain to Mr. Customer, here, how easy it is to change this prompt."
Not quite as smooth, especially when Chester trips over his chair, drops a permanent marker in the customer's coffee, and otherwise betrays symptoms of nervousness that anyone who does not normally spend his whole life in front of customers is prone to display.
I like the sales guy's approach, myself. I'm not offended at being called a "C coding monkey." Call me anything you want, just pay me.
Amen to that. I've made a mini career out of stepping into troubled situations and fixing them. The last one I did had spent over $30M on useless third-party software licenses, deals, and consultants, to try to stitch together some sort of application framework that they could sell. Net net of all that was exactly zero. It all had to go, every last bit of it.
There's a lot of crap out there. It's hard to figure out whether it's crap or not before you really get into it, even if you know what you're doing. It's especially hard if you're a PHB or even an educated PHB. And some of it isn't even crap, it's just the wrong tool for the job.
Here's a true story: our company had an ongoing task of moving and translating data between systems. Some PHB reasoned, based on his latest issue of EE Times: "We need an ETL tool!" So he ran out and bought an ETL tool for $200,000, and sent a half dozen people out of the building to train for a month.
Problem is, it's never the same two systems, and it's never done more than once. Oops! An ETL tool is the worst possible choice for the job. Custom Perl scripts would work better. And did.
As far as I know, the $200,000 ETL tool is still on the shelf where the PHB put it, before we kicked his sorry ass out of the company.
Let's not forget how long it took them, either. I worked with some of the Shuttle programmers. I shared an office with one pudgy little 40-something bald guy who wrote about three lines of code per month. He had a big loose-leaf notebook full of all his test cases and his test jigs and his interfaces and his error checks. He worked for another guy who used to hold 1/2 day meetings every two days. In the time I shared a cubicle with him, probably 3 months, he had accomplished a whole lot of nothing.
As far as how together and structured the Shuttle group was, I remember the day there was a head crash on the 3330 drive that held all their source code. It was like turning over an ant nest, programmers scurrying around the halls screaming, etc. Don't believe everything those people write about how well they were organized and how wonderful everything was.
Because I'm feeling contrarian, too, I'll call you on your claims. Virtualization can be very cheap, and very easy to administer. VM/370 was based on CP/CMS, which was developed using government money, so it was open source. In an early example of why open source is such a good idea, several big timesharing companies took CP/CMS and hacked CMS to get rid of the real I/O instructions (CCW's, or Channel Command Words) inside it. You see, CMS was a real single-user OS. So CMS could run on bare hardware, just like it could run under CP. Thus, CMS issued CCW's to talk to what CMS thought were "real" I/O processors on "real" hardware. Which meant that when CMS ran under CP in user (non-privileged) mode, every time the machine tripped over one of these CCW's, an illegal instruction trap was generated. The trap was caught by CP, which then parsed and painstakingly emulated the CCW in an extremely complex routine called "CCWTRANS." Many have lost their sanity reading the code to CCWTRANS. Anyway, although really cool, this strategy also turned out to be really expensive.
Meanwhile, because they all had the source code to CP/CMS, the timesharing companies all came up with the same basic great idea. They hacked CMS to get rid of the CCW's, and replaced the CCW's with the equivalent of fast BIOS traps into CP. So CP didn't have to translate or emulate anything any more, things began to run at native speed, and suddenly everything was lickety-split fast again. In fact, this hack sped up CMS to the point where the premier speed vendor, National CSS, could run 250 users with decent performance on a 370/168 mainframe. VM/370, meanwhile, topped out at a measly 60-70 users. IBM either never figured out the hack, or as is more probable, wasn't very interested in VM/370 anyway (their cash cow was and still is OS/MVT and its successors).
So you are correct; VM/370 was a dog. But CP/CMS, hacked with traps, was totally amazing. I was there; I was a CP system programmer; I know.
The modern equivalent of this strategy is called Xen. Xen has been a topic here before. I predict you will see a lot more about it in the future.
Right, and what the hell does "Enterprise Resource Planning" mean?
It used to mean the combination of MRP ("Material Requirements Planning") + Accounting. Then along came PeopleSoft and kinda changed it to HR + Accounting. Then along came Siebel and everyone scurried to make it MRP + HR + accounting + CRM (not quite there yet, though). Then they noticed Kronos and they all scurried to make it MRP + HR + Accounting + CRM + Time & Attendance. And failed, because Time & Attendance is a big pain in the butt. Heh. So they partnered with Kronos instead.
The march of "embrace and extend" continues. Next app up: Expense Reporting (say bye-bye to Concur, etc., that's an easy app). Already on deck: data warehousing (say bye-bye to Cognos, Business Objects, etc., say hello to SAP BW). Soon to come: business process automation (say bye-bye to Ariba, etc.)
And so on, if you believe the pundits.
"ERP" has become a meaningless acronym, an umbrella under which every business app known to man is rammed into the same stinking pile of multi-million dollar shit. At some point it will probably implode from its own weight, and we'll go right back to the "best of breed" interoperable software model.
But it will be a while yet. I suspect in the meantime there will be some Open Source alternatives. I sure hope so.
This is so reminiscent of other stupid claims of the past. "Cars can't go 60 mph." "Planes can't go supersonic." "Computers can't play checkers." "Computers can't play (pick one) expert level/master level/grandmaster level/world champion level chess." And so on.
Now it's "Open source can't build ERP systems." As if it's that f-ing hard to glue together an MRP system, an accounting package, and maybe some CRM and HR software. I mean, duh.
ha, but the way you eat someone's lunch the way the Indians are doing to the rest of the world is to get good at the crappy stuff that's out there and then stay on top of it, regardless of the pain.
The scary part is, I happen to know (from working with Indians) they ARE teaching classes on this stuff, or at least similar stuff. I could use some classes myself. I just wrote a few pages of jscript and I am in severe browser standards pain just like I was the last time I did this, 2 years ago. There's still no decent place to find all the tricks of the trade. And finding the reasonable information in between all the stuff that the w3c "claims" is there but isn't, and all the stuff that random web pages "claim" is there, but is actually only available in IE, is a real problem.
I wish somebody was teaching classes at our shop. It's such a moving target, most of the info out there (books included) is all worried about stuff that I couldn't care less about any more. Those big Indian shops have whole reams of jscript floating around to do all the "standard" stuff that I'm having to invent from scratch. Normally we're way faster programming than any Indian shop, but every time we dive into this shit they blow our fucking doors off.
Yes, mainframes are really, really good at I/O, which is a concept that many people didn't get (DEC for one, when they fell flat on their faces trying to leverage the VAX into mainframe land) and still don't get. The CDC 7600 was surrounded by 6600's to spoon feed it, just as IBM mainframes have channel controllers (real processors) separate from the CPU to do the same thing.
However, your memory of 3270's is a lot different than mine. How about when that nifty wifty 3270 cluster controller went south, as it did at our shop multiple times per day? And maybe you could pump bits at it pretty fast, but under TSO your Q1 response time was 10 to 20 seconds during peak times, so it didn't really matter how high-speed the intrinsic channel was.
3270's were designed for forms entry with CICS apps, basically. It's a record-oriented device (like all IBM devices) which just doesn't add up to a very good user experience. You need character interrupts, and you need fast service for those interrupts. The mainframe secret is to let the CPU compute uninterrupted by batching up terminal I/O, screw the user.
Which is exactly the Web experience today. Fill in a form, press a button, wait. Back to the future! In the limit, it doesn't matter whether you're connecting back to get a whole new page, or whether you're doing some socket hackery under the covers to return a response to some jscript code. Either way, you're waiting for a server that's servicing a bazillion other people, so conceptually you might as well be running CICS thirty years ago.
Yeah, yeah, the screens are prettier now, you can download jscript and java applets, yadda yadda. You could program the 3270, too, with sufficient pain. Wake me up when this jscript shit actually works reasonably well. Just coming up for air after writing a few pages of it, and boy am I pissed. Standards all over the place. IE style.backgroundColor is "#ffffff", FF's is "rgb(255, 255, 255)". There are religious wars over "document.all", with some w3c fanatics claiming the world should have to write hideous tree-walkers to iterate over the DOM (so prove me wrong, post a code frag to show how easy it is). It never ends.
(that 3270 keyboard was GREAT. Nothing like it today. Typing on spongebob squarekeys at the moment).
Nice call! Because of the domain area of this application (a peculiar and very custom combination of document and process management), there is strong reason to suspect that they haven't thought through the data model sufficiently. I also understand that this app was cobbled together in hurry-hurry mode, which is further evidence for not a lot of profound thought.
As you imply, if the vendor had stored the customer's data in an ordinary database, then no matter how crummy their data model was, they'd have been able to cobble together a flat file somehow. The fact that they find this difficult -- and haven't done it to date, under pressure and at the request of a customer for whom they ought to be bending over -- suggests that they have painted themselves into a corner from which it is either difficult or expensive to escape.
I'm tempted to generalize from this that there might be lots of other situations where people are making similar mistakes.
Thank you for the excellent points. I was going to make many of them.
However, XML can be silly overkill sometimes. Like, for some reason you decide you're going to go XML-happy and store all your customer's data inside weird-ass custom XML, when an ordinary database would have done just fine. Then the customer (a Fortune 500 company, a BIG customer) calls you up and says, "I want to write my own reports, so do a raw data dump for me, I need a flat file right now."
Oops.
By the way, this is a real-world (embarrassing) example.
Slashdot Mirror
"Bass-o-Matic School of Persuasivist Languaging."
Like it, Centurion, like it.
Oh, please. First you agree that Groklaw "does indeed focus on legal commentary," and then you complain that not every commentary is footnoted legal discussion. Make up your mind.
My personal opinion of Groklaw is irrelevant, but here it is: PJ is a talented commentator on legal issues and has been a catalyst for the necessary and useful anti-SCO mobilization that was (and is) required to send them back to the hole they crawled out of.
PJ's other opinions are much less useful, although I am interested also in the software patent work she is doing.
As far as who she is, I couldn't care less.
Go back under your bridge. If you read Groklaw, you know that it is hardly a "blowhard blog." Rather, it is a collection of commentary and court documents on the SCO/IBM case and on other legal issues affecting the FOSS community. If you don't like the commentary, you can add to it -- thoughtful comments from any point of view are welcomed.
Furthermore, PJ has been quite forthright about who is paying her (nobody), and she's already defended herself against far more clever attacks than your silliness. The simple basis for her credibility is the fact that every commentary she posts is heavily footnoted from court documents, all of which are carefully documented and archived for posterity. If you don't agree with her commentary, you can argue from the facts, which are helpfully provided for you right on the site. There is a strong reason why Groklaw is heavily trafficked by both IBM and SCO attorneys -- and that is that it is an informational site of high value to both parties, as well as to interested observers, which you, apparently, are not.
Bottom line: PJ's identity is irrelevant, and so, my little snowflake, are you.
I'm sorry, but that is a deeply irritating post. If you have something intelligent to say, why not say it, and educate the rest of us?
You say: "If these people have a need for more complicated applications we should provide them the tools and training so that they can build them themselves..."
I really don't think they will become programmers, do you?
Then you continue: "...or fund the projects so technicians, like me, can build such applications for them."
I am not aware of any company that has been successful with such an approach. In fact, I can think of several that have crashed and burned spectacularly. It doesn't work in practice, because the analyst is not able to communicate completely enough or effectively enough to the programmer. Typically the analyst him/herself doesn't fully understand the scope of the problem. Which is part of why Excel is such a neat tool for them. It is exploratory in nature.
So let's focus on the problem, and pretend for a moment that you are one of these analysts. You have something you need to deliver. The only tool you know is Excel. What do you do? You can't run down the hall to some development group, which is already way over their heads trying to meet the existing schedule, and ask them to build something custom for you; they'll just laugh at you. Your only choice is to get the job done with the tool that you know.
So, here are some practical suggestions to help wean these people off doing bad things with Excel:
1)) Give them an Excel back end to your app. That way, they can customize the output, and take it farther. You know they will end up doing this anyway, typically by painfully dumping data from your database and loading it back into Excel manually; so why not make this easy for them, and take all the manual errors out of the process?
2) See if there are VBA type things that they do over and over again that can be pre-packaged for them, so that these constructs work out of the box and are bug-free. Make them a nice toolbox and train them on it. This is kinda what the original book we're supposed to be discussing is trying to do, isn't it? Um.
3) There are plenty of Excel-based collaboration tools that manage Excel use across multiple people. Find one and introduce it to the company.
Are these things hard? Some of them are, especially creating Excel interactions with web apps, unless you go ActiveX which is a disaster. But there are other ways to do this, which I will (arrogantly) leave as an exercise for the reader.
So IMO it is possible to make the situation better. But sitting back in our developer's chairs thinking that we can do something about it by trying to write enough apps to cover all the bases for these people isn't a practical point of view.
You complain that your customers -- financial analysts all -- are building stuff in Excel. According to you this is bad. I kinda line up on their side of the fence on this one, sorry. You'll have to rip Excel out of their cold, dead fingers, or replace it with something much, much better. And that ain't Calc, which is a me-too, not an evolutionary step.
I would think you'd be happy at seeing someone try to help these people build manageable Excel models and simple Excel apps. Let's face it:
1) They will continue to do this, it's fundamental to doing their job. If they need to analyze something quickly, they can't wait for a bunch of quiche-eating Java weenies to argue about the object model for the next six months.
2) There's nothing you can do to stop them.
3) Really. Nothing.
4) So you might as well help them to do what they do, only do it better.
Reminds me of a Steven Seagal movie:
"Well, if I can't control you, I might as well use you, right, son?"
"That's affirmative, sir."
But that's probably too practical a viewpoint for this forum.
Now THAT'S funny.
Very incisive post, thanks. If I had mod points you'd get 'em.
True, nobody forces anybody to read or view anything, but you have to admit that stadium scene was really grim.
m edndangerous_archive.html
Quoting Eric Raymond,
"The difference between Heinlein and Pournelle starts with the fact that Pournelle could write about a cold-blooded mass murder of human beings by human beings, performed in the name of political order, approvingly -- and did.
But the massacre was only possible because Falkenberg's Legion and Heinlein's Mobile Infantry have very different relationships with the society around them. Heinlein's troops are integrated with the society in which they live. They study history and moral philosophy; they are citizen-soldiers. Johnnie Rico has doubts, hesitations, humanity. One can't imagine giving him orders to open fire on a stadium-full of civilians as does Falkenberg.
Pournelle's soldiers, on the other hand, have no society but their unit and no moral direction other than that of the men on horseback who lead them. Falkenberg is a perfect embodiment of military Fuhrerprinzip, remote even from his own men, a creepy and opaque character who is not successfully humanized by an implausible romance near the end of the sequence. The Falkenberg books end with his men elevating an emperor, Prince Lysander who we are all supposed to trust because he is such a beau ideal. Two thousand years of hard-won lessons about the maintainance of liberty are thrown away like so much trash.
In fact, the underlying message here is pretty close to that of classical fascism. It, too, responds to social decay with a cult of the redeeming absolute leader. To be fair, the Falkenberg novels probably do not depict Pournelle's idea of an ideal society, but they are hardly less damning if we consider them as a cautionary tale. "Straighten up, kids, or the hero-soldiers in Nemourlon are going to have to get medieval on your buttocks and install a Glorious Leader." Pournelle's values are revealed by the way that he repeatedly posits situations in which the truncheon of authority is the only solution. All tyrants plead necessity."
Full text at http://armedndangerous.blogspot.com/2002_11_10_ar
As far as the quickie test goes, yeah, sure, they have a Libertarian axe to grind. However, the site really did get some rave reviews from some big political wonks. The two axis idea is interesting.
Of course, are there only TWO axes? I rather doubt it. Let's see an N-space version with a more elaborate questionnaire, minus the Libertarian commentary.
Many political columnists and major newspapers would disagree with you. The test has been called "brilliant."
With regard to Pournelle's Axes,
a) there's no fun test to take
b) you "think" you know where you stand already, so "finding" yourself on Pournelle's coordinate system isn't very interesting
c) And may I say, Pournelle pisses me off, and so does his militaristic fiction. Anyone who can "solve" a planet-wide social problem by killing an entire stadium full of malcontents, even in a work of fiction, should be placed in his own "Nazi" designation. But I guess that proves Pournelle belongs in the Baen stable, along with Weber, who routinely kills off millions of intelligent sapiens, human and non-human, in the Honor Harrington series (and elsewhere) without an eyeblink.
Neither "conservatives" nor "liberals" necessarily believe in freedom. Each camp attempts to limit different kinds of freedom to accomplish its objectives.
The political landscape can be dumbed down to a simple Cartesian coordinate system: personal freedom on one axis, economic freedom on another.
Whereas a liberal will tend to deprive you of economic freedom in order redistribute wealth and fund social programs, a conservative will tend to deprive you of personal freedom in order to control your behavior.
Take this test, it's interesting: http://www.theadvocates.org/quiz.html
If I'm one page ahead of you in the manual, I'm a genius. If you're one page ahead, you're a genius.
But we both know that neither one of us is a genius, and anyone with half a brain can memorize a manual. So thanks for helping out, but look for "respect" somewhere else.
Talk about antagonizing your big money corporate sponsors, including the guy who built the new building around the corner on Vassar St. Gutsy move, but not a terribly bright one, unless self-immolation is their next plan.
Let's also not forget that the DoD has had a number of programs over the years that attempt to determine whether such methodologies work, and/or attempt to determine what the best methodology might be. Of course, everyone using such a methodology invariably reports that it works fantastically, either because they want the next deal, or because they want their particular methodology to be King of the Hill.
I worked for a DoD contractor for a while, so I've seen it from the inside -- and, I'd say that using DoD-funded development projects as a measure of anything is ludicrous. Years after my DoD experience, I remember interviewing for a lead hardware engineer. I needed a guy who could build a Z80-based microcontroller board. I had one tech to give him, that's it. And, I needed the board laid out and working in 4 months. I knew this was possible, because I had worked with plenty of hardware engineers who could do this in their sleep, with one layout and no rework. Remember, this is 4mhz, folks. Crosstalk? What crosstalk? Hell, armed with a book and help from the vendor in the form of boilerplate designs, even I could have taken a stab at it, and the last time I hacked hardware was years ago in a college course.
Anyway, this guy was from a large defense contractor, R******n. Turns out he was PART OF A TEAM that had built a Z80 CPU board over the last 18 months. His particular responsibility had been the DRAM circuit. According to him there were 20 other hardware engineers on the project. Yup, he said TWENTY. That's right. T-W-E-N-T-Y.
The $64,000 question is, what the heck was this guy doing for those 18 months? I was stunned. So was he, when he realized what was expected of him in the "real" world. I don't care how MIL-spec'd his board had to be, or how much vibration and radiation testing they had to do, or how many $22,000 toilets they had to flush it down to test it, 18 months and 20 people is ridiculous. Period.
I found someone else for the position. He built the board, delivered it ahead of schedule, and it worked fine. And while he was doing that, in parallel he designed and built another board for an RF hand-held. I guess he wouldn't have fit in at R******n. Nothing against R******n, though. Largest employer in the state. Love you guys. Keep everyone working.
Hmm, I think the sales guy was trying to tell the customer that it's no big whoop to fix something that the customer wants fixed. The sales guy is deliberately minimizing the importance of this to keep the issue under control. So, he's minimizing what the coders do as well, in order to make his point. What would you have him do instead, make a Federal case out of it?
"Oh, well, goodness, we'll just consult one of our Senior Programming Architects about that, Mr. Customer. I'm sure with his vast knowledge of the computer sciences, he'll be able to straighten this glitch right out! Oh, wait a minute, look, we have Chester Nerdbrain sitting right here, one of our finest Senior Programming Architects. Chester, take your finger out of your nose and explain to Mr. Customer, here, how easy it is to change this prompt."
Not quite as smooth, especially when Chester trips over his chair, drops a permanent marker in the customer's coffee, and otherwise betrays symptoms of nervousness that anyone who does not normally spend his whole life in front of customers is prone to display.
I like the sales guy's approach, myself. I'm not offended at being called a "C coding monkey." Call me anything you want, just pay me.
Amen to that. I've made a mini career out of stepping into troubled situations and fixing them. The last one I did had spent over $30M on useless third-party software licenses, deals, and consultants, to try to stitch together some sort of application framework that they could sell. Net net of all that was exactly zero. It all had to go, every last bit of it.
There's a lot of crap out there. It's hard to figure out whether it's crap or not before you really get into it, even if you know what you're doing. It's especially hard if you're a PHB or even an educated PHB. And some of it isn't even crap, it's just the wrong tool for the job.
Here's a true story: our company had an ongoing task of moving and translating data between systems. Some PHB reasoned, based on his latest issue of EE Times: "We need an ETL tool!" So he ran out and bought an ETL tool for $200,000, and sent a half dozen people out of the building to train for a month.
Problem is, it's never the same two systems, and it's never done more than once. Oops! An ETL tool is the worst possible choice for the job. Custom Perl scripts would work better. And did.
As far as I know, the $200,000 ETL tool is still on the shelf where the PHB put it, before we kicked his sorry ass out of the company.
Let's not forget how long it took them, either. I worked with some of the Shuttle programmers. I shared an office with one pudgy little 40-something bald guy who wrote about three lines of code per month. He had a big loose-leaf notebook full of all his test cases and his test jigs and his interfaces and his error checks. He worked for another guy who used to hold 1/2 day meetings every two days. In the time I shared a cubicle with him, probably 3 months, he had accomplished a whole lot of nothing.
As far as how together and structured the Shuttle group was, I remember the day there was a head crash on the 3330 drive that held all their source code. It was like turning over an ant nest, programmers scurrying around the halls screaming, etc. Don't believe everything those people write about how well they were organized and how wonderful everything was.
Because I'm feeling contrarian, too, I'll call you on your claims. Virtualization can be very cheap, and very easy to administer. VM/370 was based on CP/CMS, which was developed using government money, so it was open source. In an early example of why open source is such a good idea, several big timesharing companies took CP/CMS and hacked CMS to get rid of the real I/O instructions (CCW's, or Channel Command Words) inside it. You see, CMS was a real single-user OS. So CMS could run on bare hardware, just like it could run under CP. Thus, CMS issued CCW's to talk to what CMS thought were "real" I/O processors on "real" hardware. Which meant that when CMS ran under CP in user (non-privileged) mode, every time the machine tripped over one of these CCW's, an illegal instruction trap was generated. The trap was caught by CP, which then parsed and painstakingly emulated the CCW in an extremely complex routine called "CCWTRANS." Many have lost their sanity reading the code to CCWTRANS. Anyway, although really cool, this strategy also turned out to be really expensive.
Meanwhile, because they all had the source code to CP/CMS, the timesharing companies all came up with the same basic great idea. They hacked CMS to get rid of the CCW's, and replaced the CCW's with the equivalent of fast BIOS traps into CP. So CP didn't have to translate or emulate anything any more, things began to run at native speed, and suddenly everything was lickety-split fast again. In fact, this hack sped up CMS to the point where the premier speed vendor, National CSS, could run 250 users with decent performance on a 370/168 mainframe. VM/370, meanwhile, topped out at a measly 60-70 users. IBM either never figured out the hack, or as is more probable, wasn't very interested in VM/370 anyway (their cash cow was and still is OS/MVT and its successors).
So you are correct; VM/370 was a dog. But CP/CMS, hacked with traps, was totally amazing. I was there; I was a CP system programmer; I know.
The modern equivalent of this strategy is called Xen. Xen has been a topic here before. I predict you will see a lot more about it in the future.
Right, and what the hell does "Enterprise Resource Planning" mean?
It used to mean the combination of MRP ("Material Requirements Planning") + Accounting. Then along came PeopleSoft and kinda changed it to HR + Accounting. Then along came Siebel and everyone scurried to make it MRP + HR + accounting + CRM (not quite there yet, though). Then they noticed Kronos and they all scurried to make it MRP + HR + Accounting + CRM + Time & Attendance. And failed, because Time & Attendance is a big pain in the butt. Heh. So they partnered with Kronos instead.
The march of "embrace and extend" continues. Next app up: Expense Reporting (say bye-bye to Concur, etc., that's an easy app). Already on deck: data warehousing (say bye-bye to Cognos, Business Objects, etc., say hello to SAP BW). Soon to come: business process automation (say bye-bye to Ariba, etc.)
And so on, if you believe the pundits.
"ERP" has become a meaningless acronym, an umbrella under which every business app known to man is rammed into the same stinking pile of multi-million dollar shit. At some point it will probably implode from its own weight, and we'll go right back to the "best of breed" interoperable software model.
But it will be a while yet. I suspect in the meantime there will be some Open Source alternatives. I sure hope so.
This is so reminiscent of other stupid claims of the past. "Cars can't go 60 mph." "Planes can't go supersonic." "Computers can't play checkers." "Computers can't play (pick one) expert level/master level/grandmaster level/world champion level chess." And so on.
Now it's "Open source can't build ERP systems." As if it's that f-ing hard to glue together an MRP system, an accounting package, and maybe some CRM and HR software. I mean, duh.
Parent comment is all you need to read. Nothing else to see here. Nice job, RichardX!
ha, but the way you eat someone's lunch the way the Indians are doing to the rest of the world is to get good at the crappy stuff that's out there and then stay on top of it, regardless of the pain.
The scary part is, I happen to know (from working with Indians) they ARE teaching classes on this stuff, or at least similar stuff. I could use some classes myself. I just wrote a few pages of jscript and I am in severe browser standards pain just like I was the last time I did this, 2 years ago. There's still no decent place to find all the tricks of the trade. And finding the reasonable information in between all the stuff that the w3c "claims" is there but isn't, and all the stuff that random web pages "claim" is there, but is actually only available in IE, is a real problem.
I wish somebody was teaching classes at our shop. It's such a moving target, most of the info out there (books included) is all worried about stuff that I couldn't care less about any more. Those big Indian shops have whole reams of jscript floating around to do all the "standard" stuff that I'm having to invent from scratch. Normally we're way faster programming than any Indian shop, but every time we dive into this shit they blow our fucking doors off.
Have I mentioned how much I hate this?
ah, well, back to the salt mines.
Yes, mainframes are really, really good at I/O, which is a concept that many people didn't get (DEC for one, when they fell flat on their faces trying to leverage the VAX into mainframe land) and still don't get. The CDC 7600 was surrounded by 6600's to spoon feed it, just as IBM mainframes have channel controllers (real processors) separate from the CPU to do the same thing.
However, your memory of 3270's is a lot different than mine. How about when that nifty wifty 3270 cluster controller went south, as it did at our shop multiple times per day? And maybe you could pump bits at it pretty fast, but under TSO your Q1 response time was 10 to 20 seconds during peak times, so it didn't really matter how high-speed the intrinsic channel was.
3270's were designed for forms entry with CICS apps, basically. It's a record-oriented device (like all IBM devices) which just doesn't add up to a very good user experience. You need character interrupts, and you need fast service for those interrupts. The mainframe secret is to let the CPU compute uninterrupted by batching up terminal I/O, screw the user.
Which is exactly the Web experience today. Fill in a form, press a button, wait. Back to the future! In the limit, it doesn't matter whether you're connecting back to get a whole new page, or whether you're doing some socket hackery under the covers to return a response to some jscript code. Either way, you're waiting for a server that's servicing a bazillion other people, so conceptually you might as well be running CICS thirty years ago.
Yeah, yeah, the screens are prettier now, you can download jscript and java applets, yadda yadda. You could program the 3270, too, with sufficient pain. Wake me up when this jscript shit actually works reasonably well. Just coming up for air after writing a few pages of it, and boy am I pissed. Standards all over the place. IE style.backgroundColor is "#ffffff", FF's is "rgb(255, 255, 255)". There are religious wars over "document.all", with some w3c fanatics claiming the world should have to write hideous tree-walkers to iterate over the DOM (so prove me wrong, post a code frag to show how easy it is). It never ends.
(that 3270 keyboard was GREAT. Nothing like it today. Typing on spongebob squarekeys at the moment).
Nice call! Because of the domain area of this application (a peculiar and very custom combination of document and process management), there is strong reason to suspect that they haven't thought through the data model sufficiently. I also understand that this app was cobbled together in hurry-hurry mode, which is further evidence for not a lot of profound thought.
As you imply, if the vendor had stored the customer's data in an ordinary database, then no matter how crummy their data model was, they'd have been able to cobble together a flat file somehow. The fact that they find this difficult -- and haven't done it to date, under pressure and at the request of a customer for whom they ought to be bending over -- suggests that they have painted themselves into a corner from which it is either difficult or expensive to escape.
I'm tempted to generalize from this that there might be lots of other situations where people are making similar mistakes.
Thank you for the excellent points. I was going to make many of them.
However, XML can be silly overkill sometimes. Like, for some reason you decide you're going to go XML-happy and store all your customer's data inside weird-ass custom XML, when an ordinary database would have done just fine. Then the customer (a Fortune 500 company, a BIG customer) calls you up and says, "I want to write my own reports, so do a raw data dump for me, I need a flat file right now."
Oops.
By the way, this is a real-world (embarrassing) example.