Martijn Endenburg

Agile Architect

[m5n82]

The ‘Big-Bang vs. Iterative’ dilemma

It’s been a few years since we’ve had to make a decision on the Big Bang vs. Iterative dilemma for our project. When Erik van der Wenden and I presented our case “Incrementally replacing a legacy system using the Strangler pattern” at the Tweakers Developers Summit in February 2018, it was still very current and present in the day-to-day life of many attendants. It appears that the industry still struggles with this dilemma and that neither of these strategies clearly wins the match.

Given that renovating the legacy system is no longer an option, the dilemma arises to choose what strategy to take in replacing the old system with a new system. To clarify the difference between the two:

If you were to choose the Big Bang strategy, it means you will be building a completely new system next to the old one until you’re done and replace the old system at once. It is very important to note here that in this case you will replace the old system in one go.

The Iterative strategy, however, is about building a new system that runs simultaneously with the old system and replace it bit by bit each time the next bit is ready. In this case you replace the old system feature-by-feature; preferably small features or subfeatures.

A rationalist's comparison

Many people have a strong intuitive feeling towards one of these strategies. This bias often moved people from solid decision making to gut feeling. I’ve seen both approaches being taken at various replacement projects and the decision for taking either approach should've been made by reasoning. If you do, you see both options have their ups and downs.

Big Bang pros

Isolated/focused development

Lower development complexity

Big Bang cons

Higher risk at release/switch

Deferred business value

Chasing a moving target

Iterative pros

Immediate business value

Short feedback cycles

Iterative cons

Higher development complexity

Inside knowledge of legacy system required

The Big Bang pros (B+), and cons (B-), Iterative pros (I+), and cons (I-). Let’s go through each of them.

B+ 1. Isolated/focused development

Sure thing: if you build a new system from scratch until it’s done, you don’t have to account for the legacy system in production. Ongoing business doesn’t disturb you and no production issues. It's just your team building an amazing new system. Sure, one day it will replace the production system, but until then you can be focusing on rapid application development and ignore real-world problems.

B+ 2. Lower development complexity

Since you are isolated from the rest of the organisation and you don’t need to account for the legacy system in production it is lowering the complexity as opposed to the iterative approach. For instance, you don't need any synchronisation of data between both systems. This is a major booster for development speed for this strategy.

B- 1. Higher risk at release/switch

Since everything that was built for the new system was in a sandbox environment, it is hard to predict how the system will react once it is in production. Think of load capacity, performance, functional fit, bugs, but also how users will react to this sudden change. Not to mention, even before the go-live, how will your migrated data be in the new system; does it fit at all? What to do with incompatibilities? Many things you will need to adopt to, now that the system will actually be used.

B- 2. Deferred business value

New features and improvements surely have made its way into the new system. But they will only make profit once they’re live to your end-users. And that moment is there when the system is completely ready and deployed to production. Sure you may have done the user acceptance testing period, but human psychology works in a way that most issues will be found when it is live.

B- 3. Chasing a moving target

During your rebuild project, business moves as well. It needs improvements and changes, no matter how small. If they’re important enough, these things will be put in the legacy system in production. But they also need to propagate into the new system; doing the same thing twice.

I+ 1. Immediate business value

Replacing your legacy system bit by bit means by every iteration. Iterations should be short (i.e., at most a few weeks). With every iteration you deliver new business value because you replaced a little bit of the legacy system already.

I+ 2. Short feedback cycles

Because you deliver in short iterations, you see gradually what impact this little go-live has on your new system, infrastructure and users. You'll gather feedback on each iteration for you to take in the next iterations. This drastically reduces the risk of releasing new things as opposed to a Big Bang strategy.

I- 1. Higher development complexity

One of the downsides of iteratively replacing a system is that you need to account for the legacy system because both systems run simultaneously. This increases development complexity. For instance, you will need to synchronise both systems in terms of data consistency.

I- 2. Inside-knowledge of legacy system is required

In order to properly take over the legacy system iteratively, and in short cycles, you will need to hook into the legacy system to find the spots where you need data synchronisation, or external system calls, etc. Legacy systems tend to be not so well structured (this is often a reason for replacement in the first place). To achieve this, it requires inside-knowledge of the legacy system.

An empirical evaluation

I’ve seen projects that chose the Big Bang strategy as the way to go. They’ve used the previously mentioned pros for the Big Bang approach as arguments for doing so. Unfortunately, the business stakeholders interpreted them (faulty) as shorter time to market. Their reasoning was that because development is isolated and less complex, the development would be quicker and they would sooner replace the complete legacy system than if they would go for Iterative replacement. This project was estimated for six months but went on for several years, over-time and over-budget...

Some other projects went for the Iterative strategy. Again, using the previously mentioned Iterative pros as arguments for doing so, but also consciously agreeing with the cons it brings. The projects that made an estimation all went over-time and over-budget...

Should we conclude that both strategies are unsuccessful?

Wrong perceptions lead to wrong estimations

One of the hardest things in software development projects is estimating time and costs. Not just because it is very hard to determine at the start of a project what work needs to be done, and how much time it will take. It’s all very dependent on the team and the individuals that make up the team, but also the management of stakeholders and their requirements, demands and expectations, and add to that: variations in team, management, etc. during development.

Additionally, the software itself has some weird characteristics: it is easy to change and it evolves. As more work is being done on the same codebase, the structure and quality of the code changes. Sometimes for the good, sometimes for the bad. This has its effect on the complexity of new work and thus on the time it takes to do the work. Work that was already estimated when you planned the project upfront. This moves you further away from your estimated time and budget targets; in a negative way, of course.

The misinterpretation of looking at software development as separate projects lays in the fact that software is never finished. Software development is a continuous process of putting effort in developing new and maintaining existing features. This is why agile methodologies, such as Scrum and Kanban, work so well on software development. It is a flow of continuous change that need to be managed. No upfront estimate for any software project of significant size will ever be correct and accurate at the same time. There's just too many factors of influence. You better manage these factors than trying to predict the future.

Choosing a strategy

So, what strategy to choose in replacing your legacy system?

The choice is very much depending on the agile maturity of your organisation and depending on the type of system you replace. In general, if your organisation is used to agile methodologies, and it is feasible to use an iterative strategy for your case, the iterative strategy is usually the best idea: you receive value early in the process and it increases as the replacement progresses. So even if the replacement takes several years, you’ve delivered more value and reduced more business risks than with the big bang strategy.

Further read

Big Bang adoption

Strangler Application, by Martin Fowler

[m5n82]

QA in the land of Continuous Deployment

I am a big fan of Continuous Deployment; the practice where every push of commits is automatically deployed to production. From time to time, I get the question how to get the testing procedure right in this way of working.

Leveling up in integrating code changes

Continuous Deployment is the highest level of maturity when it comes to integrating code changes and deployment of software products. Let's see what levels we can distinguish.

At the most basic level, a team is used to manually compose releases by selecting features that have approval by the QA engineers. Development uses feature branches to code new features, and once they're done, QA is involved in testing it. Only when QA has verified the feature works correctly, it will be integrated and released on a set date.

The next step is Continuous Integration, where a part of the release process is automated by using a centralised build server. Whenever a developer pushes a series of commits into source control, the build server is triggered to run a series of automated tests to verify the code is correct. Having an extensive set of unit tests is becoming very important from this stage on. Merging of pull requests could be automated on the build server, or the team is working trunk-based and code is already merged. Either way, the QA engineer verifies the new state of the program before it is released on Production.

At the third level we have Continuous Delivery: the build server is extended by automatically deploying the next release to an Acceptance environment. In this way of working, the team has fully automated deployments. Also, it is pretty clear that the new code will in fact be in the next release, because generally, from here on, there is only one branch holding the next release. However, QA will still have to verify this new release on the Acceptance environment. Only if QA approves the release, it can be deployed to Production. This last step is semi-automated by the build server, in the sense that it is a push-button automatic deployment.

The final level is Continuous Deployment. Although it is in fact nothing more than removing the push-button part from Continuous Delivery pipeline, it changes a lot in the way of working of the team. A well-maintained delivery pipeline takes at most 10-15 minutes to automatically build, test, and deploy. If the QA engineer tests the new code on Acceptance, you're too late because it will already be on Production. A shift of the QA role needs to happen.

In Continuous Deployment, the QA engineer no longer does his/her thing at the end of the production chain. Instead, it will be more at the beginning of the chain. This may sound weird; how can you test things that haven't been built yet? Well, it is in the quality of a user story that becomes a lot more important.

Three amigos

For the creation of User Stories, a Product Owner is no longer solely responsible for delivering tickets that conform to the Definition of Ready (i.e., the promise of the Product Owner to the development team). User Stories are refined in sessions where a developer, a QA engineer, and the Product Owner (the Three Amigos) sit together to write the acceptance criteria for this user story.

Clear acceptance criteria should be stated as use case scenarios whenever possible. Following the Given...When...Then... structure, one can clearly describe the behavior of the system in terms of functionality. You set the stage (Given), perform an action (When), and expect a testable result (Then).

The Acceptance test scenarios should then be automated by the development team and run on each build to verify the functionality of the system is still working before deployment. This is automating a part of the testing work that the QA engineer used to do. Now, he/she is rather thinking of the scenarios before development takes place instead of after a feature has been delivered.

Manual testing

Yes. The QA engineer will still perform some manual testing on the system. This time, it is an added level of quality control instead of a necessity. Because we have now automated most of the functionality testing by implementing acceptance test scenarios that are run on every build, there is no real need to verify the workings again, manually.

The additional level of quality can be achieved when QA does exploratory testing on the program. This is done manually. The purpose of exploratory testing is to verify the system is still coherent. For instance, to answer questions like: Does the new feature still fit in the overall user perception of the system? How is the usability of the system? How does it feel to work with the system? Does the copy in forms and dialogs make sense?

Those questions are hard to answer by automated tests and in general can only be verified by seeing the system at work.

Acceptance Tests verify we've built the right thing, Unit Tests verify we've built the thing right. Exploratory tests verify the system is coherent.

Further read

Lean-Agile Acceptance Test Driven Development, Ken Pugh

Continuous Deployment

[m5n82]

How to measure technical debt

Technical Debt is a metaphor for a phenomenon first pointed out by Ward Cunningham. He defines it as (paraphrased) a conscious decision to implement a solution that is quicker and might make changes harder in the future as opposed to the 'right' solution that takes more time to implement.

Technical debt is inherently related to time-to-market vs 'good design' trade-offs (whatever 'good design' may be, more on that later). Along that line, technical debt may be a mess, still not all mess is technical debt (by Uncle Bob).

Not all technical debt is bad, right? For instance, if you need to choose the quick solution to be able to take a business opportunity for product version 1.0, which will earn the money to pay for product version 2.0, it is justified, right? Or doesn't it? If you generalize this rule, is it justified to take the shortcut for product version n to earn money to pay for version n+1? You see where this is going...

Cost of change

Inevitably, one day, this 'bad' solution will have to be changed as by Lehman's laws of software evolution. By that time, you will need to pay the extra cost (or interest, as by metaphor) that you did not pay for when you made the 'bad' decision in the past.

These laws of software evolution do not differentiate between 'good' or 'bad' decisions. Software needs to change to stay current. Period. It seems it does not matter whether you chose the 'right' or 'wrong' solution. Does it cost more to change a 'bad' design than it costs to change a 'good' design? Maybe.

A problem with quantifying your technical debt is that the absolute cost of the 'good' design is not known, because,... well... you did not choose that design. Additionally, the 'interest' will change over time, because of changes in the value of money, salaries, and the value of the solution. So, it depends both on what was considered the 'good' design and the very moment you're about to change that 'bad' design.

Maybe even the 'good design' back then, is not the same 'good design' you would go for now, because, you know... times have changed (evolution!). Can you even relate the debt of the 'bad solution' from way back when to the interest you need to pay now for that new, 'good' solution you want to implement? If not, what are we talking about? Let's assume you can. Why?... because both designs solve the same initial problem.

Ironically, it appears that money is a bad quantifier for technical debt. So, what actually is a good unit for measuring technical debt? Man-hours? Lines of code? The answer is (as always): it depends. This time it depends on the skills and knowledge level of your team members, on the programming language, and more like this.

'Good' vs 'Bad' design

Let's take a step back; if technical debt arises solely from the deliberate choice of the 'bad' design instead of the 'good' design, with the assumption that every 'bad' design is harder to change (hence, more expensive) than a 'good' design, then what defines a 'good' or 'bad' design? How can we measure this?

In general, 'good' design has some characteristics on the code level: low complexity, low duplications, low coupling, high cohesion, high test coverage, split into modules, and such. Analogously, a 'bad' design will then have high complexity, high duplications, high coupling, low cohesion, low test coverage, and (very) few modules. Many of these metrics can be measured, even automatically (e.g., Sonar).

Does measuring technical debt matter?

Having the metrics (complexity, duplication, test coverage, etc.) will help you find design flaws in the code, but it does not tell you whether this code, which is part of a bigger design, is like this on purpose. The intent is lost. It seems that measuring technical debt, as defined as deliberately choosing the 'bad' design, cannot be measured automatically.

So, does it matter to differentiate between technical debt and other design flaws? As a developer, you'll have to deal with the non-technical debt defects as well at some point. And aren't they just as painful to change as the deliberately chosen bad designs (at scale, of course)?

Conclusion

At the moment your team needs to redesign, refactor, or just maintain existing code, it does not really matter if any extra work (or costs) resulting from 'bad' design is coming from technical debt or other design flaws. They will have to deal with it either way.

The question whether a piece of code is in fact technical debt or not is the wrong question. The question to ask the team is: should we fix this crap now?

Gain insights

It is a good idea to record the deliberate choice of the 'bad' design. Make documenting design decisions a part of the design process. This, in general, is a good way to document designs; not just for technical debt, but for any design decision. As team members come and go, and software evolves, it is a good thing to be able to revise decisions made in the past and see why they were made to judge whether they're still appropriate. Basic information such as the problem it solves, the solution, and the arguments why are the most important. Sure, you don't document every design, just the key ones or the ones that are hard to change.

Technical debt is a term that shouldn't be used within development teams, as it is irrelevant to the development team members (just fix it now or later). You could use the term to explain to management at design time that taking that shortcut now will indeed shorten time-to-market, but will inevitable give problems (in terms of extra work) in the future.

To keep track of the design quality, you can use the SQALE method to measure this along multiple quality axes. A Sonar plugin for SQALE is available that rates the Technical Debt (misuse of the term!) of a project and/or component.

[m5n82]

Keeping a maintainable code base

The need to have a maintainable code base is something most developers know. But why is a maintainable code base important? How to get one? And more importantly, how to keep it?

Software evolves

You probably know that software evolves. Not like plants and animals, but in its own way. Plants and animals evolve by intrinsic feedback - whatever works for the specie itself. Software evolves by extrinsic feedback. This extrinsic feedback is given by the developers and end users of the software system.

Lehman [Lehman1996] described this phenomenon in his paper on the Laws of Software Evolution. He ‘discovered’ eight laws that support this. I will shortly discuss the laws that are the most relevant to maintainability.

Law I: Continuing change

Lehman’s first law is the law of Continuing Change, which he describes as “An E-type system that is used must be continually adapted else it becomes progressively less satisfactory.” (Lehman refers to an e-type system as a software system that solves a real-world problem; i.e., business application).

This law is originated in the fact that the software undergoes changes because of feedback pressures caused by mismatches between the system and the domain of the problem it is trying to solve. The feedback comes from the end-users in this case.

Law II: Increasing complexity

The second law is the law of Increasing Complexity: “As a program is evolved, its complexity increases unless work is done to maintain or reduce it.”.

This law describes the feedback loop originated in the developers of the program. The developers work hard to fix the mismatches between the system and the application domain and, as an effect, they make the system more complex (i.e., less maintainable). Every functional ‘improvement’ results in more complexity. Therefore, extra work needs to be done to deal with this complexity.

Law VI: Continuing growth

The sixth law of Lehman is the law of Continuing Growth: “Functional content of a program must be continually increased to maintain user satisfaction over its lifetime.”

It describes how the software needs to grow in order to keep users satisfactory. It is not directly related to the first law, which is about mismatches between the system and the application domain. This law is about user demands resulting from using the system.

Law VII: Declining quality

The seventh law is about Declining Quality: “E-type programs will be perceived as of declining quality unless rigorously maintained and adapted to a changing operational environment.”

This law refers to the phenomenon that any system declines in quality over time. This is not due to mismatches between the system and application domain (law I), not due to increasing complexity by developing (law II), nor due to changing or evolving requirements (law VI). Even if the system is not even used for a period of time, the quality will decline. This is mostly due to other external factors, such as the evolution of the dependent systems (e.g., new operating systems, new libraries, hardware, etc.). This will, sooner or later, cause incompatibilities and thus requires effort to maintain or adapt.

These laws describe the phenomena we as software engineers have to deal with when building and maintaining software systems. So, you better have (and keep!) a maintainable system to cope with them. If not, your system may not survive.

What about maintainability?

Maintainability is one category of quality attributes of software as specified in the ISO-25010 standard [ISO2001]. It comprises several sub categories: Analyzability, Modifiability, Modularity, Reusability, and Testability.

Analyzability

To what extent a software system can be understood and analyzed.

An understandable system is a system that...

...has a clear architecture.

...is decomposed into components that communicates the intent of the system.

...has clear layers with clear communication lines.

...implements patterns to solve common problems.

...has readable source code: uses proper naming for components, units, and variables that reflect the intent.

Analyzability is about understanding. If your system is highly analyzable, the result is that it will cost you reasonable effort (and hence reasonable money) to locate and analyze a problem in the system.

Modifiability

To what extent a software system can be modified without affecting the overall stability of the system.

A modifiable system is a system in which…

...developers are able to modify one component without a ripple effect.

...developers are able to modify a component, without affecting overall stability.

A highly modifiable system typically will cost you reasonable effort and money to fix a problem. Changes can be done locally, in at most a few components, and you don't have to worry about unexpected side-effects.

Stability is another quality attribute of the ISO-25010 standard, at the same level as maintainability. However, it is closely related to modifiability. You don’t want to modify something in this place, and all of a sudden something else over there collapses. Sounds familiar? You might want to rethink Modularity.

Modularity

To what extent a software system is decomposed into separately modifiable components.

It does not really matter how you do this, as long as you have a suitable architecture in mind; and it depends much on the programming paradigm. Modularity is probably easier to achieve in object-oriented programming, than in other paradigms. However, the more complex the system becomes, the more you will need some decomposition.

Decomposition is something that humans naturally do to be able to keep concepts in mind. For instance, if you want to explain the workings of the universe it is useful to decompose it into concepts such as energy and matter, and matter into particles, and so on.

If you have a complex system, make it simpler by decomposing into the domain concepts, and these concepts into smaller concepts, etc. If you pick the concepts right, your system is still as powerful, but much easier to understand. If you separate concerns well, you can modify the components without affecting overall stability.

Reusability

To what extend existing parts of the system can be reused.

Reusing code can be achieved by many techniques, and it can be done vertically or horizontally. The key part is that it should be possible to reuse components. What your components are, depends on the choices you made in making modules and depends on the programming paradigm. They can be functions, modules, classes, packages, namespaces, etc.

In functional programming, your components might be functions. If you can reuse your functions and they are self-contained, then you're probably good. Make them configurable, and you can reuse parts without altering their source code.

Testability

To what extent the system can be tested to validate (changed) acceptance criteria.

Whether it is that your system is unit testable, or integration testable, does not really matter for this quality. As long as you can control the state of the system to validate that it is correct, the system is testable. It does matter to what extent.

It is great if you can test every unit individually. A testable system is easier to modify because you can validate that it is correct, and find out if so within a small amount of time. Moreover, if you keep your tests as part of the project, you can revalidate at any time after modifications are made.

Important is not only to keep it testable, but to extent the test suite whenever modifications and additions are made.

Conclusions

Your software project evolves without a doubt and with no exceptions. This is due to forces of external factors such as developers, the end-users, or the environment. So you should better keep it maintainable if you want to be able to continue delivering.

Maintainability is about the aspects of having a testable, modular system, consisting of reusable components, that can be understood and changed without much effort.

Getting and keeping a maintainable system is about constantly considering the quality attributes that make up maintainability while designing and implementing code.

If you have to maintain a legacy system that is not well designed, you will need to redesign and refactor the parts that are hard to understand, hard to modify, or hard to test in order to increase quality.

References

[Lehman1996] M.M. Lehman, Laws of Software Evolution Revisited, 1996

[ISO2001] International Standards Organization (ISO), ISO/IEC 25010:2011 Systems and software engineering, Systems and software Quality Requirements and Evaluation (SQuaRE), System and software quality models, 2011

[m5n82]

How code duplication impacts software maintainability

As a software engineer, you probably know some colleagues who tell you that code duplication is bad. Chances are that you also know some colleagues who tell you that code clones are not necessarily a bad thing. But what is the truth about code clones? Is there a truth? Or is it a matter of trade-offs, like so many things in our profession?

Code clones

Let’s start off with a definition of a code clone. “A code clone is a portion in source code that is identical or similar to another” [Kamiya2002]. This basically means that any portion that seems the same, either a copy or the same intent and structure, is considered duplication.

There are various reasons for intentionally duplicating code portions. In a study by Kapser and Godfrey [Kapser2006] they identified cloning design patterns. Each pattern addresses a reason for cloning code which they present as good ways of introducing duplication. For example, in some cases in an object-oriented environment, abstraction is not the right choice to reuse previously implemented functionalities. This may be the case when two parts of the system need to have similar functionality, but need to evolve independently or eventually replace the cloned component.

However, there are also duplications that were made using anti-patterns, which do not serve the special purposes as identified by Kapser and Godfrey. This kind of cloning is mostly due to habitual behavior of the developer (i.e., the mental macro), or a lack of understanding of the system under maintenance, the problem, or the solution.

Long story short; developers introduce code duplications either intentional - by optimizing other quality attributes of the system (e.g., performance), temporary clones, or a lack of understanding - or unintentional - because of a mental macro; habitual behavior of the developer [Kamiya2002].

Maintainability

People who say that duplicating code is bad, often refer to the argument that code clones are hard to maintain. To put it more formally, the code clones co-evolve, i.e., a change to one segment of the clone may or may not need to be propagated to several others. This co-evolution incurs unnecessary maintenance effort and costs [Geiger2006, Thumma2010].

The ones that say that duplicating code is a good thing say that duplicating code is a form of code reuse. As we have seen in the previous section, there are all kinds of reasons for cloning code. Kapser and Godfrey state that duplicating code can have a positive effect on maintainability. For example, it can keep your architecture clean and understandable [Kapser2006].

Up to 80% of the overall costs and effort in the software development life-cycle is spent on maintenance [Thumma2010]. Therefore, maintainability should be considered an important quality attribute during the software development process.

Maintainability is a category of software product qualities as defined in the ISO-25010 standard [ISO2011]. This category has the following quality attributes:

Analyzability - to what extent the system can be understood and analyzed

Modifiability - to what extent the system can be modified without affecting the overall quality of the system

Modularity - to what extent the system is decomposed into separately modifiable modules

Reusability - to what extent an existing part of the system can be reused

Testability - to what extent the system can be tested to validate (changed) acceptance criteria

To summarize, according to the ISO standard, a maintainable software product has the following properties:

Easy to analyze and understand

Easy to modify without affecting the overall stability

Modularized to localize change

Composed of reusable components

Easily testable to validate acceptance criteria

To be able to tell that one software product is more maintainable than another software product, we have to find a measure. We will use time and effort as a measure of software maintainability. For example, we can say that system A is more maintainable than system B if it takes less time and effort to change the same feature in system A than it takes in system B.

Maintaining clones

Clones that were introduced because the developer had a lack of understanding the system, the problem, and/or the solution; the clones are there to avoid risks in the system under maintenance. These clones had better be replaced by a solution that generalizes the concept. Clones of this kind co-evolve and need some kind of management to maintain. This management can be a piece of documentation that tells developers where clones of that code portion resides in the code base. Unless well-documented, this will have a negative effect on the analyzability of the software system. Therefore, these kinds of clones induce extra maintenance effort and have a negative effect on the overall maintainability of the system.

Clones created because of a mental macro are unintentional by nature. This implies that the developer does not realize he/she is introducing a clone, which results in a non-documented clone. Additionally, these clones’ evolution are expected to be closely related. Maintaining these clones are error-prone and a potential threat to the system’s overall stability. This has a negative effect on the modifiability of the system (because of regression defects), and therefore a negative effect on the overall maintainability.

Optimization clones are created to improve other quality attributes. These clones essentially co-evolve. Unless well-documented, these clones increase maintenance effort. However, the overall quality of the system should be at least as good as before the cloning.

Temporary clones are created to replace components in a later stage. However, documenting the clones is required if the basis of each clone needs to stay up-to-date with the original.

Conclusion

So, if the clones are managed (i.e., every duplicate, and the original, has a well-documented reference to all others and possibly describing the intent of the clone), then maintaining the clones becomes easier and definitely more structured than un-managed clones (i.e., without the documentation). The ease is gained by knowing where the clones reside. Still, a developer maintaining them should always consider whether the modification needs propagation; for each clone.

If, on the other hand, the clones are not managed (i.e., without proper documentation), then maintaining them becomes a hard job. The developer can easily forget to update a clone. It takes more effort to decide whether a duplicate needs change.

In either case, it inevitably takes more time and effort to maintain clones than if it were just one piece of code to update. In general, we see a reduction in the analyzability, modifiability, and eventually modularity of the software system due to code duplications. Therefore, we can conclude that code clones are harmful for software maintainability.

References

[Geiger2006]

R. Geiger, B. Fluri, H. Gall, and M. Pinzger, Relation of code clones and change couplings Fundamental Approaches to Software Engineering, 9th International Conference, FASE 2006, vol. 3922 of Lecture Notes in Computer Science, p 411-425, Springer, 2006

[ISO2011]

International Standards Organization (ISO), ISO/IEC 25010:2011 Systems and software engineering, Systems and software Quality Requirements and Evaluation (SQuaRE), System and software quality models, 2011

[Kamiya2002]

T. Kamiya, S. Kusumoto, and K. Inoue, CCFinder: a multi-linguistic token-based code clone setection system for large scale source code IEEE Transactions on Software Engineering, 2002

[Kapser2006]

C. Kapser, and M.W. Godfrey, 'Cloning considered harmful' considered harmful Proceedings of the 2006 Working Conference on Reverse Engineering, p 19-28, Benevento, Italy, IEEE Computer Society, 2006

[Thumma2010]

S. Thummalapenta, L. Cerulo, L. Aversano, and M. Di Penta, An empirical study on the maintenance of source code clones Journal of Empirical Software Engineering, 2010