Deciding what constitutes a single module, what classes belong to which module or the right set of modules for a specific software system has always been a challenging task. The problem is even harder in large-scale software systems composed of thousands of classes and hundreds of modules. Over the years, researchers have been proposing different techniques to support developers in re-modularizing their software systems. In particular, the search-based software re-modularization is an active research topic within the software engineering community for more than 20 years.

This paper describes our efforts in applying search-based software re-modularization approaches at Adyen, a large-scale payment company. Adyen's code base has 5.5M+ lines of code, split into around 70 different modules. We leveraged the existing body of knowledge in the field to devise our own search algorithm and applied it to our code base. Our results show that search-based approaches scale to large code bases as ours. Our algorithm can find solutions that improve the code base according to the metrics we optimize for, and developers see value in the recommendations. Based on our experiences, we then list a set of challenges and opportunities for future researchers, aiming at making search-based software re-modularization more efficient for large-scale software companies.@en

Code quality of software products often degrades while they grow. Counteracting the degradation of code quality or improving it requires immense effort. Tools that reduce this effort are a hot topic in software engineering research. Software Modularization in particular aims to aid in the process of improving the quality of code structure, by finding flaws in code structure and suggesting improvements. Much research has been done in this field, however, most of it is applied on small to medium scale codebases. In addition, the quality of solutions implied by this research is often not properly validated. This thesis aims to apply an existing approach to an enterprise-level codebase, namely that of Adyen, and validating the results with developers experienced with the code. We achieve this by taking a graph-based approach, applying the NSGA-II algorithm, and introducing a new metric called the Estimated Build Cost of module Cache Breaks. We evaluate the approach in two ways. First, we performed a controlled experiment exploring the feasibility of the approach on larger scale codebases. For this experiment, we apply the approach to the Adyen codebase. The results show that the approach is scalable and shows a significant improvement of code quality in terms of the metrics used. We then performed a user study where we explore the feasibility of these results in practice. For this study, solutions generated during the experiment are split up and filtered to form groups with less than 10 changes, which are reviewed by developers that have changed that code recently or are a senior with experience in that specific area of the code. The results show that the algorithm is successful in identifying flaws in the codebase. However, the improvements it suggests are less precise and require future work.

This report explains the design choices, implementation and results of a software engineering project commissioned by MakeTek. The team was tasked with making a system that could solve bike delivery scheduling problems with limited bike carrying capacity, time windows, dynamic delivery additions, movable pickup points and delivery time estimates.

The project started with two weeks of research, which concluded that the main algorithm should be a Genetic Algorithm (GA). The final product contains an app for visualising results as well as a backend that runs the genetic algorithm. Both systems are written in TypeScript and built upon a boilerplate provided by MakeTek. To calculate routes an open source routing provider is used, and the project is executed with an agile development workflow to ensure the product conforms to the client's expectations.

The implemented system contains almost all desired features and the missing ones were chosen to not be included due to time constraints and limited functional benefits. It is well-tested, extensible and adheres to software quality standards.

A solution is constructed by first clustering deliveries by location to distribute them over the bikes, then the genetic algorithm is run on each cluster separately. At the end of every generation of the GA the intermediate best solution is saved in a database. This ensures a valid solution is available at all times. Finally, postprocessing can be run on the final solution which checks if it is more efficient for a deliverer to wait between certain deliverers to prevent them from being early.

Testing shows that the implemented system and its features work as intended on different datasets. The effect of different parameters on the performance of the genetic algorithm is explored, with the following conclusions:

The algorithm should have enough opportunity to explore the solution space. This is achieved by setting an appropriate mutation parameter.

No significant performance differences are present between single point, two-point and uniform crossover.

Tournament selection converges faster than roulette selection, but explores less of the solution space.


The resulting system successfully implements all of the requirements as set by the client. It includes an algorithm that converges to an optimum, it can adapt to new changes and a solution can be requested at any time during runtime. It can be concluded that the project is brought to a successful end.