Disability Benefits: Audit And Remove Feature Toggles

by Alex Johnson 54 views

Introduction

In the realm of software development, feature toggles are powerful mechanisms that enable developers to modify system behavior without altering code. However, as projects evolve, these toggles can become obsolete, leading to code clutter and potential performance issues. This article delves into the critical task of auditing and removing feature toggles associated with Disability Benefits within the Department of Veterans Affairs (VA). Specifically, we will focus on identifying and retiring unnecessary feature toggles related to 526 forms and ancillary processes. The goal is to streamline the codebase, enhance maintainability, and optimize system performance. By systematically reviewing and removing these toggles, engineers can ensure that the application remains efficient, scalable, and aligned with current operational needs.

The proliferation of unused or unnecessary code not only increases the complexity of the system but also poses risks in terms of security vulnerabilities and operational inefficiencies. Regular audits and cleanups of feature toggles are essential for maintaining a robust and reliable application. This article aims to provide a comprehensive guide on how to approach this task, including identifying candidate toggles for removal, reviewing their usage history, and executing the removal process in a safe and controlled manner. By following the steps outlined in this article, engineering teams can proactively manage their feature toggles and ensure a cleaner, more efficient codebase. This proactive approach to code maintenance not only improves the overall quality of the application but also reduces the likelihood of future issues and enhances the developer experience.

Our exploration begins with an engineer's perspective, aiming to reduce unused code by auditing and retiring feature toggles. We will investigate specific toggles found on the staging environment and outline the steps needed to determine their relevance and potential for removal. This process involves reviewing activity logs, creating a prioritized list of toggles for retirement, and establishing tasks for their removal. The end result is a cleaner, more efficient codebase that enhances system performance and maintainability.

User Need: Streamlining the Codebase

As an engineer, the primary objective is to audit and retire no longer needed feature toggles. This process aims to reduce the amount of unused or unnecessary code, which can lead to improved system performance, reduced maintenance costs, and a more streamlined development process. Feature toggles, while useful for managing feature releases and experimentation, can become liabilities if not properly maintained. The presence of numerous obsolete toggles can clutter the codebase, making it harder to understand and potentially introducing conflicts or unexpected behavior. Therefore, a systematic approach to identifying and removing these toggles is crucial for maintaining a healthy and efficient software system.

The need to streamline the codebase is not just about aesthetics; it has tangible benefits for the entire development team and the end-users. A cleaner codebase is easier to navigate, which reduces the time spent on debugging and maintenance. It also makes it easier to onboard new team members, as they don't have to wade through layers of obsolete code. Moreover, a streamlined codebase is less prone to errors and security vulnerabilities, as there are fewer lines of code to scrutinize. By prioritizing the removal of unused feature toggles, engineers can contribute to a more robust, reliable, and maintainable software system. This proactive approach to code management not only improves the developer experience but also enhances the overall quality of the application.

Moreover, regular audits of feature toggles help ensure that the system remains aligned with current business requirements and user needs. As the application evolves, some features may become obsolete or replaced by newer functionalities. In such cases, the corresponding feature toggles should be retired to prevent any potential conflicts or confusion. By keeping the codebase lean and focused, engineers can ensure that the system remains agile and responsive to changing requirements. This adaptability is crucial for maintaining a competitive edge and delivering value to users in a timely manner. Therefore, the ongoing effort to audit and remove feature toggles is an essential part of the software development lifecycle.

Description: Feature Toggles Under Review

Here's a list of feature toggles related to 526 and ancillary forms, discovered on the staging environment (https://staging-api.va.gov/flipper/features): These toggles control various aspects of the disability benefits application process, from sending claim dates to Lighthouse to enabling browser monitoring and managing email notifications.

  1. disability_526_add_claim_date_to_lighthouse
    • Enables sending the claim date to Lighthouse when submitting a Form 526EZ if present.
  2. disability_526_browser_monitoring_enabled
    • Enables Datadog RUM for the disability 526 submission frontend workflow.
  3. disability_526_call_received_email_from_polling
    • Enables received email in poll_form526_pdf job and disables calling from form526_submission.
  4. disability_526_ee_process_als_flash
    • Enables adding applicable flashes to disability_526 prior to submission.
  5. disability_526_form4142_polling_records
    • Enables creation of, and tracking of, sent form 4142 documents, from the 526 flow, to the Lighthouse Benefits Intake API.
  6. disability_526_form4142_use_2024_version
    • Enables the 2024 version of form 4142 in the disability 526 submission frontend workflow.
  7. disability_526_improved_autosuggestions_add_disabilities_page
    • Enables new version of add disabilities page, with updates to content and search functionality.
  8. disability_526_send_form526_submitted_email
    • Enables sending submitted email in both primary and backup paths.
  9. disability_526_show_confirmation_review
    • Enables showing a submission review section on the 526 confirmation page.
  10. disability_526_toxic_exposure_opt_out_data_purge
    • Enables function that removes toxic exposure data if user has opted out from toxic exposure condition on Form 526 submission.
  11. disability_compensation_0781_stats_job
    • Enables a job to run that will check DB records and report stats as metrics into Datadog.
  12. disability_compensation_0781v2_extras_redesign
    • If enabled, the 0781v2 overflow page will use the new design.
  13. disability_compensation_email_veteran_on_polled_lighthouse_doc_failure
    • Sends document upload failure emails when polled doc uploaded to Lighthouse has failed to process at Lighthouse.
  14. disability_compensation_flashes
    • Enables sending flashes to BGS for disability_compensation submissions.
  15. disability_compensation_form4142_supplemental
    • Use Lighthouse API to submit supplemental Form 21-4142 from Form 526EZ submissions.
  16. disability_compensation_sync_modern0781_flow_metadata
    • Enables adding new 0781 form indicator to in-progress 526 forms and saved claim records for 526 submissions.
  17. disability_compensation_sync_modern_0781_flow
    • Enables a new form flow for 0781 and 0781a in the 526 submission workflow.
  18. disability_compensation_temp_separation_location_code_string
    • Enables forcing separation location code to be a string in submit_all_claim endpoint.
  19. disability_compensation_upload_0781_to_lighthouse
    • If enabled, uploads 0781/a forms to Lighthouse Benefits Documents API instead of EVSS.
  20. disability_compensation_upload_veteran_evidence_to_lighthouse
    • If enabled, uploads Veteran Evidence to Lighthouse Benefits Documents API instead of EVSS.
  21. disability_compensation_use_api_provider_for_0781_uploads
    • Provide a temporary killswitch for using the ApiProviderFactory to select an API for uploading 0781/a forms.
  22. disability_compensation_use_api_provider_for_bdd_instructions
    • Provide a temporary killswitch for using the ApiProviderFactory to select an API for uploading BDD instructions.
  23. disability_compensation_use_api_provider_for_submit_veteran_upload
    • Provide a temporary killswitch for using the ApiProviderFactory to select an API for uploading Veteran Evidence.

Each of these feature toggles plays a specific role in controlling the behavior of the disability benefits application. To effectively audit and determine which toggles can be removed, it's essential to understand their purpose, usage history, and current relevance. The following tasks outline the steps needed to conduct a thorough review and identify candidates for retirement.

Tasks: A Step-by-Step Approach

To achieve the goal of auditing and removing obsolete feature toggles, the following tasks need to be undertaken:

  • Investigate Additional Feature Toggles: Determine if there are any other disability benefits-related feature toggles not listed in the description that should be addressed.
  • Review Activity/Audit Logs: Examine the activity/audit logs to understand the usage patterns and history of each feature toggle.
  • Prioritize Toggles for Review: Based on the initial assessment, prioritize the toggles that are most likely to be candidates for removal.
  • Assess Toggle Relevance: For each prioritized toggle, conduct a detailed assessment to determine if it is still relevant and serving its intended purpose.
  • Consult with Stakeholders: Engage with relevant stakeholders, such as product owners and other engineers, to gather insights and validate the findings.
  • Create Removal Tasks: For toggles identified as candidates for removal, create specific tasks outlining the steps required to safely retire them.
  • Execute Removal Tasks: Implement the removal tasks, ensuring that all necessary code changes are made and thoroughly tested.
  • Monitor System Performance: After removing a toggle, monitor system performance to ensure that there are no adverse effects.
  • Document the Process: Maintain detailed documentation of the entire audit and removal process, including the rationale behind each decision.

Acceptance Criteria: Defining Success

The success of this initiative is measured by the following acceptance criteria:

  • Feature Toggle List: A comprehensive list of feature toggles is created, and those ready for retirement are clearly identified.
  • Removal Tasks Created: Tasks are created for removing each identified unused feature toggle. These tasks should link to the relevant documentation on removing old/unused feature toggles.

Definition of Done: Ensuring Quality

The definition of done for this task includes:

  • Meets Acceptance Criteria: All acceptance criteria are fully met.
  • Reviewed and Approved: The work is reviewed and approved by product and/or design stakeholders.

Engineering Considerations

From an engineering perspective, the following points are crucial:

  • Testing: All tests must pass to ensure that the removal of feature toggles does not introduce any regressions.
  • Unit Tests: New functionality (if any) should be covered by unit tests to ensure its reliability.
  • Logging and Monitoring: Implement logging and monitoring (if applicable) to track the behavior of the system after the toggles are removed.

Code Review & Pull Requests

When submitting code changes, ensure the following:

  • Local Testing Steps: The pull request (PR) includes clear steps for local testing.
  • Flipper/Testing State Details: The PR includes details about the Flipper/testing state (if applicable).
  • Submission Screenshot: The PR includes a screenshot demonstrating local proof of submission.
  • Copilot Review: A Copilot review is completed, and all feedback is addressed.
  • Internal Reviewer Approval: An internal reviewer approves the PR.
  • Staging Verification: Code functionality is verified on the staging environment after the merge.

Refinement Checklist

Before starting the work, ensure the following refinement checklist is complete:

  • Description, Tasks, and Acceptance Criteria: Added description, tasks, and acceptance criteria.
  • Estimate: Added estimate for the effort involved.
  • Practice Area Label: Labeled with the appropriate practice area (engineer, design, product, data science).
  • Issue Type and Characteristics: Labeled with issue type and characteristics (bug, accessibility, request, discovery, documentation, research, content, UX testing, front-end, back-end, Datadog, etc.).
  • Project Fields: Added any other relevant project fields (team, OCTO priority...).
  • Epic or Super Epic: Added an Epic or Super Epic to provide context.

Conclusion

Auditing and removing feature toggles is a critical task for maintaining a clean, efficient, and reliable codebase. By following the steps outlined in this article, engineering teams can proactively manage their feature toggles, reduce code clutter, and enhance system performance. Regular audits and cleanups of feature toggles are essential for ensuring the long-term health and maintainability of the application.

By systematically reviewing and removing these toggles, engineers contribute to a more robust, reliable, and maintainable software system. This proactive approach to code management not only improves the developer experience but also enhances the overall quality of the application, ultimately benefiting both the development team and the end-users. Embracing these practices ensures that the application remains agile, responsive, and aligned with evolving business requirements.

To learn more about feature toggles and their management, visit this comprehensive guide on Feature Toggles at LaunchDarkly