Non-inclusive Text in Source Code – a Developer’s Journey

Words matter. They have the power to inspire and unite, fostering a culture where we can be our true selves. At Dell Technologies, we’ve established an inclusive language philosophy where we embrace diversity and inclusion (D&I), no matter what language we’re using – this includes coding language. After all, our code speaks for our technology.

I’m part of a working team from across Dell Technologies that meets regularly to identify and remediate non-inclusive language, no matter the platform where it’s used – be it web pages, product marketing material, user manuals, user interface text, and the source code that make up these products.

Below are examples of non-inclusive words with alternatives:

• • Master/Slave
    • Alternatives: Primary/Secondary, Parent/Child, Active/Standby
  •  Blacklist/Whitelist
    • Alternatives: Denylist/Allowlist, Blocked/Allowed, Reject/Accept
  • Blackhat/Whitehat
    • Alternatives: Unethical hacker/Ethical hacker
  •  Segregate
    • Alternative: Separate
  • Man-hour/Man-day/Man-month/Manpower
    • Alternatives: Person-hour/Person-day/Work-month/Workforce
  • Rule of thumb
    • Alternatives: Guideline

Dell’s goal is to replace non-inclusive text within application source code. Identifying and remediating every instance of non-inclusive text within our products represents a large and complex set of challenges. I’ll walk you through lessons we’ve learned on how to increase inclusion.

There are various ways to remove non-inclusive text from software products, including manual inspection of every line of code, building a tool to globally find and replace instances of offending text or putting policies in place to prevent new instances from being added to source code repositories. However, when developers are required to scan code manually or invoke a secondary tool to do so, there are two possible side effects: the process will be circumvented or releases will be delayed as D&I adds another layer of activity to the development and deployment process.

To address these challenges, I formed a multi-step solution that relies on automation with intelligent, assistive tools that become a natural part of the software development process:

• • At coding time: Automated source code scanning via an editor or integrated development environment (IDE) extension.
  • At build time: Static code analysis via a custom lint tool invoked during developer local builds.
  • At commit time: Automated source code scanning via a Git Webhook when code is pushed to a repository.

Step 1) Driving inclusiveness at coding time – The goal of the first step is to help developers catch non-inclusive text as they write code. For example, popular IDEs, such as Microsoft Visual Studio Code (VSCode), perform syntax checking and error highlighting in real time. This boosts productivity since it’s easier and quicker for a developer to fix an error in code just written. If you apply the same philosophy to D&I scanning, you can achieve the same goal: identification and remediation of non-inclusive text without impacting developer productivity. To try this, I built a VSCode extension to automatically search for and mark up instances of non-inclusive text in real time as though they are syntax errors (see Figure 1).

This form of D&I checking and remediation has virtually no impact on developer productivity as it doesn’t require additional steps or tools to run. Instead, it relies on an efficient paradigm that developers are already used to, within tools already in use. Avoiding non-inclusive terms becomes second nature.

Step 2) Updating the local build process – The second step is to create a custom lint tool for static code analysis that searches for non-inclusive words and phrases in source code. The tool is invoked as part of a developer’s local build process. If the developer somehow misses the visual indicators in the IDE, the warnings or errors produced here are harder to miss.

Sample output from a local build is shown here:

This tool works equally well with Make, Maven, Ant, Gradle and others across environments, development languages and operating systems. Automating the process, and assisting intelligently, helps to maintain developer productivity and increases the effectiveness of Dell’s inclusive language efforts.

Step 3: Extending the CI/CD process – In the third step, source code is scanned as part of the CI/CD process, and code is pushed to a repository to be included in a shared code base. This is important in case non-inclusive text has made it through the previous two checks. In this phase, the developer will be alerted via warnings or errors (see Figure 3), the push can be stopped, or a build manager can be alerted. Most Git vendors support Webhooks to support customizations to the CI/CD process, such as GitLab, GitHub, and BitBucket. Regardless of approach, scanning for non-inclusive text during the CI/CD process ensures software conforms to your D&I policy before it’s released.

At Dell, we’re working with a partner to centralize our dictionary and rules used for identification and remediation of non-inclusive terms. As we identify new words to remediate, we can update a primary list and the entire organization immediately benefits. The tools used in each step above (real-time scanning at coding time, static code analysis at build time, and scanning during the CI/CD process) leverage this single, company-wide, non-inclusive dictionary for consistency and timeliness.

Dell is taking diversity and inclusion seriously, but it will take our collective effort for real change. We’re working with peers and communities – like our work with Intel and other partners on the Alliance for Global Inclusion –  to expand these efforts across the industry to establish new industry-standard inclusive language that reflects the world we strive to see. I hope the process and steps I’ve shared help you as you explore your own D&I developer journey.