The most frequent question we receive about Neches is “What does my score mean?” or “What is a good score?” To explain this I would like to help understand how we arrived where we are, and our future plans for the Neches score.
What is the goal?
The goal of Neches is to help you create BPM solutions that are easy to maintain and modify. All of the current rules highlight things that, if you ignore them, will make creating version 1.1 (or 2.0) of your process significantly harder to deliver. We believe that following incremental review of your Neches score will make your deployments less risky and easier. Not all of these findings can be avoided. BPM solutions can be quite complex. Neches aims to uncover where this complexity exists in your solution so that you can assess if the identified issues can be avoided or are a necessary evil in order to meet the business requirements of the solution.
How does Neches Scoring work?
Think about a Neches score essentially like a golf score - lower is better. Effectively what is being done is points are being added to your score for every Neches finding in your report. The number of points added depends on how far beyond the threshold for low / medium / high measures of the metric being used. Additionally each rule has a different amount of points for these thresholds reflecting how important our team feels the rule is in helping achieve the Neches goals.
It is very important to understand that it is virtually impossible to deliver a meaningful BPM solution and receive a Neches score of 0. The goal is not to get a “perfect” score, but rather to look at the items that are contributing to your score and determine if the “risk” of implementing the solution in this manner is appropriate. Again the risk is really attempting to articulate items that might be difficult to understand, modify, or maintain.
Awesome…. So….. What’s a “good” score?
There is no absolute “good score” in Neches. Really only you and your team can determine if your score is appropriate to what you are trying to accomplish. We would like to see the Neches findings being used as the launching point of code reviews prior to or immediately after each playback. Focusing on the items contributing the most points, in a team review, will hopefully yield some or all of the following outcomes -
- A better understanding by the entire team of the most complex portions of the solution.
- A technical debt “punch list” of items the team agrees are overly complex and should be re-worked.
- A better understanding by the entire team of how their choices will effect the stability and maintainability of the solution.
- Avoidance of the worse coding practices in future development work.
I got all that. Now really what is a good score?
We knew everyone would want to know that. Originally we capped the possible Neches scores so that the topped out at 999. However the problem was that there was no good way to differentiate between a score that was barely over that threshold from one that triggered the rules 5 or even 10 times more than that. As of January 2017, we removed this hard cap and allowed scores to be unbounded.
To compensate for this we've added a new measure "Community Rating" that attempts to find the other solutions on the server most similar to yours in terms of the counts of items in the export. We then show you how you match up against the 10 best matches to the nature of your solution and give you your percentile rank.
With the scoring that is in place today everything you add to your solution has the “opportunity” to add Neches points to your score. This necessarily means that a solution with only 2 BPDs and 100 services will likely have a much smaller score than one that contains 40 BPDs and 1000 services. What community rating attempts to do is compare solutions with ~40 BPDs and 1000 services to other ones of approximately that size and solutions with 2 BPDs and 100 services to their peers as well.