Our .NET web application has the ability to add roles dynamically and assign functionalities (we define them in an application enum) to that role. So those functionalities are defined by us (our client) based on his business requirements. Some of them can be really specific and it makes the code really unmaintainable and there is no possibility to have something generic in our application.

So my question is what are the main reasons other than the current code approach is unmaintainable which i know is a big reason not to go with this but i am mostly interested in reasons that can be understood by someone that is not familiar with the technical aspects of programming.


Begin with the domain requirements

Forgetting about why you don't want user-roles and the associated permissions to be dynamic, you need to approach this from the perspective "what does the business/user need".

So, ask yourself:

  1. Does this business have finely grained permission-rules? This is usually true for companies that handle high-sensitivity information; e.g. banks, any organisation with large turnover or a large workforce, etc.

  2. Are permission-rules highly free-form or are they applied from a consistent set of a rules? i.e. does the person's job title dictate their permissions or does it vary from project to project or file to file, et al.


This is a discussion you should have with the business/software owner. During the discussion forget about your implementation concerns, just talk about what his/her company needs.

Then look at implementation

You need to implement the domain requirements of your software in the best way possible for your circumstance. Ideally, you will be able to define a set of user-roles that assign basic permissions and then allow some dynamic permission assignments where needed on-top of that.

If you still can't find a way to implement it without an extremely difficult-to-handle code-base, then simply put the decision back to business/software owner:

"I can either implement your current domain rules as we discussed or I can give you a simplified fixed role-based system. The implications of this are: more development time, more expensive maintenance, etc. What do you want to do?"

Try to keep the discussion to things they will understand; approximate relative lead-times, associated costs, etc.


The simple point is that you cannot make business rule decisions (such as how permissions are assigned) due to an implementation concern. Either model the rules as they are or explain the business-case for changing them; that is, why you think it is in the business's interest to simplify the permission system.

  • 2
    +10 for your last paragraph: business concerns always trump implementation concerns. And never assume that high development costs are prohibitive. The business may well be more than happy to pay the extra implementation cost. Developers often don't have enough information to figure out the actual cost/benefit of features. (They usually see only the costs.) – Marjan Venema Mar 7 '16 at 7:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.