A common coding practice can lead to product efficiency but also software maintenance nightmares and technical debt.
By John Blyler, Editorial Director
At a recent EDA event, Semi-IP Systems talked with Cristian Amitroaie, the CEO of AMIQ, about the good and bad side of developing software from code that is copied from another program. What follows is a paraphrased version of that video interview (AMIQ_DAC2015_Pt1). – JB
Cristian Amitroaie (left), the CEO of AMIQ, is interviewed by John Blyler (right), editorial director of JB Systems.
Blyler: I noticed that you recently released a copy-paste detection technology. Why is that important?
Amitroaie: We introduced these capabilities in Verissimo Testbench Linter. We’ve had it in mind for some time, both because it is very useful – especially when you accumulate large amounts of code – but also because it is fun to see how much copy-paste code exists in your program. There are all sorts of tools that detect copy-paste in the software development world, so why not include that in the chip design and verification space. Also, the topic of copy-paste code development is very interesting.
Blyler: Is the capability to copy and paste a good or a bad thing for developers?
Amitroaie: To answer that question, you first have to first see how copying and pasting are being used. While it is not a fundamental pattern used by software engineers, it is a common technique. When engineers want to build something new or solve an existing problem, they usually start from something that is working or basically doing what they need. They take what exists to use directly or to enhance it for another application. Copying and pasting is a means to start something or enhance it. In software, it is very easy to do.
It may happen that you don’t know if what you need is already available. For example, you make work in a big company and similar activities are being done in parallel that you don’t know about. So, you develop the same thing again. Now you have code duplication in the overall code base.
Another reason to use a copy-paste approach is that junior engineers lack the senior-level skills or experience to start from scratch. They copy and then build upon existing solutions.
Whatever the reason, in time most companies will have duplicate code. The fact that you use copy-paste to solve problems isn’t bad, because you take something that works. You don’t have to start from scratch, so you save time. You tweak the existing code and use it to solve a new problem. After all, engineering is about making things work. It’s not about finding the best, most ideal solution.
Blyler: We are talking about software programmers who prefer elegant solutions, aren’t we?
Amitroaie: Yes, but today you have lots of time pressures. Plus you often don’t have enough resources to get the best solution. But you need to get a solution within the market window. So elegance tends not to be the highest priority. The top thing is to make it work. In this sense, copying and pasting is a practice that makes sense. It is also unavoidable.
The bad thing is that, as time goes by, you accumulate and duplicate more code. When a mistake is detected, you must now go to several places to fix it in the original code – if there is such a thing. It’s an interesting question: In this copy-paste world, is there such a thing as the original code? But that’s another matter.
Fixing or enhancing the code is problematic. For example, if you want to enhance an algorithm or functionality, you must remember where all the duplications are located. Many times, when you duplicate code, you don’t understand the intention of the original program. You think that you understand so you copy and paste it, adding a few tweaks. But maybe you really didn’t understand the intentions or implications of the original programmer and unknowingly insert a bug.
In this sense, copying and pasting is bad. As the code base grows, you can have what is called “technical debt” resulting from the copy-paste activity. Technical debt results from code that hasn’t’ been cleaned. We never have time to clean-up the code. We say that we’ll do it later but never do. If you go to your manager with a request for code clean-up, he/she will say “no.” Who approves time for code cleanup? Very few. They all talk about it but I’ve never seen it happen. Even though we are in the EDA market, we are still software developers and have the same challenges when trying to improve our code. I know how hard it is for a team leader to approach code clean-up. This is what is known as technical debt, which is analogous to interest that accumulates on a financial loan. You add more and more and the “clean-up debt accumulates that will add to higher maintenance cost over time. You can end up having huge piles of code that no one knows where it starts or ends and how much is duplicated. That makes it tough to redesign or make the code more compact. It will blow up in your face at the worse possible moment.
Blyler: The debt comes due when you are least able to afford it.
Amitroaie: Yes, it’s unavoidable. It is similar to software entropy in that it keeps accumulating. At some point, it will become more cost effective to rewrite the code from scratch than to maintain it.
The good side of copying and pasting is that it is a fundamental way of getting code developed quickly. It helps programmers advance in an efficient way, at least from a result oriented prospective. The bad side is that you accumulate technical debt that can lead to maintenance nightmares.
Blyler: Thank you.
For more information: AMIQ EDA Introduces Duplicate Code Detection in Its Verissimo SystemVerilog Testbench Linter
Originally posted on Chipestimate.com “IP Insider”