We have 6 people in my group. My boss and the others are all SQL developers with little understanding of programming, design patterns, good object oriented design, etc. But, they have all taken a Java course in college.

When new projects come up, I am usually asked to give a time estimate for how long my part will take. If this project is needed with quick turn around and they don't like the estimate I have given them, they will look at previous modules/portlets I have built and say things like, "It basically looks the same as Project X, so you should be able to just copy/paste that code and modify the SQL a little. You should be able to do this in 1/2 the time you gave us".

Recently, it got so bad, my boss called me into a daily status update meeting with the group there, and each of the SQL developers asked me why I couldn't just copy/paste the existing code. They even took the wiki documentation I created from the previous projects and began explaining my documentation to me.

Has anyone else ran into this? How do you handle this?

  • 5
    invite them to do it themselves and then crack down on the result – ratchet freak Jan 23 '14 at 15:44
  • 10
    Leave. The odds are stacked against you. – James McLeod Jan 23 '14 at 15:45
  • 1
    Sometimes coding IS a matter of copy/paste/modify/tune (e.g. SQL that supports basic CRUD without business logic). Sometimes though it is a terrible idea. Can you provide more details about your requirements? – John Wu Jan 23 '14 at 15:45
  • 4
    One thing to consider: if the modules are that similar, why have you not abstracted the common bits out so it's less clearly a copy/paste issue? – Telastyn Jan 23 '14 at 16:17
  • 2
    "How to explain" questions always seem to be really "How to force them to agree" questions. You're in a place where slapping something together and getting it out the door is the priority. They arent going to change their minds until that attitude comes back to haunt them in a very bad way, and they have to deal with the consequences. – GrandmasterB Jan 23 '14 at 16:19

Either you are too conservative or they are too aggressive in thier estimates. If times are different, then you will need to validate your estimates and assumptions in detail for others to view and come to consensus on. One can't just say, "it should take 3 weeks because it looks like project X". You will need to go deeper.

Estimates usually come in 2 forms:

  • High Level
  • Detailed

Usually esimates start in high level form. A high level estimate is maybe T-Shirt size like XS, S, M, L, XL, and XXL. There are usually used to define how big the project will be. If everyone agress on the same size, then no need to go any further.

However, if you are saying medium and they are saying extra small, then you need to go into a more detailed estimate that lists out all the assumptions, desired functionality, and corresponding effort (tasks) to justify the medium effort. This should flush out any differences so that all parties agree on the estimated effort of the project. How deep should you go? For estimation purpose, maybe a high level view of the proposed system that will be built, components, and broad tasks needed to build those components.

If you are doing the same things over and over again, then I would have to agree that things should take less time the second, third, fourth time around. Certainly accessing a database should be a common component that can be re-used. You could develop starting templates for CRUD type operations so you are not starting from scratch every time.

Also, if you justify your estimate and everyone else still says something different, then they are not being logical or reasonable.


Problem with copying is that you copy the bugs also and you add new features only to the last 'current' copy.

When copying bugs over you may end up with a maintenance culture where you have to fix bugs many many times for each separate copy. As time passes and the code loses simularity bug fixing isn't 'copying' anymore. One fix won't quite fit on the other project etc.

When you add new features that you want to retrofit to a project that was source of a copy in the past the business may expect it would be easy, in practice not so much, the code bases will stray away from each other with time.

Refactoring is a big no-no, knowing that if you improve code on project A you'd still be stuck with the painful experience on all the other projects. Doing a complex refactoring 10 times? I don't think so.

If project A is only a few line changes from project B maybe you can just use project A's code as is and share between A and B. Add configuration options to differentiate between A and B. Create a framework, configurable application or service. Etc.

Having said that. I do copy code a lot, but only for scaffolding purposes. I aggressively remove any code not needed and I look for parts that could potentially be moved to a library and shared that way. This is a valid way of working if project A and project B are expected to have different axis of change (they are similar now but won't be further into the future).

Constantly looking for commonality and coming up with increasingly abstract and therefor vague components has it's limits also. Draw a line somewhere and just fork for dissimilar domains.

Not the answer you're looking for? Browse other questions tagged or ask your own question.