Copy & Paste programming

N

NightShift

Expert Member
Joined
Oct 8, 2009
Messages
1,952
Reaction score
1,404
I'm working on something at the moment with a small team of developers - a very important system consisting of alot of different elements, a tight timeline and many screens. For reference, I'm not a developer, but I am keen on getting more insight into the issues I've been encountering in this development effort, hence posting here.

We uncovered a number of bugs which are "serious" because if we dont fix them right now, I'm told we will just replicate them in further screens, and thus the effort to fix the problem later on will be much much larger than it would be to fix it now. And I understand that, and from that perspective it sounds logical.

What I dont understand is why, essentially, taking code from one page and reusing it on 5 pages, would mean i need to fix 5 pages because there was a problem in that original code.

The question is: Is this practice standard, or is there a more elegant and sophisticated way of handing this? I'm sure there must be. I'm slightly concerned that I could uncover something later on (say a few months down the line) that MAY be missed now, that requires a substantial effort to address.

Thoughts??
 
And you are quite correct that it would lead to an unmaintainable system and months later somebody would suggest that you start all over again!
 
ernstn said:
If you write the same piece of programming code more than once, you have no idea about programming!
Click to expand...

QFT.

Good programmers/developers are lazy. Encapsulate re-usable code, don't repeat same code every page.
 
Markd said:
I'm working on something at the moment with a small team of developers - a very important system consisting of alot of different elements, a tight timeline and many screens. For reference, I'm not a developer, but I am keen on getting more insight into the issues I've been encountering in this development effort, hence posting here.

We uncovered a number of bugs which are "serious" because if we dont fix them right now, I'm told we will just replicate them in further screens, and thus the effort to fix the problem later on will be much much larger than it would be to fix it now. And I understand that, and from that perspective it sounds logical.

What I dont understand is why, essentially, taking code from one page and reusing it on 5 pages, would mean i need to fix 5 pages because there was a problem in that original code.

The question is: Is this practice standard, or is there a more elegant and sophisticated way of handing this? I'm sure there must be. I'm slightly concerned that I could uncover something later on (say a few months down the line) that MAY be missed now, that requires a substantial effort to address.

Thoughts??
Click to expand...

The situation you describe points to several problems: first and foremost a severe lack of experienced Software Engineers in the usual roles; an inability to identify, document and manage requirements; and the negative effect the former have on analysis, design, implementation and testing.

Chances are that similar problems will rear their ugly heads in the near future. If you get people on-board who are sufficiently experienced and give those people the power to make the necessary decisions, you should end up with an implementation that is vastly different and far more successful than what you currently have.
 
thanks for the feedback. it's clear that what has been produced so far is severely lacking. It's quite hard to believe actually...
 
ernstn said:
If you write the same piece of programming code more than once, you have no idea about programming!
Click to expand...

This...99% of the time.

There are instances where copy pasting is better than "making it common and bloating your base" especially if it is used only two or three times. But this is really the exception to the rule.
 
In software engineering, Don't Repeat Yourself (DRY) is a principle of software development aimed at reducing repetition of information of all kinds, especially useful in multi-tier architectures. The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer. They apply it quite broadly to include "database schemas, test plans, the build system, even documentation."[1] When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically-unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync. Besides using methods and subroutines in their code, Thomas and Hunt rely on code generators, automatic build systems, and scripting languages to observe the DRY principle across layers.

http://en.wikipedia.org/wiki/Don't_repeat_yourself

DRY is a pretty much a fundamental in program development, about the level of boiling water.

If your team aren't aware of this fact then ... let's say it's not good. For you, that is.

Incidentally, it sounds as though the team is selling you on the approach 'get the first screen right, then we'll just duplicate the code for the rest'. If so, be aware that whilst this approach sounds good in theory, it rarely ever works well in practice :)

And good luck with the project ...
 
dequadin said:
This thread is overly critical given the vague nature of the OP.

#justsaying
Click to expand...

Nope: if the development approach [as described in the original posting] is to cut and paste then - if anything - this thread is not sufficiently critical ...
 
I have worked with many Devs from junior to intermediate level that think copy/paste is good reuse.
It only takes a few hours of teaching them the right way and things start working out.

Do you have at least one senior dev on the team that can lead and help the lessor experienced?
 
Mike Smit said:
I have worked with many Devs from junior to intermediate level that think copy/paste is good reuse.
It only takes a few hours of teaching them the right way and things start working out.

Do you have at least one senior dev on the team that can lead and help the lessor experienced?
Click to expand...

Ja going forward more than 1 senior person will be involved. So, I dont doubt that it will improve. I was worried that this was just sloppy work where one should know better, but it sounds, though, that you would have to work quite hard to mess up like this. Seems some educating will be required. Thanks all.
 
Imagine this:

You are a Maths teacher, in charge of teaching Maths to Grades 7,8 and 9 students. There are 20 students in each grade, giving you a total of 60 students. At the end of each term, you have to draw up a report card for each student - a total of 60 report cards. The format is pretty standard, but there are sections in each report that need to be different for each grade, as well as for each student. Grade 7's all get blue reports, Grade 8's all get red reports, and Grade 9's all get green reports.

Copy-paste programming is like drawing up each individual report manually, writing it with pen, by yourself. 60 report cards all done from scratch, no photocopying. Tedious, error prone, uneconomical, inconsistent.

The right way to do it is get design your report with blank spaces in the right places. Blank spaces for name, grade, date, result and comments, The rest of the report remains the same. Once you design your template report and you're happy with it (i.e. you've tested it, and made sure it caters to all your needs), you photocopy it in 3 batches. First on blue paper, then red, then green.

Now you fill in the report card for each student - all you have to do is fill in the details specific to that particular student. Name, grade, result (percentage) and comments. You've saved yourself a whole lot of work by working smart. Perhaps you are even smarter and realise that "Grade" only changes 3 times, and that the date is the same for all the students. So you print 3 pages of your initial template, but fill in the grade, once for each of 7, 8 and 9, and fill in the date from the start. So instead of having to write out 7, 8 and 9, as well as the date, for each student, it is already photocopied for you.

For the following year, the principal asks to change the format, he'd like to add a principal's comment section and the number of demerits the student has received in the term. No problem, just add the 2 fields on ONE page, the original page, and follow the same procedure. This means making 2 changes to the original, and adding the additional comments and demerits for each student.

Using the manual method, adding these 2 fields has to be replicated 60 times each, and you haven't even put in the values yet (actual comments from the prinicipal, number of demerits for the student)

Programming is very similar to the above. You can work in a tedious, error-prone way that requires less thinking and no/little design and planning, and very little brain-work. Or, you can work smart/intelligently, by analysing, planning, and trying to visualise your end goal from the start, and what the most efficient way of reaching that is, in the face of the end-goal changing at a later date.

In the example above, you work intelligently by re-using what you've already done. This is the DRY principle. The photocopier and template design is your method/function that helps you to be DRY. You call on the photocopier to do all the repetitive boring work, and you relax because you've designed an intelligent, reusable, and economical system. Any changes are done in one place - on your template, and duplicated by your photocopy machine.
 
Last edited:
Markd said:
I was worried that this was just sloppy work where one should know better, but it sounds, though, that you would have to work quite hard to mess up like this
Click to expand...

Well put: you have my vote for the best understatement of the week, if not the month ... :)
 
Hamster said:
This...99% of the time.

There are instances where copy pasting is better than "making it common and bloating your base" especially if it is used only two or three times. But this is really the exception to the rule.
Click to expand...

I believe if it is used more than once then it needs to be in a library. The last thing you ever want to do is have to fix the same code in multiple places, even if it is just two.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X