1. The ramp up time for new engineers is too long.
2. The ramp up for new hires is too taxing on existing engineers.
3. We have a team of engineers who have little or no background with Angular.
4. Style regressions make it into production.
5. Functional regressions could (do?) make it into production
6. The QA process is too manual
7. Any engineer that touches a view must deal with HTML/CSS/Accessability/BrowserSupport/etc.
8. Tying yourself to a specific tech stack is dangerous due to the rate of change
9. Changes to UI components are inevitable
10. The entire company needs access to our design decisions
11. Customers should have a consistent experience when interacting with the Terminus brand.
12. We have a team of engineers who have very little exposure to things like accessibility.

(problem) solution

• (1|2) Automated documentation (TS/SCSS)
  • Engineers need only to comment their code as needed
• (5) Unit tests
• (5|6) End to End tests
• (5|6) Integration tests for the UI library
• (7|8|9|12) Completely custom components (<ts-button></ts-button>)
  • No HTML/CSS/etc written 98% of the time
  • Enforce our design patterns (i.e. don't expose the option to change button padding)
• (3|7|9|11|12) Separated UI library
  • Completely change the implementation of a feature without updating code throughout the core app
• (8) Explicit structure for styles (OOCSS/BEM)
  • Changing the encapsulation of an Angular component doesn't break styles
  • Porting to another system doesn't require changes
• (4) Visual regression tests
  • Make sure all style changes are expected and desired.
  • Alert other teams when a substantial change is being released (e.g. CSMs are notified when a change to our datatable structure/style is being released)
• (10|11) Formalizing a style guide allows us to share the Terminus design language with the entire company and receive feedback on it.
• (1) Enforced coding style
• (4|9) Automatic semver releases allows UI updates to be opt-in