It’s been a while since I have posted here, mostly because we are busy building things at Okta. In the past while I have been building our UI framework and generalizing UI components, and thought I should share some high level bullet points of my experience.

1. You are building a framework

Unless you are building a small website, no matter if you’re using backbone, angular, ember, react, vanilla JS or whatever MVC framework the cool kids are using nowadays, in order to have a consistent user experience, without a significant amount of copy/paste boilerplate code, you need to have a solid framework layer. It’s easy to think (as I have) that “we are focusing on building a great product, not a framework” and it couldn’t be more true. However, in order to build a great product, you need a great framework to support you. The investments we made in our framework turned to be a key component in enabling us to move fast, without compromising quality.

2. Abstracting 3rd party widgets is probably a good idea

No matter how stable and mature your 3rd party dependencies are, and how great the developers are, APIs change. By abstracting external dependencies you gain the flexibility of upgrading even a major version, without refactoring a large amount of code. The best way to avoid major refactoring when that happens, (or to get stuck on an older version), is to have your own internal layer of abstraction around it. After all, it’s a know fact that all problems in computer science can be solved by another layer of abstraction except for the problem of too many layers of abstraction.

3. Documentation and code review help spreading the word

It’s really awesome to be generalizing code and writing frameworks around common patterns, but it doesn’t help a lot if the other developers in your org are not aware of it. We’ve found that the combination of code review, and a centric doc site help a lot with training and exposing what features are available. A rotation between developers to help extending the framework is a win win as well: developers get to better know the framework and it’s internals, while the framework gets more contributions.

4. Tests are crucial to success

As any large software application, it would have been impossible to maintain our application without a good amount of tests which validate that:

• The code does what you think it does
• Side effects are easier to catch.
• Future development can be done (in less horror)

Our UIs have proven to be incredibly stable when it comes to regressions, and this is mostly due to our investment in unit tests and end-to-end tests.

5. Cleaning up after generalizing is a good idea

Typically, we decide to generalize a pattern after we are sure we will use it more than once. This way we can assure we are generalizing the right thing, and not what we assume is the right thing. In order to keep the codebase clean and honest, its important to go back to the previous implementations and apply the new pattern. This solves two main problem:

• It assures that we correctly solved the problem
• It assures that the next developer running into the same problem will not copy/paste an obsolete/one-off solution

6. You are, by definition, writing tomorrow’s legacy code

It’s impossible follow trends and rewrite your whole application using the new shiny framework that pops up every other week (Heck, The angular 1.x app you wrote last year is considered legacy code today). Instead, we focus on choosing tools that promotes practices we have learned to be useful, with current technology. With the pace the industry is moving forward, future challenges are likely to be along the line of “how to stay current”. There’s no answer to that challenge, but modularity has to be a key component.

If you want to be working with a company which faces these sort of challenges, We are hiring!