Why our software never returns warnings

We at SSOReady spend a good chunk of our day talking about pretty minor product decisions. I mean stuff like should this button say ‘Done’ or ‘Close?’ For a company of our size (i.e., not very big), details like this might seem pretty tedious, maybe inconsequential – but we think it all adds up.

As we make decisions, we tend not to rely on firm rules. We basically improvise. We figure it’s best at our stage to make judgment calls. If we’re wrong, the thinking goes, we can reverse course pretty easily. After all, we’re still small enough that we get direct feedback from every single customer.

However, we have developed at least one firm rule: our software never returns warnings to developers. We enforce binary outcomes. Either the behavior’s exactly right or it’s a full-fledged error.

Here’s one example to illustrate what I mean.

Our SAML single sign-on product allows only two states for SAML responses. A login may either have Succeeded or Failed (for an attempted login to remain In Progress indicates the absence of any response from an identity provider). By choice, we have no way to float warnings to our customers.

We’re borrowing this design choice from the Go compiler, which similarly never reports warnings. That behavior has at times inspired frustration from developers, because it means the Go compiler returns errors in places that other languages wouldn’t. You can’t just have unused variables, for example. Go’s FAQs share more on the reasoning.

We think this is the right approach for our product for basically three reasons.

First, warnings give us room to be lazy. Great product teams take care not to pass too many decisions onto the user. Mediocre teams ship lots of stuff and leave the user with a sea of nested menus and esoteric settings to fiddle with. We see this in big companies with fragmented decision-making authority. Their products just get increasingly indecisive, bloated, and confusing. It’d be too easy for us just to say ‘yeah, idk, add a warning when that happens.’

Second, we have to help our customers feel comfortable and confident during implementation. Most developers don’t really know how authentication works. We most commonly partner with customers undergoing a SAML/SCIM implementation for the first time. Above all else, our product exists to guide our users to the right outcome, so we’re just not doing our job if we introduce ambiguity. At no point can we say ’this thing could be bad, but you need to decide.’ That undermines our value proposition.

Third, security is paramount. We have to do everything in our power to protect our customers. If there’s any chance that a customer’s implementation looks unsafe, we have to be aggressive in enforcing failure. We have to constrain the universe of acceptable behaviors solely to things that we know are safe.

In short, we’re choosing to be opinionated. We’re consciously giving our customers pretty minimal discretion, because we think it’s the right product experience.