Accurately estimating the scope of software rewrite projects is a difficult task. These projects involve working with existing applications, each with its own unique complexities and surprises. Traditional estimation methods may not fully account for these nuances, resulting in inaccurate project timelines and scopes. Here, I’ll present a refined estimation technique specifically designed for software rewrites, focused on the intricate legacy systems that often form the foundation of these projects.
The Complexities of Legacy Systems
Legacy systems always hold hidden complexities. While the features may appear simple on the surface, there are often layers of intricate and outdated code, custom solutions, and undocumented fixes underneath. These complexities can vary greatly and have a significant impact on the accuracy of project estimations.
This complexity can challenge someone estimating the time and effort of replacing such a system. Even with a multi-week Research, Design, and Planning engagement (RDP), the time available for analysis and estimation of the old system and room for design of the new system are much too short to de-risk adequately.
One way to better approximate the scale of a rewrite can be achieved with access to the legacy system’s source code. Measuring the lines of code in the legacy system, particularly the components of the system that need to be rewritten or which the rewritten component may need to integrate with, gives a measure of how much “stuff” is in the current app. It’s therefore a proxy estimate for the work required to build an alternative solution.
Detailed Explanation of the LOC-Based Estimation Technique
The Lines of Code (LOC) estimation technique provides a nuanced approach to capturing these complexities. Here’s a step-by-step breakdown of how to implement it.
- Accessing the Codebase: Begin by securing access to the existing application’s source code. This step is crucial as it lays the foundation for the entire estimation process.
- Identifying Key Sections: Methodically survey the application to pinpoint code sections relevant to the project’s scope. It is helpful in this step to call out critical elements, such as intricate business logic or complex algorithms.
- Counting the LOC: Quantify the effort by meticulously counting the lines of code in these identified areas. This count is a proxy for the complexity and scope of the work involved in the rewrite.
- Estimating speed of rewrite: Pick a lines-of-code-per-developer-per-day (LOC-per-dev-day) number to represent the speed of replacing the various components, or a single aggregate number. 50-100 is standard for writing new code, and something in this range (typically at the higher end) is appropriate most of the time.
- Compute the number of developer-days: Divide the LOC by the LOC-per-dev-day to get the number of days it would take a single hypothetical developer to work through the legacy scope.
- Scale to a team: Divide the developer-days by the number of devs on the team to get an estimate for how many days should be added to the project timeline.
Calculating the Impact on Project Cost and Timeline
Once we have identified the relevant sections of the legacy code and counted the lines of code, we can calculate the estimated number of developer days needed for the rewrite. This calculation is straightforward but crucial for understanding the project’s timeline and resource allocation. Here’s how it works:
Determine the Total Lines of Code (LOC)
- Count the number of lines in the identified sections of the legacy system.
- For example, let’s say we have 10,000 lines of code.
Set the Average Lines per Developer per Day
- Based on the complexity and quality of the code, set a realistic average of lines a developer can handle per day.
- Assume, for this example, 100 lines per day.
Calculate Developer Days Estimate
- Divide the total lines of code by the lines per developer per day.
- Developer Days = Total LOC / LOC per Day
- In our example: 10,000 LOC / 100 LOC/Day = 100 Developer Days
Factor in the Number of Developers
- Depending on the size of your team, divide the developer days by the number of developers.
- With 4 developers: 100 Developer Days / 4 Developers = 25 Calendar Days
Convert to Calendar Weeks and Estimate Cost
- Convert the calendar days into weeks (assuming a 5-day work week).
- Calendar Weeks = Calendar Days / 5
- In our example: 25 Days / 5 = 5 Weeks
- Multiply the number of weeks by the weekly team cost to estimate the total cost component.
- Total Cost Component = Calendar Weeks x Weekly Team Cost
By following these steps, you can estimate the time and resources needed to address the legacy code in your software rewrite project. This method offers a pragmatic approach to planning, helping ensure that your project timelines and budgets are realistic and well-informed.
Tips and Variations
Variations in the LOC Estimation Technique
The LOC estimation is not a one-size-fits-all technique; it can and should be tailored to the specific context of the project.
- Code Quality Adjustments: If the code is well-written, clear, and well-documented, you might move towards the higher end of the LOC-per-day spectrum. Conversely, poor quality or complex code will require a more conservative approach.
- Relevance of Code Sections: Not all code in the existing system will be relevant to the rewrite. Distinguish between code that needs to be rewritten and code that serves as a reference or is obsolete.
- Redesign and Refactoring Needs: Consider the extent of redesign or refactoring required. A complete overhaul of the system will require a different approach than minor tweaks or updates.
Integrating LOC Estimation with the 50-90 Technique
To get an accurate estimate, use the LOC-based technique along with the 50-90 estimation method. The 50-90 method is great for estimating new development or major changes. You get a complete picture of the project’s workload when you include the LOC-based estimate for the existing components. Make sure you don’t count the same elements twice, as they may be shared between the new development and the existing system.
Clarifying the Role of LOC Measurement
It is important to clarify a common misunderstanding: the number of lines of code per developer per day is not a reliable measure of team efficiency. This metric is meant to assess the complexity of a project, not to evaluate performance. The approach to handling complexity in a legacy system may vary greatly in terms of size and scope compared to the original, often resulting in a smaller codebase due to improved design or narrowed scope. Nevertheless, every aspect of the legacy system requires thorough consideration and strategic planning.
Practical Application and Challenges
Applying the LOC technique in real-world scenarios comes with its set of challenges. For instance, unforeseen complexities may emerge, requiring adjustments to the LOC metric. It’s essential to remain flexible and reassess parts of the code as new information surfaces. Here are some strategies to effectively navigate these challenges.
- Identify Crucial Code Parts: Develop criteria for what constitutes ‘crucial parts’ of the code. This might include core functionalities, modules with dense logic, or areas with extensive historical fixes.
- Efficient LOC Counting: Use tools and techniques that streamline the counting process, ensuring accuracy without getting bogged down in details.
- Ongoing Adjustments: Be prepared to adjust your estimates as the project progresses. Regular reviews and updates to the estimate can accommodate new insights and changes in project direction.
A Closer Look: Estimating a CRM System Rewrite
TechSolutions Inc. is embarking on a comprehensive rewrite of its legacy CRM system, characterized by performance bottlenecks and outdated codebases. This initiative necessitates a strategic approach to estimate the effort required accurately. The project is divided into two main components: the core code, which is essential for the CRM’s primary functionalities, and the reference code, which supports these primary functions but is not central to the CRM’s operation.
Core Code: Navigating Complexity
The core code of the CRM encompasses critical functionalities such as customer data management, analytics, and reporting. This segment is notorious for its complexity, resulting from years of accumulated legacy practices, including the use of outdated libraries, custom patches, and a lack of comprehensive documentation. These factors significantly impact the readability and maintainability of the code, necessitating a meticulous rewrite process.
- Total LOC (Core): 20,000
- LOC per Developer per Day (Core): 75, reflecting the intricate nature of the core code and the cautious approach required to prevent functional regressions.
The calculation for the core system rewrite effort is as follows:
– Developer Days (Core) =
20,00075
Developer Days = 266.67 Developer Days
Reference Code: Ensuring Seamless Integration
In contrast, the reference code includes functionalities like auxiliary user management and logging, which, while necessary, do not directly impact the CRM’s core operations. This code is generally more straightforward and may adhere to more modern coding practices, making it easier to navigate and reference to ensure compatibility with the rewritten core system.
- Total LOC (Reference): 30,000
- LOC per Developer per Day (Reference): 1,000, accounting for the less intensive nature of working with reference code, which primarily involves reviewing for compatibility rather than comprehensive rewriting.
The estimated effort for handling the reference code is:
– Developer Days (Reference) =
30,0001,000
Developer Days = 30 Developer Days
Combined Effort and Project Timeline
Summing the efforts for both core and reference code segments yields a total of 296.67 Developer Days. With a dedicated team of 5 developers, the project is estimated to span:
- Calendar Days =
296.675
Days = 59.33 Days
– Calendar Weeks =
59.335
Weeks ≈ 12 Weeks
This detailed estimation provides TechSolutions Inc. with a clear roadmap for the CRM system rewrite, highlighting the importance of understanding both the complex nature of the core functionalities and the supportive role of reference code. By distinguishing between these two components and tailoring the LOC/developer/day parameter accordingly, the project team can set realistic expectations and allocate resources efficiently for a successful rewrite.
More Accurate and Dependable Estimates
Adding a detailed LOC-based approach to your estimation toolkit can greatly improve the accuracy and dependability of software rewrite project planning. By thoroughly assessing the intricacies of legacy systems and combining this analysis with traditional estimation methods, project leaders can establish achievable goals, enhance communication with clients, and better manage project risks. This method requires a thorough understanding of the current codebase, but it can lead to more successful and predictable project results in the constantly changing world of software development.