Treat feature access as data, not code

If you've worked on a software project for any length of time, you've seen requirements change. It's a simple fact of life. No one is "at fault", it's just the reality of building software.

Recently, we worked with a client to launch a new feature to their users, and the original direction was that only privileged users should be able to administer this feature. Other users could interact with it in limited ways, but they could only work within the constraints set by the privileged users.

I'll be honest, right from the beginning we suspected they would later change their mind. But instead of pushing back or trying to predict the future, we built the feature as requested, but knowing that we could easily change it later.

Why were we so confident about the potential future change? Because we build roles and permissions into the application in a very disciplined way. We treat permissions as data, not code.

So when rolling out the feature, we created a granular set of permissions related to both using and administering the feature. And initially, we only assigned those administration privileges to one or two administrative roles.

Then, throughout the code, we only gated access to the administration features based on the presence of the permission or not. We never refer to roles again. No other assumptions were made. The code was entirely data-driven.

As you might guess, since I'm telling this story, sure enough: the requirements did change a few months later, and they wanted to open up the administration features to a wider group of users. How much work did this take?

It was literally a single database migration. That migration simply added the permissions to the additional role, and that was it. Not a single line of code in the application changed.

The discipline of keeping that clear boundary line between roles and permissions, and only using permissions to control access, is something we've seen pay off time and time again. And if you're wondering why we didn't provide a user interface to manage roles and permissions, we've already discussed this on our podcast.

Here to help,

Joel

P.S. If you enjoy reading these tips, I'm sure you would enjoy being a part of the Mastering Laravel community.