# 003 - Standard Python Module

Alexander Zabielski

Last Modified: July 1st, 2025

Title: Standardized Python Module (ibp_core) for Common IBP Calls

Status: Implemented

# Context

Our organization has been facing significant challenges with consistency and maintainability across various IBP projects.

A primary issue is the disparate use of libraries and different versions for common functionalities, such as MySQL calls, where various pymysql libraries are employed.
A widespread practice of copying and pasting identical or similar functions into multiple lambda functions has led to code duplication, increased maintenance overhead, and a higher risk of inconsistencies and bugs when updates are required. This fragmentation hinders development velocity and introduces unnecessary complexity in our codebase.
Additionally, the lack of a standardized approach to common operations has resulted in a steep learning curve for new developers, who must navigate through inconsistent implementations across different lambda functions.

# Decision

We will design and develop a standardized Python module, ibp_core, with controlled dependencies, that can be used universally across all IBP lambda functions for common calls and functionalities.

# Rationale

This decision addresses the critical need for consistency, maintainability, and efficiency across our IBP projects.

Factors that influenced the decision:
- Code Duplication: Eliminate the rampant copy-pasting of common functions.
- Dependency Management: Centralize and control the versions of external libraries (e.g., pymysql) used for common operations.
- Standardization: Ensure a consistent approach to common operations across all IBP lambda functions.
- Maintainability: Simplify updates and bug fixes for common functionalities, as changes only need to be made in one place.
- Developer Efficiency: Provide a readily available and tested module, reducing the need for developers to rewrite common code.
Evidence/Research: This approach is a standard best practice in software development for managing shared code and dependencies, often implemented through internal libraries or packages. Discussions with development teams highlighted the recurring issues stemming from the current fragmented approach.
Strengths of the chosen solution:
- Improved Code Quality: Leads to cleaner, more consistent, and less error-prone code.
- Reduced Development Time: Developers can leverage pre-built, tested functionalities.
- Simplified Maintenance: Updates and bug fixes become centralized and easier to deploy.
- Enhanced Scalability: A standardized module makes it easier to onboard new developers and scale our development efforts.

# Implications

People/Training: The developer team will require training on how to obtain this ibp_core project from the Azure DevOps Artifacts feed and integrate it into their lambda functions. They will also need to learn how to use the specific functions and conventions within the new module.
Process Adjustments:
- Existing CI/CD pipelines for lambda functions will need to be updated to include fetching and packaging the ibp_core module with the lambda code.
- All existing lambda functions that perform common actions (e.g., MySQL calls, common data manipulations) will need to be refactored to utilize the functions provided by the ibp_core module instead of their current implementations.
- New lambda functions will be mandated to use ibp_core for these common operations.
Tooling: The primary tooling change will involve the adoption and consistent use of the ibp_core module as a standard dependency within all IBP lambda functions. Azure DevOps Artifacts will be the central repository for the module.
Risks:
- Codebase Issues: Potential for bugs or performance issues within the ibp_core module itself, which could impact all consuming lambda functions. Thorough testing and version control will be crucial.
- Improper Use: Developers might initially misuse or misunderstand the module, leading to incorrect implementations. Clear documentation and training are essential to mitigate this.
- Migration Effort: The refactoring of existing lambda functions will require a significant initial effort and potential temporary disruption.

# Trade-Offs

Benefits:
- Significantly reduced code duplication across IBP projects.
- Centralized dependency management, ensuring consistent library versions.
- Improved code quality and reduced likelihood of inconsistent behavior.
- Faster development time for new lambda functions using common patterns.
- Easier maintenance and updates for common functionalities.
- Better onboarding for new developers who can leverage a well-defined standard module.
Drawbacks:
- Initial overhead for developing and thoroughly testing the ibp_core module.
- Required training and ramp-up time for the development team.
- Significant effort needed to refactor existing lambda functions to use the new module.
- Potential for a single point of failure if issues exist within the ibp_core module itself.

# Key Evaluation Metrics

Reduced Code Duplication: Measure the reduction in lines of duplicated code for common functionalities across lambda functions (e.g., identify and track the removal of redundant MySQL connection logic).
Consistency in Library Usage: Track the number of unique library versions for common operations (e.g., pymysql) in new or updated lambda functions, aiming for a single, controlled version.
Developer Onboarding Time: Measure any improvement in the time it takes for new developers to contribute effectively to IBP lambda functions, due to the availability of the standardized module.
Reduced Bug Rates: Monitor the number of bugs related to common functionalities, expecting a decrease as a result of centralized and thoroughly tested code.
Adoption Rate: Track the percentage of new and refactored lambda functions that successfully integrate and utilize the ibp_core module.

# Conclusion

We recommend proceeding with the design and development of the ibp_core standardized Python module. This strategic decision is crucial for addressing the current fragmentation, inconsistency, and high maintenance burden within our IBP projects. While there will be an initial investment in development, training, and refactoring, the long-term benefits of improved code quality, developer productivity, and simplified maintenance far outweigh these challenges. The next steps involve defining the scope of initial functionalities for the module, establishing a versioning and release strategy, and planning the phased migration of existing lambda functions.