Simplifying large Python projects by distributing complexity.
The talk
Schedule
Room: Room 218
April 4
15:00–15:45
Abstract
An overcomplicated project increases development and maintenance time. If a complete redesign is not possible, we can distribute the complexity across the existing codebase. If AI assistants cannot help us with this task yet, we should discuss manual methods and tools that can be useful. Using examples of real large projects, we will discuss that despite different business types, geographical and social contexts, these projects share similar architectural mistakes and how they can be redesigned.
Prerequisites
This talk is for persons with knowledge about refactoring and experience with legacy Python projects.
Description
The purpose of this talk is to define the necessary steps for startups after the initial growth explosion to support successful future adaptation.
Let’s imagine a successful startup. Brilliant ideas require quick realization. Customers are happy, investors ask to add more functionality. With time, the project copes with a serious initial surge of interest and growth stabilizes . The team scales up with the project. Some programmers leave, new ones come in. Parts of the project are rewritten due to lack of documentation or technology not meeting business needs. But suddenly the productivity of the developers collapses - this is the so-called “second act” of the project’s life with the following symptoms:
Exponential growth of required tools and technologies Low revenue from additional features vs. high development costs Enormous growth in the number of people involved Since it is impossible to avoid the occurrence of the second act of project life, it is necessary to prepare for it in advance in order to minimize negative consequences and enhance positive impacts.
Preventive actions:
Implementing a Code Style Guide to unify parts of the code base. Gather opinions on keeping legacy code or a complete refactoring. These will become future milestones on your project roadmap. Documentation in the form of “What do I do if I die?”. Spreading complexity through separating parts of a project into isolated blocks:
GPT tools, how they can help, and why they can’t help. Manual tools and techniques for identifying and avoiding interfacing patterns in the project. Adding the bundle of individual applications if microservices are not a solution. Packaging parts of code into separate libraries. Separating settings.
For each topic, I will give examples of working with large projects that are at the “beginning of the second act”. Despite different business types, geographical and social contexts, these projects shows similar architectural mistakes, which will be discussed.
