Slashdot Mirror
Philosophies of IT
Lion Templin writes
"Despite the extremely dry topic,
"Philosophical Changes in 1990's Information Technology"
covers a broad history of IT and makes a strong suggestion
as to why the industry is what it is today. A main focus
is the differing philsophies of traditional "academia"
related 'mainframers' versus the fast-paced 'micros' that
predominate most of the IT industry today. Written as
university research, it's been read by several people in
the IT field and received good responses."
Written as research and reviewed by people who know...
Come on what a bunch of crap. This "Research" was 75% history, some of which was wrong. This paper came off to me as a bunch of whining. The HW all 'blackbox', GUI users act as magicians would if hte magic didn't go right. What a bunch of bull.
I could write a better paper about software quality and my degree is Aerospace Engineering.
These people don't know how their car works either , nor their refrigerator, phone, tv, cockoo clock, etc. So what. The only insight of this paper is the idiocy that passes for academics.
jmr
I can't believe he wrote this:
...employees working long hours, often with little or no overtime. Many are even salaried.
Ummm yes, I like technology, but I like getting paid too.
Technology is driven by end users. You should here what the end users here think about the PhDs hidden away working on their "pet projects".
Sure, if you can't talk to users and like sitting in your basement writing code for free its up to you. But its not for most of us.
Richard
I think mainframe land isn't as great as the article makes it out to be.
Most mainframe work I've seen looks boring as hell.
If you want to do interesting and creative stuff you should be doing client/server.
While I'm afraid I don't know enough about IT history to comment intelligently on this paper's veracity or insight, I do think that its author has been more than a little influenced by Dan Simmons' Hyperion books. Read Templin's paper and then see if this sounds familiar: ignorant humanity is addicted to the power of technologies it doesn't understand. These technologies are ministered to by humans, but actually created and controlled by a mysterious group of entities outside the bounds of reality.
The paper muddles the early history of computing,
probably it is by a youngster with little
experience in the field.
Probably better to characterize "establishment"
versus freelance programming. In every decade
the freelance systems seem to turn into the
establishment of the next.
I read as much as I could stand then stopped. What I read (the punctuation and grammar notwithstanding) was poorly aligned with what I know of 25 years of working in this field and, in my opinion, a very shaky piece of analysis.
... you might disagree with them, but at the very least they are speaking from the coalface. The author seems to me
It's the kind of stuff I used to write before I learned (did I?) that if you haven't discussed your basic premise with a few more seasoned practitioners first, you will be most likely get roasted later.
As an example, the section on software engineering is simply naive. There is a whole corpus of work out there that blows away the simplistic view that this paper takes. Read Barry Boehm, Ed Yourdon (if you must) and a ton of others
to have taken a very limited experience and conflated that to be some kind of overview of an entire discipline.
I have seen this type of paper before, but mainly
in the field of social science.
Mike Banahan
> I found this paper full of blatant grammar, historical and conceptual errors.
Yes. "A new class [...] were born". "tenticals". Ouch. "Only six years after the development of the integrated circuit, Digital Equipment Corporation created the PDP-6, a mass produced and widely available minicomputer. With this began a long and prosperous history of pure computer science." Oh dear.
Another anonymous coward further down remarks the paper is probably written by a youngster. That thought struck me too, and a glance at the home page confirms it.
I was quite amused by the highfalutin "space opera" phrasing which appears in places.
Behold, unto the world did the English bestow their very Language.
Hehehehehe!
London, UK
The initial few pages were passable until I encountered a gratuitous swipe at Bill Gates for the infamous "640K should be enough..." quote. I stopped reading any further. Was this added just for a headline grab? An excuse to include an obviously useless (even at the time) assertion? There were many similar engineering limitations and poor design choices made at the time, and by a cast of thousands. Why single out one person (however vacuous they were or are now)? I couldn't be bothered reading any further to see if Steve Jobs gets ridiculed for the closed box design of the first Macintosh.
I think an english prof I had a few years can give the best grade for this paper.
"I had to give some guy an F. He turned in shit punctuated with bullshit."
Here is a review of the review, with convenient bullet points for your reading pleasure:
* The author confuses mainframe and unix programmers - the former are totally un-academic and boring drudge workers, the latter are intersting creative people with a theoretical bent. Owing to this confusion, he focuses on unix and totally omits the real big iron software that runs most corporate databases - IBM mainframes.
Leaving out the biggest behemoth in IT? That's a gaping hole in any study like this.
* The network chapter draws a conclusion about the internet that isn't just wrong, but the exact opposite. He writes:
"The atmosphere of academia has been forever destroyed by this epoch, leaving the original users to ponder what to do next."
Far from it, the net resurrected academic interest in programming, making it a new hobby for intelligent teenagers who would never have been interested in programming if they hadn't bumped into javascript, perl, cgi, multiplayer quake scripts, etc. Yes, the net has injected a fun and vibrant spirit into the programming community, which has expanded to include the general public brought into contact with it thru lameass annoying animated web pages.
* The chapter on software engineering was insightful in narrating how programming became a corporate tool of hugely bureaucratic dimensions.
Coming next - a philosophical essay on the psychological impact of quake playing on the Taliban
In my dealings with users, the main things that get highlighted to me is a divorce, at the bottom level, between the IT staff and the end users. What needs to be recognised across the board in IT is that the systems are a tool - the real income generator is the productive end user that does the work that brings in the bucks. The villain of the piece isn't usually the software developer, but the tehnical support people who sit behind phones giving dismissive answers, or the office techie more concerned with playing with the server than the key jobs of protecting the data and --the big problem-- making those end users more productive! If they did their job OK, it would feed through the IT section, and any problems with in house developments would get through to the developers.
A big bugbear in several firms whose employees I've spoken to in this regard is Word document templates and macros. Tech support never want anything to do with them, blaming the user - neither they or the programmers see them as real computing. So skilled professionals, knowing that the company sacks people who don't adhere strictly to the document standards when preparing reports for clients, end up spending as much time fixing the documents and fighting bugs in templates, as in organizing the information.
So, in addition to your comments - most of which I agree with - I would stress a focus on the general business process and on justifying any IT development in terms of increasing the productivity of the income generating user.
Years later people would either laugh or swear about the infamous Bill Gates quote:
``640k should be enough for anybody.''
In fact it was Bill Gates himself who could be considered, in part, responsible for these short sighted design principals. IBM contracted his
company, then Micro-Soft10, to produce the operating system11 for the IBM PC. And unlike the big iron operating systems that were built on
years of experience12, Gates' new OS was a simple program to allow the user to launch other programs. This OS, named the Disk Operating
System13, is alive and well today in much of it's original form. It even exhibits the 1981 behavior commented on by the above Gates quote: it
imposes a 640k limit on standard memory, which is in fact not even close to enough of what people need today.
What 5 years is he talking about???
"Microsoft's DOS was off and running, getting five (supposed) major revisions18 in only 10 years. It had taken over 20 years of mainframe19 development to get 5 major revisions20."
MVS had 15 revisions before it went BETA. OS/MFT
r16.0 was the first commercial release. The ORIGINAL "DOS" was IBM's DISK Operating System
DOS/VS went through 34 releases by 1972, DOS/VSE
had 15-20 releases by 1985, DOS/VSE SP had 20
releases by 1993 and DOS/VSE ESA has had another
10 releases to the present. At least 80 software
updates in 32 years.
By the time Microsoft can get to it's 80'th update
of Windows, the human race will be as old as the
Dinosaurs.
IBM actually offers a GUARANTEE that it will fix
any reported BUG or pay for the loss. Microsoft
still sells Windows NT with an AS IS/USE AT YOUR
OWN RISK license.
Why do you think that the US Missle Cruiser that
uses Windows NT to control it's engines had to
be towed to port 3 times (the captain typed 0rpm
and the engines crashed with a divide by zero).
``If you have enough experience with what a computer is that if you can convince the Operations Manager that you won't screw something up on your first day, you'll get the job.''
My experience has been that recruiters want 3-5 years of experience with a particular piece of technology before they will even consider you. This is often narrowly defined as a specific programming language on a specific platform writing a specific application for a specific industry. (After it goes un-filled for a year, they'll whine about the "programmer shortage".)
True Story: I tried to get a job doing Java programming. At the time, Java had only been widely available for 1.5 years. The recruiter insisted on *3-5* years experience.
I think the only way to get an interesting job using new technology is to *lie about your experience*. My conscience won't allow me to do this. Note: this is also how the barely-competent people get hired.
sorry, I tried to be positive, but when the guy says 'Mainframers..worked under a scholastic aura of science, slow and methodical'.....
A 'scholastic aura of science'?
programmers?
What's the bottom line: greed has crept into the computer industry; if more people would just be "idealistic" computer science folks instead of "mercenary" software engineers then the world would be a better place.
The one big mistake of Lion's premise that Software Engineering is not new. It's as old as the computer and engineering methodoliges are as old as the stone tools of the neanderthals.
Sorry, "Lion", science and engineering are not incompatible and both will drive developments in the computer industry for a long time.
-ac
P.S. Hey, lamerators : Moderate This!
Posted by nokaos:
the author treats 'software engineering' as something that has happened in the past or may be happening now. i do wonder what definition of the term he is using. it is not in the footnotes.
Well, at least it still responds to pings. :^)
BTW, I see a lot of "What a lamer! I could write a better article than this Lion guy!" I'll say bullshit. If you *can* write a better paper, I want to see it. Otherwise, quit talking out of your asses.
Ah... feel better.
--- Journals are boring; Go to my web page instead
ROTFLMAO
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
I think the paper is pretty darn good, _except_ that the author does not appear to understand the distinction between large UNIX "minicomputer" systems and mainframes, not recognize that the cultures surrounding the systems are different.
For instance, in the section "Software Engineering: The Death of the Programmer" he states "Contrast this with the mainframer's GUI, X Windows". Working at a shop where all the major software still runs on a set of mainframes under MVS, TSO, CICS, and their ilk, I can tell you for sure that the mainframer's "GUI" is a 3270 terminal emulator 8-). This, and other mistakes, lead me to believe that the author wouldn't know "Big Iron" if it was dropped on him.
The difference between mainframes and UNIX-based minicomputers is vast, as is the difference between the cultures of the two systems. The true "mainframer" culture is basically exists in the corporate world, and does not have a large academic component. The UNIX-based minicomputer culture is highly academic (although that has been changing due to the free micro-based UNIX implementations).
- Ken
Hey, if you have the testicular fortitude to tout your writings in a forum like /. then you had better be prepared to take your lumps like an adult.
Submitting ones own paper with a 'glowing' review that does not make it clear one is the author is a smidge over the top IMHO.
- Ken
While the image is still vague, my impression (based my own observation, and the observation of some "clueful" industry consultants I know) of the "new and improved" software developer that companies want embodies the following, in no particular order:
- Confidence, communication and humility.
These are important in teamwork - don't let your views get lost because you're shy - but have the humility to concede when you're proven wrong.
- Being able to see the forest AND the trees.
To elaborate what I mean by that point:
- A specialization in an area of technology such that they can perform "high leverage" activities. I.e. instead of "plowing through" a problem that would take a generalist 3 days, it takes them 6 hours, because of their specialized knowledge. An example would be someone who is intimately familiar with distributed systems development vs. GUI interface design.
- On top of the specialization, a general *understanding* of the issues of management, economics, sociology, psychology, organizational behavior, and entrepreneurship.
I.e. they don't have to KNOW how to run a business, they don't have to LIKE running a business, but they should UNDERSTAND why a business does what it does, and whether it makes sense in the larger picture of the world economy.
Note that the above trait is probably the hardest one to find, mainly because there are so few people - even managers - in employment today that even understand basic principles of economics and innovation/entrepreneurship.
- A genuine belief that software development is first & foremost about *PEOPLE*, not technology.
That's what I see as the desired software developer of the future. Companies don't want "geeks", who spout hubris of their greatness while ignorantly criticizing business. They want "ubergeeks" who have workable SOLUTIONS to business problems, instead of just incessant complaining, and who can communicate their solutions in terms of RESULTS, not the technical details - but when pressed, can express themselves at ANY level of technical detail.
What companies want is not the fakery of IT-analysts of the past, who had little technical expertise. They want someone who systematically tries to match technology with reality, instead of someone who lives in a bubble - be it "business" or "programming". They want *flexibility*.
This is what the IT shortage is all about. A lack of a flexibility in the workforce.
(end rant)
-Stu
Although the distinctions between the two types of systems are becoming harder and harder to see in some ways, at least on the hardware side. But the difference in general attitude and programmer "culture" between the academic Unix community and the old-school corporate mainframe community is still pretty large, at least in my experience.
:-) The environment I work in doesn't even HAVE a C compiler, and our application predates the C language anyway (I think the first implementation was on a Univac 1108 in 1966).
The Unix folks (at least around here) sometimes don't seem to take certain types of support issues very seriously, and support response times can be pitiful. And while C is a good language and all, other languages actually do exist. Really.
In our case (at least on the Unisys 2200 side of the fence where I work, since we have IBM big iron as well) it's OS2200, TIP, and UTS20-compatible terminals instead of the mythical mainframe GUI mentioned in the article, but I suspect the same general principles apply: Transaction-driven systems with text-based screens and very fast response times.
--
-Rich (OS/2, Linux, Mac, NT, Solaris, FreeBSD, BeOS, and OS2200 user in Bloomington MN)
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
asinus sum et eo superbio
asinus sum et eo superbio
in omnibus veritas
asinus sum et eo superbio
asinus sum et eo superbio
in omnibus veritas
"Why do you think that the US Missle Cruiser that
uses Windows NT to control it's engines had to
be towed to port 3 times (the captain typed 0rpm
and the engines crashed with a divide by zero). "
I don't understand why Linux users keep trying to grasp onto this story. Your interpretation is obviously incorrect.
Attributing an application error to the OS? Come on, you should know better.
Damn, trn crashed on me. I guess Linux must suck then!
Ok, the guy makes a few good points about software, but I think he confuses them within the historical context.... Let me try to simplify.
:)
If you look at the history, things come in waves.
Mainframes from IBM certainly came early on.
But then DEC entered the scene with PDP/VAX running VMS. They billed their systems as offering performance for less money. Of course at first, the Mainframe guys complained that they didn't scale and were unreliable.
Then later on Sun(and others) entered the scene selling Unix solutions. They billed their systems as offering performance for less money. Of course at first the Mainframe guys, and the VMS guys complained that they didn't scale and were unreliable. Actually as I recall the President at Digital stated that he never expected the Unix market to outgrow the VMS market.
Then a little later on, the PC entered the scene. It was intended for a different purpose. But guess what? Eventually it grew up and now they're claiming(well Microsoft is) performance at a reasonable cost. And the Mainframe, VMS and Unix guys are all saying it doesn't scale and it's unreliable.
Do you see a pattern here?
I fully expect in 5 years, PalmPilots will be offered as the next great solution, offering performance for a low cost!
Many of these companies depend on their mainframe and AS400 databases for survival!
The mainframe AS/400 world is nowhere near dead.
Yes, many of these companies do depend on their iron and midranges for survival, but as you have partially said, an AS/400 is not a mainframe. It is a mid range business solution (and I emphasize `business') and does wonders with `client-server,' X Window, Java, Integrated x86 hardware for NT, and 5250; it absolutely sucks for any intense interactive (non-batch) processing.
It is my belief that an AS/400 just can't be now considered in the old-school iron.
3lixyqueue
from my POV. He's getting flamed left and right for grammar and some factual errors, but still a good read.
To some of you that may be lucky anough to have the status to choose your job, you definately have a different perspective than some of us "youngsters." Where I work, it's all about who can pull what strings, and who has what certs. It's very painful and frustrating to know that no matter how good an idea you have is, you might as well toss it into the shitter before you speak it. Actually telling someone just damages your credibility.
This is the future I see... quicky solutions running on bad software running on cheap hardware. There are some of us that actually have to cope with the shit put in place. And work a few weekends to do it.
Some of us still love the machine more than the money. But in the place I work, that's treated as a Bad Thing. Are mainframes/UNIX still the norm in the rest of the world? How would I know... here, if it can't be done on NT, they wonder why you'd want or need to do it.
Hopefully, there's a much bigger world out there than I've seen, because what I've seen bothers me.
Some guy(?) named Lion Templin submits a story that turns out to be something written by some guy(?) named Lion Templin. Are we witnessing the birth of the Katz effect?
BTW, the main page says this article has 3 comments so far but I'm down to -15 and I still only see 2. Just how offensive is that 3rd comment?
(when I get the time, I'll read Templin's multi-part whatever it is, and if it's good I'll rush back to this thread to say so)
I see even classic Slashdot is now pretty much unusable on dial up anymore.
Actually, I'm seeing more and more spelling, grammar, and usage errors in many different print sources these days that appear to be caused by the software's "advanced features", as they are of an entirely different character than the "typo's" of the 50's, 60's, and 70's. Microsoft Office components seem to be especially laden with "features" that have their own ideas about how your work should be re-written and re-formatted.
That's not to say that the authors don't contribute their own share of goofs along with the dreck and psychobabble.
Maybe what Slashdot needs is fewer moderators and more editors.:-)
I see even classic Slashdot is now pretty much unusable on dial up anymore.
I was assuming this person with the somewhat uncommon name was a guy but leaving myself an out just in case that was an incredibly sexist and out-of-date assumption on my part.
I am not judging the paper on the basis of the author's name. I was pointng out that instead of the usual "Person A submitted this story written by Person B about..." it instead appeared that the story submitter and the author of the subject of the story appeared to be one and the same which isn't how it's usually done (except for a certain resident gasbag).
I see even classic Slashdot is now pretty much unusable on dial up anymore.
>Ummm yes, I like technology, but I like getting paid too.
Then why are you working salary???
Up till about six months ago I was working salary. I worked an average of 60 hours a week and got paid for 40. Then I was offered the chance to change over to an hourly rate at a lesser amount per hour. I jumped on it.
And even though I am making about the same amount of money now that I was making before the quality of my work has improved greatly. Now when I look at a job I ask myself how long will it take, not how will I finish it in 40 hours. I have found that my entire creative process has changed because of this.
Minne-snow-da: Winter is comming...
I think the fortune file says it best:
"I don't know what this is, but an 'F' would only dignify it."
I found this paper full of blatant grammar, historical and conceptual errors. IT personnel that don't (didn't) listen to end users? Yeah, they're just going to turn this multi-million dollar machine over to a bunch of techies and trust that they're going to "do the right thing" and get those paychecks/invoices/quarterly reports generated. A little common sense, please!
Just junk food for thought...
My real problem with this article is that he paints microcomputer engineers and programmers as idiots for using inferior solutions - while completely missing that the more complex solutions just wouldn't have worked on the limited hardware available.
Yes, X has a lot of neat features. But it always has been, and always will be, slower than direct-to-hardware systems, especially for graphics-intensive applications like VR and games (thus svgalib's niche). It wasn't until the early '90s that X became even remotely acceptable on most micro hardware.
Yes, Novell and other LANs are inferior to other networking solutions. That's why TCP/IP has won, now. But at the time, they were the fastest, most reliable, and cheapest way to get a network.
Over and over, he shows a preference for blue-sky solutions rather than what actually works, and works at a fraction of the cost.
He even goes off on local application execution, which is a FAR superior solution in most cases - a big expensive server and xterms are more expensive than a cheap file and database server and a bunch of PCs for the same horsepower.
He needs to get out and get a real job.
"A" paper in 10th grade? Maybe at the 'Tard school. Someone ought to ask Lion if he rides the short bus to school...
by Mike Buddha -- Someday the mountain might get him, but the law never will.
What is wrong with you people? Since when do we judge a paper based on the authors name? Yeah, some guy(?) named "unitron"
How about Reading the paper before you go shooting your mouth off?
I've read it now (leo's doing a suprisingly fine job keeping up with
Sure, there are gramattical and spelling errors and cliche's, but this isn't a peice for print that has been edited by anyone... Content is what is important.
Working for a company that makes millions of $$ selling emulation software, i'd have to say that the GUI of choice for "mainframers" is a WinXX solution. Many of these companies depend on their mainframe and AS400 databases for survival! Training thousands of users how to use a dumb terminal just to look up somebodies insurance info is just crazy these days! They use windows, have their Mainframe app's brought to the web or have custom front ends and macros/etc to make it easier to use.
The mainframe AS/400 world is nowhere near dead.
As someone who was in the same classes as Lion, we made fun of mainframes and cobol and all that when we were freshmen in the CS program... how many of us are now working or have worked for places that use mainframes every day? of my close friends that i graduated from UMD with?
ALL OF US
This post was not checked for correct grammar, punctuation, spelling, or content. Deal with it.
> I can't believe he wrote this: ...employees working long hours, often with little or no overtime.
...employees working long hours, often with little or no overtime pay .
>
> Many are even salaried.
I belive that Lion's intention with that statement was:
Some of these people are working incredibly long hours, or "on-call" hours for a salary, not for overtime. If I was going to be expected to work 60+ hrs per week, I'd want to be paid for extra time/work too..
I don't know where you came up with the idea that people shouldn't get paid...
This post was not checked for correct grammar, punctuation, spelling, or content. Deal with it.
Yep. Maybe Rob should provide mirrors for sites which are to be mentioned here ;-)
belbo
--
"Just believe everything I tell you, and it will all be very, very simple."
I'm not saying they shouldn't leave him black and blue. I was just tired of reading... "here are the facts, get it straight!" without trying to further the topic and supporting their newly stated facts.
BTW - "testicular fortitude"
very well put.
Cordova
My microbes must have translated that wrong! - Aeryn Sun
I've been frequenting /. for a few months now, and I have never seen such a harsh critique. Every comment so far except this one seems to think Lion's paper should be drawn and quartered.
/., I don't care. Give me better ideas, not "you didn't have every single little fact right in your article".
I know most people here are techies and linux addicts, hell I'm one of them; but why not actually try to figure out what the writer is trying to communicate instead of tearing specifics of the article apart.
HUMBLE REQUEST
If any of you have better opinions on where the industry is going to go, in reference to methods/philosophy/ethics in development mentioned in the paper. I want to read them. Reply to this, or even post your own writings to
Cordova
"Can't lurk all the time"
My microbes must have translated that wrong! - Aeryn Sun
Hey, Bone Crusher. I'm the guy who had to take over your project after you left. You talk about a "final product". That's a mythical beast; there will always be a 1.01, a 1.2, a 2.0 and so on - unless you're writing code for a space probe that will never again be touched by human hand (and even then, they're likely to tinker via radio).
Without the documentation that you so kindly glossed over, I had to make guesses about what your code was supposed to do. Don't kid yourself - there were bugs in your code. I could tell what your code was actually doing, but sometimes it was hard to tell what it was supposed to do. But I did the best I could. And because you didn't document what you had done in your 45,000 lines of code, I had to go over every single line, trying to find where you had implemented that function they wanted changed RIGHT NOW. Don't get me wrong - it was fun to have half the organization breathing down my neck, wanting to know why I couldn't just read the specs, find the function, and change it. And your reasons for choosing the original architecture were doubtless sound, but a month or so after you left, the Big Boss came back from a seminar and said we should have done it as a intranet-based centralized client-server structured object-oriented module. And I didn't have the time to analyze the entire application and tell him why he was wrong, and you hadn't left any record of WHY your architecture was better, so I had to capitulate.
This probably pleases you. You probably feel like Mel, the real programmer, whose code was fast, functional, and incomprehensible. You think if I was only as good as you are, I wouldn't have these problems - I'd be writing my own 1.0s instead of maintaining your code. You may be right, and I hope it gives you warm fuzzies. I hope you enjoy feeling like an artist. But I hope you realize that there is nothing left of your art. By the time we hit version 6.24.06a, not a single line of your code was left. It was like you had painted this beautiful vision of the Mandelbrot set on the wall of the Louvre, only they changed their mind and asked me for a surrealist landscape, so I sandblasted it a bit at a time and transformed your vision into mine.
I'll be leaving the project pretty soon now - going to work for Microsoft. Bill says it's important - something about how they're going to be the next Red Hat. Anyway, I know that whoever takes my place won't be as good as me, and won't have my experience on this project, but at least they will be able to understand my thought-processes while developing the program. I bit the bullet, sucked it up, and followed the documentation procedures.
I don't really disagree with your points on freedom or one-size-fits-all templates. But don't skimp on documentation. Those who have to maintain your code thank you.
Well, I guess we /.'ed the server...only made it
through about half then it went south. Oh well.
Grated there are numerous errors both historically
and others, however there is a point I think the author is trying to make. Having not exactly finished the article, I am going out on a limb here. But I think the point is one size does not fit all.
All the IT organizations I have interacted with in recent years recite this singular thought like a mantra.
I dont know about others, but I get results because I still treat systems architecture and software development as a art. I cut corners in the "software engineering", "process documentation", and other more bureaucratic areas where it makes sense without compromising the final product. This drives IT types crazy.
I have noticed this more in recent years than in the 80's. Back in the days of PDP's, Vaxen, BSD, etc, each project had its own set of challenges.
We were allowed the freedom to overcome those by whatever methods were available.
The 90's were just the opposite...try to do every project using the same template.
So is the pendulum swinging back? Have we come full circle ? I dont know. But I do know that OSS
gives me the tools I need to crank out solutions at an ever increasing rate to meet demand. I also know that IT types are watching very closly trying to figure out "How'ed they do that!!!".
**** Sworn to Fun, Loyal to None. ****
The paper has dozens of grammatical errors. Cliches are everywhere. I didn't see any evidence of original thought.
Background research is nearly nonexistent. The author doesn't even refer to basic works in the field by Yourdon and others. In fact, only three actual books are mentioned in the bibliography, and that counts the New Hackers Dictionary! (Although "Microserfs" is quoted, it is not in the bibliography.)
That was truly "written as university research"?
It would have barely rated a "B" as a Grade 7 report.
Faugh.
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
I disagree. I think this would be an "A" paper at least through the 10th grade, and possibly all the way through some of the weaker secondary schools.
Unfortunately this says more about schools than it does about the quality of the paper...
Why is that the majority of these pseudo-academic papers that get posted to slashdot contain SO many spelling and grammar mistakes? You would think if someone was going to write about the IT industry they would at least learn how to use the spelling and grammar checkers in their word processor.
Oh how I hate these LaTeX2HTML generated pages. You read three paragraphs, then have to wait for the next page to load, foonotes are on separate pages again. This may be useful for 100 pages documents, but this little thing could have easily been put into a single HTML file. So many authors seem to think LaTeX2HTML is so scientific and makes their documents look more important.
Woah,
I never expected to see someone I actually met in the headlines of slashdot.
Way to go Lion.
Quality paper my man, better than the 50-pager I shot out for my psychology class last semseter *wink*.