Having a great user experience is a desirable goal, but is not a necessity. There are always going to be situations where the UX needs to be compromised. The first and perhaps most common situation is team evolution.

As the team evolves and becomes more experienced with Go, it will inevitably find that some early software patterns no longer seem as effective. These might include things such as the use of global, panic, and loading configurations from environment variables, or even when to use functions rather than objects. As the team evolves, so does their definition of both good software and what is standard or intuitive.

The second, and in many cases, an overused excuse for poor UX, is performance. As we saw in an early example in this chapter, it's often possible to write faster code, but the faster code is often harder to understand. The best option here is to optimize it for humans first and then, only when the system has proven to not be quick enough, optimize it for speed. Even then, these optimizations should be selectively applied to those parts of the system that are shown, by measurement, to be worth the effort to refactor and the long-term cost of less-than-ideal UX.

The last situation is visibility; sometimes, you just can't see what a good UX might be. In these cases, the more effective option is to implement and then iteratively refactor based on usage and any inconveniences that arise.