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
Note
- 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
- 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
- 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
- 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
- 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, …