Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Is plagiarism a risk to the future of quality programing? 1

Status
Not open for further replies.

lionelhill

Technical User
Dec 14, 2002
1,520
GB
This is just a philosophical moan, and perhaps a warning for something which I feel threatens the future of good quality IT altogether.

It's triggered by a recent thread in the assembly forum. Someone posted quite a reasonable question, another person posted quite an elegant solution, I pointed out a minor error, other person corrected it, and first person said thanks, we'd just completed his homework very nicely.

We actually teach people to reuse code. It's one of the first lessons people learn: if you can possibly get your code from anywhere else, a library, a previous application, then don't write anything yourself.

Is it any surprise that there are heaps of budding "programers" out there who reckon their best strategy to do homework is post it on enough sites that someone answers it by mistake?

If no one is doing their homework any more, where are all the good programers going to come from? And when all these wretched cheats get good certificates and jobs, what sort of quality of product are we going to get from them? Already software engineering has a poor reputation for success-rate and reliability compared to most other branches of engineering (how many bridges get left half-finished, change specification half-way-through, or fall over because of design faults? Some, but not many). How much worse is IT likely to get?

OK, moan over... Life probably isn't sooo bad.

 
The tools analogy works only partially. If we use an IDE such as Visual Interdev to build a website, that's the tool--but what you sell is the product of what you made with that tool. However, code snippets taken from someone elses library are not tools, they are finished product that we slap into our product.

I guess an analogy might be that fancy crown molding you buy at Home Depot. In the past, a highly skilled trim carpenter had to carefully piece together all the little intricacies and brik-a-brak of such a piece of wood, as well as install it on the ceiling. Now you buy that stuff pre-formed in 20 foot lengths made of fiber-pulp molded 'wood product' and slap it up, throw paint on it and you're done.

Not as good a job but it's quicker. Maybe for some work (tract housing) that's ok. But for a custom, expensive home, I'd want the real thing. However, most customers don't want to pay for the real thing. Same with coding.
--Jim



 
Truthfully I can't really think of a good analogy that fits this. I know the "tools" one is a bad one in this case. But jsteph's comments are perhaps closest....if we have all these widgets, each of these widgets have a function, and you hope they all work right if you put them together.

The problem is that a lot of people have no conception of how these different widgets work, they just slap them together. Now what if the software isn't working right? How do you know if it's not your third-party widget or your own code? How do you debug what the problem is? You're putting a lot of faith out there in things not in your control.

Me? I'd rather know what I'm working with and understand it so I can fix things if a problem comes up.

And even worse, you're getting people that have no concept of what being a programmer is (what they call "programming" really is "code librarian"). Like I said, you tell these people on forums by them asking for "components" to do jobs, and not asking how to do things.

And the silliest part of this...most coding is plagarized through component use...there's no such thing as one's pure intellectual property (IP), because no one solely designed anything - most programs are usually third party components, and in the case of a visual development environment (like Visual Basic), there's more IP from Microsoft in the average VB app than anyone else's...

Hence, anyone who does not seriously program is not a programmer, but a code librarian. Slapping a couple of controls on a form and setting the methods on them does not a programmer make.

Perhaps we need to make a clear distinguishment between the two in most people's minds.
 
Actually, I think Sheco's Sir Isaac Newton quote says it best.

It mostly comes down to the person, not the technology. Some people will use examples to learn and lift themselves higher by building strong foundations on knowledge and experience gained from looking inside the 'block' created by others.

Others will use whatever means necessary to get to the top of their desired ladder (e.g. a new product, or career, or certification etc) and just add in whatever block seems to fit - but using blocks of unknown content to build your foundations is hugely dangerous, and is likely to let that person down one day...

Without re-use of existing knowledge, mankind would not be where we are today - no single generation has the time to learn and build everything we have and take for granted. Even those who copy and paste all the way to the top, may stumble on something useful for the rest of us - unfortunately it is less likely they would recognise it when it happened.


So, we are all 'code-librarians' in one way or another - unless everyone here except me programs using 1's and 0's.. or even chips, transistors and solder, or.... you get the idea. The commonly accepted level of abstracted re-use is usually bourne from the stability and level of the current technology, the average level of programming when computers were first emerging was much lower than today - does that mean all you java/c# programmers are 'librarians' ? in one way yes, in the alternative way, no.

One more time because I like it so much:
Isaac Newton said:
If I have seen a little further it is by standing on the shoulders of Giants - Isaac Newton
We should all try looking down once in a while and appreciating all the shoulders we're standing on to see so far.

A smile is worth a thousand kind words. So smile, it's easy! :)
 
If you want to get down to a fundamental language, everything is made of components.

If I build a clock, I'm not going to go out and mine the minerals to melt down and make the gears, mine the jewels for the movement, and redesign the entire timepiece from scratch.

By the same token, if I'm programming, I'm not going to start with a new CPU design.

I am a programmer. I consider myself a programmer, as do others. But I didn't write the interpreter or compiler that I'm using to program. It's all components.

Here's my take on it. If you piece together a web page using someone else's javascript code to perform functions, you're not a programmer. You're a "librarian" (to use the term coined before). If you're downloading virus source code, and modifying it, you're not a programmer. You're a script-kiddie.

I make the computer do things that it wasn't able to do before; whether that's real-time data acquisition, a new way of doing treatment planning, an instant messaging system on a mainframe with nothing but text terminals, or testing motors coming off of an assembly line using all computer controls (all projects that I have worked on), *that* is programming, IMHO.

Not trying to toot my own horn, but just venting a little, since a kid (with an AA degree in computers) who I "carried" at my last job, just got a job at a major hospital that I had applied for. He got the job because of his degree, not his skill. I didn't even get an interview, and I've been working in the health care field for over half my career. <grumble>



Just my 2¢

"In order to start solving a problem, one must first identify its owner." --Me
--Greg
 
Copying code is one thing, but in order to be in a position to copy code you need to know what you want your code to do. One of the toughest things is that you know in plain language what the result needs to be, but what are the steps to get there. Then you start putting the pieces together.

I graduated college about 2 years ago and the majority of my classmates had no clue about how to write code. Many were drug along by others. Yes, that can get you a degree, but when you get in the real world and your employer finds out that you know nothing, you're probably not going to make it. On the other hand, out in the real world is where you really learn anyway.
 
... the tools analogy may not fit exactly, but it does have some useful points:
(1) A craftsman doesn't have to make his own tools, but he/she should understand how they work. Of course you use a compiler, but you should know (approximately) what it's doing behind the scenes, so you can use it as appropriately as possible. I find this difficult; very few textbooks tackle the underlying mechanisms.
(2) A tool-using human knows when a tool is no good. If a cave-man was digging a hole with a stick, he'd break off any bit of stick that got in the way. The problem I have with some "code-librarian" approaches is that any stick that contains the right pointy bits gets pushed into service, even if it's a totally resource-heavy and inefficient stick from every other point of view. Unfortunately breaking off the unnecessary bits of stick isn't an option if you're using someone else's library functions.
Thanks for interesting discussion, all!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top