Process Refactoring

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

Real World

  • Often ad hoc, i.e., no actual process
  • Developers with different levels of knowledge, experience, and capabilities
  • Management with different levels of knowledge, experience, and capabilities
  • Stated goals versus reality
  • Political issues


  • The problems in your work situation are not unique
  • These problems happen more often than you think

Massive Changes

  • Require retraining
  • Lead to failure due to:
  • Personalities
  • Individual goals
  • Previous history
  • Especially a problem for ad-hoc environments
  • Are often wrong, i.e., Big Design Up Front (BDUF)
  • Have to be perfect, i.e., "Can't win" situation

Incremental Changes

  • Give people time to adjust
  • Give the system time to adjust
  • Prepare the way for future changes (and improvements)
  • Can be judged on an individual basis
  • Much easier politically

Process Refactoring

  • Current system/process may be dysfunctional, but it works
  • Identify parts of the process that can be improved
  • Improve that small part
  • Integrate the new part into the system
  • Allow time for the ramifications to occur (and for you to get credit)

Process Refactoring Catalog

  • An (incomplete) list of refactorings to apply to a process
  • My list (so very tentative)

Version-Control Refactoring

  • Introduce version control into the system
  • Release code from version control
  • Versioning applies to all artifacts, not just code
  • Can be done locally by individual developers before being integrated into the overall group

Archive Refactoring

  • Keep archives of all changes and historical information
  • Relatively easy to do if Version-Control Refactoring is applied first
  • For non-versioned artifacts, keep copies of previous work
  • Benefit: Validates who did what and when
  • Benefit: Provides historical data for future analysis

Format Refactoring

  • Change to a better format for artifacts
  • "better" in the sense of:
  • Easier to maintain
  • Grows with the project
  • Can be used to generate other artifacts automatically
  • Examples: Markdown, YAML, JSON, XML, XHTML formats
  • Converters may be needed

Text-to-Data Refactoring

  • Instead of explanatory text, use a data format to define
  • A data format can easily be processed by a program
  • Does not require manual interpretation
  • E.g., Source-code licenses in source-code file
  • Often boiler-plate code
  • SPDX
  • SPDX ids

Comparison Licenses

Format-Refactoring Examples

  • Simple, Markdown format for Requirements
  • Post documentation in PDF instead of Word
  • Post documentation on a shared drive instead of email, e.g., Dropbox
  • Supply update notices via Twitter instead of emails
  • Others? What about UML?

Split-Artifact Refactoring

  • E.g., Description of feature and legal ramifications
  • A single artifact may have low cohesion
  • Split the single artifact into more than one
  • Relatively easy to combine artifacts when needed
  • Different roles may have their unique views

Forward-Engineering Refactoring

  • E.g., Generate base code from UML design
  • Automatically generate artifacts from other artifacts
  • Problem: Evolution
  • Small scale example: Generate terms for documentation from code

Kill Zombie Artifacts Refactoring

  • Many processes have artifacts that are not ever used but are still maintained and eat (time from) living artifacts
  • How do you kill a zombie? Stop updating the zombie artifact.
  • Put a note in the artifact that updates no longer occur
  • Note: What you think is not used may be, so be careful in applying this, and do so in stages

Raise Zombie Artifacts Refactoring

  • Just because it is a zombie doesn't mean it couldn't be useful
  • Integrate the zombie artifact back into the process
  • Often, the result of incomplete attempts at fixing the process

Integrate-Tool Refactoring

  • Take the existing method and support it with a new tool
  • E.g., writing test cases
  • Since the method is in use, motivation to develop/purchase/integrate the tool exists
  • Avoid the "exercise machine" syndrome

Move to a Standard Tool Refactoring

  • Versus custom tools
  • E.g., Generating a website
  • Previous process: HTML templates, XML data files, XSLT transformations, using xmllint and xsltproc with custom Makefile on the department server
  • Current process: HTML templates, Markdown data files, Jekyll, Liquid, on GitHub Pages
  • Standard Tool advantages: …

Bug-Tracking Refactoring

  • Put bugs and requests into a bug-tracking system, e.g., GitHub Issues, Trac, Bugzilla
  • What is the difference between a bug and a feature?
  • Recording the history of the project is useful for later analysis, determining credit, and examples for other projects

Close-Access Refactoring

  • Reduce who has access to a particular artifact
  • Both read and write access have to be considered
  • Towards a "need to know" basis
  • The first step in improving security
  • May require Format Refactoring

Open-Access Refactoring

  • Open access to an artifact that was previously closed
  • Allow read access to an artifact, e.g., bug reports
  • Allow write access to an artifact, e.g., allow users to comment on bug reports
  • May require Format Refactoring

GUI to Command Refactoring

  • Take something you do via a GUI and find a command-line equivalent
  • E.g., Use curl to download a file instead of via a browser
  • Why? Command-line tools are easier to share, remember, and automate
  • Why? Often many more options than shown in the GUI
  • This applies to all platforms, e.g., PowerShell

Add Automation Refactoring

  • Automate something that you do manually
  • Each use saves time
  • Each use ensures proper practice
  • Tools: shell aliases, shell functions, text expanders, Makefiles, Continuous Integration tools, …