#server density

What Rough Edges?

The Server Density UI definitely has some rough edges. This isn’t something I’m embarrassed about; instead I prefer to be honest about these things so they can be addressed.

CSS: We have one CSS file that is over 5000 lines long. It hides plenty of dead CSS, and it is very difficult to work with. It also contains far too many uses of !important.

Backbone Views: Our old Backbone views tend to contain UI elements that aren’t usability tested, are less composable and less performant than their React counterparts. In our codebase, Backbone views tend to not have unit tests, whereas our React components always do.

Backbone Models: Transitioning to Redux means we are in a phase where we have redux code that duplicates Backbone Models/Collections. Fixing this duplication would lead to less loading states as data fetched for one page is easily shared with another page.

Improving the situation

If we recognise these rough edges (and we should) we should start to think about what to do about them. How do we know it’s a rough edge? How do we know if it’s getting better? How do we measure it?

If it’s measurable we can track it over time, but how? At Server Density we use simple scripts like measure React component re-use to track 4 areas of the codebase every month:

Asset file size: This is more about how much duplicate or dead code we managed to remove. Byte counting is not that useful but removing dead or duplicate code is.

CSS health: Our new CSS is composed of little files where each file has 1:1 mapping to a component and a very specific namespace. Our old CSS is a very large file, a lot of which can probably be deleted. Plus, our old CSS uses !important too much and has weak namespaces or selector depth that is too deep.

Component reuse: This is about how generic and re-usable our components are, which is about productivity and UI consistency. This read-me is a good overview.

Backbone views: How successful we are at removing Backbone views in favour of more usable, more consistent, better tested, more composable React components.

Every month we measure these stats and add them to a spreadsheet, which allows us to compare where we are this month vs last month.

Does this work?

Sometimes it’s easy to see a benefit. Prior to monthly stats the CSS file-size was increasing, but now it’s decreased every month for 10 months by 27% overall. The important point here is the amount of dead or undesirable code that has been removed or replaced and how much easier the CSS is to work with now.

Tracking JavaScript file-size has also been positive. After 10 months of monitoring, the file-size is roughly the same. Pretty good considering we ship code almost every day, and have released major features like alert costs in that time. Again, the file size is not the important point, it’s the increased composability and the removal of dead code that this indicates which is important.

Other times it’s harder to say. Component composability has increased, and anecdotally this has improved productivity because new features have comprised mostly of pre-existing code. However, I can’t say if this would have happened without the stats. I also think focussing too much on further increases would make the codebase too tightly woven.

The danger inherent in focusing too much on instances per component reveals some interesting take aways from monitoring stats like these:

Stats should be a way to tell the story of a code-base, and should not be the end goal.

Stats should be taken with a pinch of salt.

The stats you monitor might have to change as a code-base changes.

Stats need to be really specific to the codebase. Stats that are valuable for one codebase might not be valuable for another.

React

Almost 3 years ago we took the decision to switch to React. This has substantially improved the lives of our developers and our customers:

Because components are a function of props and state, they are easy to unit test. This opportunity allowed us to enforce unit tests at the view layer for the first time, making the UI more robust and less prone to regressions.

Because components are much quicker to implement than backbone views we had more time. This led to two new policies; new functionality must be usability tested and new functionality must support keyboard controls.

Because components are so much more composable than Backbone views we had a real opportunity to improve productivity and user-interface consistency. To make sure we were doing this we started to measure component re-use and document generic components.

These opportunities have proven to be huge wins for improving productivity, reducing regressions and improving usability.

However, there have been costs; the time it takes to convert backbone views to react components, the extra complexity of maintaining two very different approaches within one codebase, the cost of implementing bad components due to relative naivety and learning React.

In this case was the cost worth it? Yes, absolutely. But that doesn’t mean the cost is without consequence, in fact I expect us to be dealing with these costs for many months/years to come.

Redux

Recently we’ve taken the decision to move our data layer from backbone to Redux. Redux’s opportunities are:

Debugging how data changes over time is now much simpler thanks to immutability and tools like redux debugger

With Backbone (in our codebase at-least) each view instantiates the data it needs. This means different views will often fetch the same data multiple times as a user navigates the app. With Redux, after the first fetch, data is always available. This means the user should only ever see a loading state for specific data once, rather than several times.

Still there is a cost: We now have redux code duplicating backbone model/collection code, we’ve had to add seamless-immutable to our codebase, initial development has been slower (but is speeding up), and we’ve had to figure out how to hook backbone events to Redux action creators (eww).

Will this cost be worth it? Yes, eventually, mostly because we will be able to remove so many loading states from the app and massively improve user experience. But this will take many months/years to be completely fulfil and in the mean time we’ll be dealing with the costs.

Why does this matter?

I think using opportunity and cost as a framework for making technical decisions is important. Think:

What are the opportunities?

How long until we realise these opportunities?

What are the costs?

How long until we pay back these costs?

How can we measure if we capitalise these opportunities?

Do the opportunities substantially outweigh the costs?

Hindsight is a wonderful tool. It can and should be used to judge past decisions to improve future decisions.

At Server Density we used Backbone for 2 years without upgrading to any of the more advanced variants like Ampersand.js and Marionette. All that time I wondered whether upgrading would be worth it, but with hindsight I’m glad we didn’t. If we had upgraded we’d still be dealing with upgrade costs as well as the costs of switching to React & Redux.