Reflecting on Software Metrics


Reflecting on Software Metrics

 

At the risk of sounding pedantic, I like software metrics. They can prove to be invaluable in analyzing source code. To be clear, I am not proposing that developers be bonused based on metrics and their use in estimating and scheduling should be limited at best. I am however a fan of software metrics as benchmarks for evaluating design and understanding how software works.

There is an add-in for reflector called CodeMetrics that allows you to easily calculate a wide range of code metrics from within Reflector. We are most interested in one metric, Cyclomatic Complexity.

Cyclomatic Complexity or CC is the number of logical paths through a piece of code. This can be used to define a lower bound for the number of test cases needed to ensure proper coverage in unit testing. This can also be used to predict ongoing maintenance costs and be scaled to predict the likelihood of actually resolving a particular defect or introducing additional defects.

Tables similar to this are common:

CC

Testing Requirements

Ongoing Maintenance Costs

Resolution Likelihood

1-0

A simple procedure

Low

High

11-50

Complex

Moderate to High

Medium to low

>50

Very Difficult

High Risk

Low

The actual bands may vary depending on the line of business and skills of the developers involved, but these are generally good benchmarks.

A CC of 10 would indicate that 10 test cases are needed to fully test all of the functionality. Depending on what you are working on, that may be more complex than you want to consider or that may still be fairly trivial. As a general rule, I try to keep methods below 10.

When I am working on existing functionality, I try to review the code and refactor the code in the same module with the highest complexity, systematically reducing the overall complexity. Sometimes the best you can do is to review the more complex functions and add comments on how they may be refactored. Often times, the actual refactoring may be out of scope for the change that got you involved in the first place.

It is important to review the complexity of any code before making code changes. If you are about to change code that already has a high complexity, you want to make sure that your changes do not add more complexity. You need to be aware that with higher complexities comes a higher chance of introducing new defects and you are also less likely to resolve the underlying defect if it is embedded in complex code. This may change your estimates and should change your testing strategy.

Sometimes, complex code masks cohesion problems. If the code is very complex, there is a good chance that the particular method is trying to do more than one thing. If it is doing more than one thing, than simplifying the code may be nothing more than separating all of the different tasks that the method is trying to do. For example, code is often complex because data validation logic is blended with business logic or data mapping logic is blended with business logic. Simply pulling all of the data validation logic to a separate method and all of the data mapping logic to a separate method and isolating all of the business logic to a single method, you end up with several methods each of which is less complex than the original. Each of these methods will be much more cohesive. With cohesive methods, it is easier to know where to add new functionality or where to go when reviewing existing functionality.

Future blogs will explore some ways to reduce complexity.

author: Nick Harrison | posted @ Saturday, September 20, 2008 10:10 PM | Feedback (1)

Passive View and Cyclomatic Complexity



Passive View and Cyclomatic Complexity

We have previously talked about cyclomatic complexity and set forth the goal of keeping the complexity for our methods down below 10.   We have also talked about the goal of systematically refactoring any methods that we find to lower complexities whenever we make code changes.  These are good and admirable goals for business logic.

But what about Passive View?   Passive View is a slight variation on the Model View Presenter pattern designed to drive home the fact that the view should do very little processing.   The view should be passive.  Quiet literally the only code found in the view should be the implementation of the properties and the event handlers for the UI components.  The properties should do the absolute minimal to interact with the user, and the event handlers should simply forward calls on to the presenter.

I cannot stress this enough, there should be no actual logic in the view.

The driving force behind the Passive View pattern is to simplify testing.   Since it is harder to test the UI and the UI does not lend itself to automated testing, we want to move as much logic as possible to locations that are easier to test, class libraries.   Testing aside, logic housed in class libraries is more reusable and can be shared across multiple UIs.   In fact, the automated tests simply become a new UI.

All that being said, any method in the UI should have a cyclomatic complexity of 1!

Yep!   You heard me correctly.  One!   If you find yourself writing a method, event handler or property in the UI with a complexity greater than one, stop and ask yourself why whatever logic you are implemented is in the UI.   Chances are you will find that there is functionality that should be moved to the Presenter or a shared UI component.

I challenge everyone to identify UI code with a complexity greater than 1 that cannot be moved out of the View.   Note that I said out of the View and not out of the UI layer.   There are times when true UI processing may require some logical processing, but these are not so specialized that they cannot be removed from the View.

 

 

author: Nick Harrison | posted @ Saturday, September 20, 2008 10:04 PM | Feedback (1)

Pronouns



Using Pronouns

This may not be very technical, but hopefully it may generate some discussion and provide some insight.

Pronouns can be very enlightening about our attitudes towards work.   How long do you work for a company before you start thinking of the company as “we” instead of “they?”   Consider:   We are the number 1 producer of product X.   Vs.   They are the number 1 producer of X.   Do you ever make that pronoun switch?   What does it mean if you switch back from “we” to “they?”    What does it mean if you never make the switch?   Are you even aware of which one you use?

The dynamics with interpersonal relationships are also interesting.   Have you ever noticed that a single co –worker will probably say “I” or “my”, or “me” a lot.    A co- worker married or at least in a committed relationship will be much more likely to say “we” even if their partner is not with them.   What should we make of this?  : )

Of course you also get this with team dynamics as well.  A strong team player will frequently refer to “we.”    In this case, “we” probably refers to the team.   We are falling behind and need to catch up.   In a strong team, “I” rarely makes an appearance.    Hopefully, “you” is scarce as well.

I have also noticed something interesting with my wife that I thing is somewhat common.   The switch from “our” or even “mine” to “your” when we get upset about something.   I notice “our” dog becoming “your” dog when the dog does something bad.    Is this common?   Does it show up in other areas of life?    Do “our” processes become “your” processes when we feel like the processes don’t work?   Would such switches be a Freudian slip, malicious behavior, or a harmless word game?   Are we even of it when we make such switches?

So your use of pronouns can be used gauge the ties you feel towards your employer, your team, and your partner.    Here are some of my thoughts:

·        When your employer becomes “we” as in “We have a good work environment” instead of “They have a good work environment”, you finally feel like you are part of the corporate culture.
·        Should you go back to thinking of your employer as “they”, you may be feeling a little disenfranchised or disconnected.   Consider, “They have a strong business model” instead of “We have a strong business model”
·        If you never think of the company as “we,” are you perpetually disconnected looking in on your co-workers from the outside?
·        When you meet someone and they keep referring to “We went to the movies over the weekend”, chances are that person is married.    If your new friend states that “I went to the movies over the weekend,” you may have a new single friend.
·        When your team mates start referring to “we” as in “We have a good sense of the project timelines”, you probably have a strong team.   As long as you are still thinking in terms of “I think I know what needs to be done”, your team probably hasn’t truly formed yet.  Or maybe it is still “storming”
These are not hard and fast rules.   These are probably not even generally guidelines.   These are simple observations that I have made that seem to be true often.

Without a doubt there are many exceptions.   Most of us choose our pronouns without even thinking about it.   If we start thinking about it too much, we will probably throw the whole system out of balance, but a little self reflection is a good thing.

author: Nick Harrison | posted @ Saturday, September 20, 2008 10:03 PM | Feedback (1)