Licensing Overhaul - Return of the Designer

contract In case you missed parts one or two of the series you can find there here: Part 1- A New Challenge, Part 2 - The Whiteboard Strikes Back Welcome back to the series on Licensing Overhaul! Last time we witness the rise of a new system, and discussed the gritty details of some of the more important components. This time we will review our journey, and focus more on some realizations brought on by hindsight. To summarize, my PM wanted to change what some of the existing Licenses allowed our users to do. So I spend some 6 weeks digging through the old jungle of code, and developed a simpler, and in my opinion cleaner solution. Last week, I went into detail about this design. This week I plan to cover the benefits that were realized in the design as well as some of the foreseen drawbacks. I will address the drawbacks first. Every decision made in a design naturally chooses a set of advantages and disadvantages to take for the software. My new licensing system is no different in this respect. While the design supports a great number of data types to query, it is somewhat weak in this area. Specifically the performance of the query may be adversely affected should the number of datatypes be greatly increased. Thankfully, the number necessary would be very great indeed. Each License would need to support something on the order of 10,000 different data types before any notable performance hit would be noticed. This weakness results from the License Checking each ObjectType for its data type. This could be easily fixed if the License were to use a data type to Permissions dictionary rather than a simple list. However time has not yet been allocated to for this change, and the solution was not discovered until after the project was determined to be complete. In a similar way, the number of Licenses may also present certain challenges. Since each License is queried for each permission request, if the number of different licenses checked out by the system should increase greatly, it would also negatively impact the performance of the query. Again, the number would need to be very great, on the order of 10,000. However, the number of License checks has a multiplicative effect on the ObjectType check. As a result, it would probably be best to spend the time to fix the ObjectType rather than the License check bottleneck, as this would offer greater improvement between the two. So much for the weaknesses of the design. Now on a happier note, the design has several strong benefits, some were realized very early on in the implementation, while others became apparent towards the end. I will start with the one which became obvious while I was implementing this change. Perhaps the most long lasting of the benefits for the new system is that it was built to support incremental changes! The new system did not completely replace the existing License checks, rather it came in along side them and took over a select few. By doing so, the scope of responsibility remained manageable during implementation, and it only touched what it had to. This benefit was by far the biggest in terms of controlling scope creep. The next benefit became obvious as I drew to the end of the project. By that time, the accumulation of permissions knowledge grew to such a size that it was easy to see the patterns of allowance by the licenses, at least for the affected area of data. Since we now had an aggregation of the License permissions knowledge, future changes to said permissions are much simpler. Rather than having to dig through many thousands of lines of code to replace the various license checks, one would need only change how the License Object was created in order to implement the desired change. To cap things off, I realized that there was one further benefit that could be realized. However this will likely not be until the remote future. At present the Mediator relies on the Manager to determine what Licenses are checked out. Presuming that any replacement manager implements the same interface, it can easily be swapped out when the time comes. And with the code base gradually moving towards C#, it seems that it may be inevitable, albeit sometime in the next 20 or more years. All in all, this was a very enlightening project to be allowed to work on, and very rewarding for the chance to implement a system which may one day widely affect the application in the future. Naturally there are some optimizations that I could chosen had I been thinking about performance, but it has been said that premature optimization is the root of all evil. As always, I thank you for listening and I welcome your thoughts and comments! Let me know if you think of any ways to improve the design, I would really enjoy such a discussion! And until next time, good luck and God bless!