What If ''Rules'' Applied In Our Daily Efforts?

Being a casual fan of professional sports, I probably favor (United States) football and hockey over any other options available to me. At this point in the National Football League (NFL), the final teams are gearing up for the "big game" to determine who is the champion for the season. I hesitate to say "world champion" since this is a statement that I have never understood. I mean, what other countries are actually participating this season?

At the heart of any sport, is a collection of rules. A rule book. Albeit quite involved, the goal is to establish guidelines for the sport and provide a central point where competitors can comprehend what is considered legal play and what is considered an infraction.

I began to wonder, what if our careers as Information Technology (IT) professionals were governed by a collection of rules?

Rooney Rule

The Rooney Rule, in the NFL, is a "policy that requires league teams to interview ethnic-minority candidates for head coaching and senior football operation jobs." Since the adoption of the Rooney Rule was put into place in 2006, the number of ethnic-minority coaches has increased from 6% to 22% for head coaches in the NFL.

Over the years, I have encountered corporations that are minority-owned, which has allowed them to receive special attention when dealing with state and federal agencies. Ironically, those whom I encountered from those agencies were not actually minorities. To me, this seemed like a non-minority group gaining an unfair advantage by utilizing a corporation that was noted as minority-based.

With this in mind, if I were to imagine the adoption of the Rooney Rule in Information Technology, I could see the following rules being defined:

• 25% of all software licensed must be licensed from minority-based corporations

• 25% of all consulting engagements must utilize minority-based corporations

• 25% of all hardware purchased or leased must be from minority-based corporations

• 25% of all cloud-based solutions/licenses/subscriptions must utilize minority-based corporations

• Any project that is out for a request for proposal (RFP) must receive a bid from at least two minority-based corporations

In all cases, 90% of these minority-based corporations must employ minorities.

Taking this approach, the goal of the Rooney Rule would be recognized — giving minorities more presence in the IT industry.

However, the challenge with this approach is finding minority-based corporations that can truly compete with software, hardware, cloud, consulting and project-based entities which are not minority-based and have market-leading solutions and services. At the same time, corporations will find themselves at a competitive disadvantage (at least in the near term) from global entities which do not have to abide by such a rule.

SOx Compliance Extensions

In my "Taking Your Company Private?" article, I talked about the price to adhere to Sarbanes-Oxley (SOx) compliance and how one public company I worked with considered taking their corporation back to private status. In the end, the realization was made that the requirements for SOx compliance were good practices that should be been followed regardless of the status of the corporation.

What if SOx compliance was amended to require that any custom program logical maintain at least 90% coverage from unit and integration tests?

This would cover not just traditional program code (C#, Java, JavaScript, etc.), but even business logic buried inside macros within programs like Microsoft Excel.

Just considering traditional program code, I have encountered interesting results with unit tests alone:

• Unit test exist, with impressive coverage (< 10%)

• Unit tests exist, with low coverage (10% - 50%)

• Unit tests exists, but disabled (due to errors) (5% - 10%)

• Unit tests do not exist at all (10% - 30%)

The number of true integration tests that I have found are significantly less, even if existent at all.

Most of the time, the reason I receive when I ask about unit and integration tests is that projects often fall behind schedule. In order to meet the deadline, creation and maintenance of unit/integration tests are often taken out of the project.

One big challenge I encountered was during a project I worked on for a State agency. I was part of a small team that was rewriting an accounting module. Each team member relied on another's work. Since we started at the same time, we decided to use unit tests to mock up what we would receive in order to start our development.

Taking this approach was nice. The happy path, alternative path, and exceptions could be validated well before we were fully completed with our effort. Life seemed grand and the unit tests were a huge help.

Then, we discovered that some of our requirements were not being interpreted in the right way. The corrections caused changes with the programming and model objects that were being passed from each section of work. As a result, every one of the unit tests was now failing. Ahead of each of us was the task of correcting all the unit tests so that they were functional again.

We were fortunate to be able to resolve the issues prior to the deadline for the module, but this situation provided me with a real-life example of how the breakdown of unit tests (noted above) can become a reality.

Penalties

In the sections above, I provided a couple of examples of how rules could be applied to IT.

I am pretty sure that every rule book has space allocated to handle infractions, or consequences, when rules are broken. The challenge with the implementation of IT-based rules is to establish some form of penalty when the rules are not adopted.

Since SOx compliance relates to publicly-traded companies, there is a natural mechanism for corporations to stay within the guidelines. Failure to do so will lead to a report being made public, which could impact the price in which the entities stock is traded. If the situation became severe, the company could be delisted from the public exchange in which they participate.

However, implementing the Rooney Rule might be tougher to enforce. One would think legal action, perhaps at a state or federal level might be enough to warrant compliance. But legal items simply could get lost in the mix — with out-of-court settlements lessening the impact from failing to adhere to the rules.

One might think that social media could provide a rationale to avoid failing to adhere to the rules. The downside here is that a majority of the customers are less likely to avoid the company due to a Rooney Rule infraction. Consider this example:

Company A loved their CRM provider. It was a proven, market-leading solution that allowed the sales team to reach increasing levels of customers and prospects year of year. The Rooney Rule was employed and required the corporation to consider a minority-based SaaS provider. The corporation's view was that their viability as a growing entity would take a negative impact if they were to switch to another CRM provider. In this case, customers of the product loved the product they were offering and really didn't care that they leveraged a market-leading solution to reach more consumers.

The only drawback that could face the customer is if prices were to increase as a result of legal action to defend adherence to some rule. This would more likely than not, cause the consumer to be dissatisfied with whomever enforced such rules — standing beside the company under fire.

Conclusion

I mentioned the NFL at the start of this article, as an introduction. This was by design, as both games leading into the season finale were faced with issues around the rules of the game:

• One game's overtime rules did not allow one team (that fought hard to tie the game) a chance to continue scoring points, leading to an unfortunate loss

• The other game's lack of enforcement over a blatant infraction caused the losing team an opportunity to win in the final minutes of regulation

While no game should be decided by infraction or non-infraction of a clear penalty, my point here is that no rules system is perfect. There is always an exception to every rule, just as we program exceptions in our logic. Unfortunately, defining rules for exceptions becomes an exercise of dealing with situations that occur rarely — often without a clear basis on what the correct resolution should be.

I feel the same situation would apply when attempting to define rules for the IT industry. Trying to establish a Rooney Rule would currently lead to a competitive disadvantage based upon the current state of solution and service providers. Trying to enforce new requirements to SOx compliance would increase project costs — especially as business rules and requirements change over time.

For now, it is probably a good idea to leave things as they are. I don't suspect the same will be true with the NFL and their rules committee.

Have a really great day!