Nick Harrison

Show – Off always Shown up in Showdown

Nick Harrison — Wed, 29 Oct 2008 01:29:16 GMT

Show – Off always Shown up in Showdown

This was my fortune cookie the other day. It was attributed to Confucius. Now, I doubt that Confucius actually said it. The humor shines through only in English, I think. For the sake of not plagiarizing, let’s continue attributing it to Confucius. It reminds me of another quote that I heard a while back. This one attributed to a Buddhist monk “What I am I am and say not. Being is the great explainer”. We will get to this quote in a moment.

But first …

If you are a job candidate hoping to make it past the screening process, you may well feel like a show-off. Regardless of your personality, the job interview is not the time for modesty. The job interview is the time to say and with a straight face “Hey look at me. Aren’t I wonderful? Wouldn’t you like to have me working for you?”

If you are looking for a job, depending on how you find yourself looking, this can be tough. If you got fired (laid off, downsized, cost reduced, name your euphemism) such confidence will feel alien and fake. If you are miserable in your current job and casually looking around, you aren’t really motivated to put it all out there, and you can’t maintain the strong self confident image that you need to present.

Fake or uncomfortable, awkward or contrived, however it makes you feel, this is the façade that you have to put on to get the job.

Most of us technology geeks will more easily tend towards the Buddhist quote listed earlier. We would rather not have to toot our own horn. We would rather be modest and casual keeping a low profile and avoiding the spotlight. We try to live by the second quote mentioned earlier.

“What I am I am and say not. Being is the great explainer”. If you are a great programmer, it should be obvious if you are doing your job right. As a general rule, if you have to walk around saying, “I am great at this” or “I am great at that” you usually are not. More likely than not, you are an insufferable jerk. If you really are great, it should be obvious and you should not have to point it out all the time. This is a great philosophy for the daily grind.

Unfortunately, it doesn’t work so well for job searching. In a short interview, you flat out don’t have the time for “being to explain” what you are, must shine through quickly, usually in 30 minutes or less. If not, you may not get the rest of the time needed for being to explain.

So, if you are on the job hunt, let loose your inner braggart. Just me sure to be him back in the cage after you land your next great opportunity. If you are the screener, realize that the people you are dealing with are probably acting against their character and venturing outside their comfort zone. Be patient.

Thoughts on a Data Dictionary

Nick Harrison — Fri, 17 Oct 2008 01:21:41 GMT

Thoughts on a Data Dictionary

I have often thought about what would make a good data dictionary. Usually I have lamented the absence of any meaningful data dictionary beyond what the DBMS itself keeps on its own. If everyone would simply add comments everywhere that the database natively allows, we would all be oh so much better off. But alas we don’t.

As is so often the case, if we don’t have to do something, we probably won’t. Often times, it’s a matter of meeting deadlines, sometimes it’s a matter of shear laziness, but sometimes, it may just be a case of not understanding the need or not knowing what is intrinsically available.

Let’s tackle the need first…

Database objects rarely have meaningful names. Database objects with meaningful names to one group may not be meaningful to another group. When you are trying to learn a new data model, the history of this data model is useful to understand the conventions adopted or ignored.

In its simplest form, I have several goals for a data dictionary:

· Define the naming conventions followed
· Identify known exceptions to these conventions
· Provide an English description for each database object (table, column, stored proc, trigger, etc)
· Document the accepted data types and their purposes
· Identify known exceptions to the data type rules
In Oracle or SQL Server, this can all be accomplished with a relatively small word document and the native data dictionary.

I think though that to actually enforce these conventions, we need a little extra support:

· A Data Thesaurus
· A rule validator similar to fxCop
The data thesaurus would be used to ensure that appropriate naming conventions are used. Proposed object names would be split on a case change and run through the thesaurus. If the individual words are found in main line entries, you are good to go. If an individual word is found as an alternate, replace it with the main line entry and proceed. If an individual word is not found in the thesaurus, flag it for review.

Such a process would eliminate such confusing names as:

· ProcessDate
· ProcessDte
· Process_Date
The first name would work as entered. The second one would be converted to the first one, and the third entry would be rejected since Process_ was not found in the thesaurus. The key thing here is that it tracks and enforces the convention at the time of object creation not at the end of the process.

The above is one rule based on the data thesaurus. Other rules that may be useful might include:

· Insure that object names are not plural. Each record in the “Members” table is a Member
· Insure that each table name is a noun
· Ensure that every column is either a noun or an adjective. Columns should not be verbs
· Ensure that every table has an associated comment
· Ensure that every column has an associated comment
· Ensure that every stored procedure has an associated comment
· Ensure that stored procedures pass the thesaurus test
· Ensure that stored procedures have the form ActionObject, such as InsertMember or SelectMembersByGroupID
Or

· Ensure that stored procedures have the form NounAction such as MemberInsert or MemberSelectByGroupID

What are your thoughts on a data dictionary? Has anyone incorporated similar ideas into one? How did it work out? Have you thought about and decided against?

What Can We Do For Meaningful Variable Names?

Nick Harrison — Mon, 22 Sep 2008 23:43:42 GMT

What can we do for meaningful variable names?

You hear much about naming conventions and some shops still have some arcane rules in place. Fortunately most of us have stepped beyond Hungarian notation. I have seen some shops define rules that the method name should include the number of parameters. I have seen shops define rules that would ban overloading and insist on a sequence number for methods that should be overloads. I have seen shops that wanted the Requirement Number embedded in method names, and I have seen shops put maximum character size limits to simplify reading. This unfortunately led to awkward abbreviations.

None of these standards have led to more meaning variable names. The fact that a variable is an integer or a string does nothing for me. Having a method signature come like:

Public void int DoSomething (string strParam, int intParam)

does nothing for us. Having one like:

Public void int ProcessIncomingClaims (string branchCode, int transactionID)

Can be very enlightening.

Like legislating morality, none of these rules will guarantee that the names are good. At the same time, almost any set of “good” rules could still be applied and end up with “bad” variable names. We may not always know when a name is “good” but we usually know when the name is “bad”.

Enter GhostDoc. GhostDoc is a wonderful tool designed to help automate your comments. Caution it works best for C#, but they are building support for VB. The intention here is that GhostDoc takes your method, properties, parameters, etc. and splits them to come up with the documentation for that item. There are several thinks that seem to be happening here. First it splits the words at a case change. Second, it interprets methods as being in the form verb – object and will attempt to structure the comment like that.

For instance, if you have a method called DataBind (), GhostDoc will come up with the comment:

/// <summary>

/// Datas the bind.

/// </summary>

This is clearly not what we want for a comment. Note that the naming convention was not followed. We would want to have methods following the pattern of Vern Object. Here it is following the convention of Object Verb. Ghost Doc ends up with a comment that does not make sense grammatically. Now consider the comment generated for the method BindData ():

/// <summary>

/// Binds the data.

/// </summary>

Our method name follows the naming conventions that we have setup and now the generated comment makes sense as well.

Try it and you will find that whenever GhostDoc does not come up with a boiler plate comment, your variable names or method names or property names are probably not named well.

Not a bad litmus test for good names!

Just like Ghost Writers in the publishing world, there is only so much that GhostDoc can do. It does a good job of structuring your comments. It does a good job of mapping out the details needed for comprehensive XML documentation. It also does a good job brining in ancestor details when overriding from a base class.

It does not explain how logic works or why logic is needed. This you still need to add yourself, but at least you will know where it goes to produce in comprehensive documentation. The better you name your methods and parameters, the less you should have to write. The more highly cohesive your methods, the less you should have to write. The less you have have to write manually, the better your code can be understand without your comments.

Has anyone else used GhostDoc to help ensure naming conventions or help ensure that code is readable?

?

You hear much about naming conventions and some shops still have some arcane rules in place. Fortunately most of us have stepped beyond Hungarian notation. I have seen some shops define rules that the method name should include the number of parameters. I have seen shops define rules that would ban overloading and insist on a sequence number for methods that should be overloads. I have seen shops that wanted the Requirement Number embedded in method names, and I have seen shops put maximum character size limits to simplify reading. This unfortunately led to awkward abbreviations.

None of these standards have led to more meaning variable names. The fact that a variable is an integer or a string does nothing for me. Having a method signature come like:

Public void int DoSomething (string strParam, int intParam)

does nothing for us. Having one like:

Public void int ProcessIncomingClaims (string branchCode, int transactionID)

Can be very enlightening.

Like legislating morality, none of these rules will guarantee that the names are good. At the same time, almost any set of “good” rules could still be applied and end up with “bad” variable names. We may not always know when a name is “good” but we usually know when the name is “bad”.

Enter GhostDoc. GhostDoc is a wonderful tool designed to help automate your comments. Caution it works best for C#, but they are building support for VB. The intention here is that GhostDoc takes your method, properties, parameters, etc. and splits them to come up with the documentation for that item. There are several thinks that seem to be happening here. First it splits the words at a case change. Second, it interprets methods as being in the form verb – object and will attempt to structure the comment like that.

For instance, if you have a method called DataBind (), GhostDoc will come up with the comment:

/// <summary>

/// Datas the bind.

/// </summary>

This is clearly not what we want for a comment. Note that the naming convention was not followed. We would want to have methods following the pattern of Vern Object. Here it is following the convention of Object Verb. Ghost Doc ends up with a comment that does not make sense grammatically. Now consider the comment generated for the method BindData ():

/// <summary>

/// Binds the data.

/// </summary>

Our method name follows the naming conventions that we have setup and now the generated comment makes sense as well.

Try it and you will find that whenever GhostDoc does not come up with a boiler plate comment, your variable names or method names or property names are probably not named well.

Not a bad litmus test for good names!

Just like Ghost Writers in the publishing world, there is only so much that GhostDoc can do. It does a good job of structuring your comments. It does a good job of mapping out the details needed for comprehensive XML documentation. It also does a good job brining in ancestor details when overriding from a base class.

It does not explain how logic works or why logic is needed. This you still need to add yourself, but at least you will know where it goes to produce in comprehensive documentation. The better you name your methods and parameters, the less you should have to write. The more highly cohesive your methods, the less you should have to write. The less you have have to write manually, the better your code can be understand without your comments.

Has anyone else used GhostDoc to help ensure naming conventions or help ensure that code is readable?

Passive View and Cyclomatic Complexity

Nick Harrison — Sun, 21 Sep 2008 03:04:27 GMT

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.

Pronouns

Nick Harrison — Sun, 21 Sep 2008 03:03:16 GMT

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.

Why we Blog!

Nick Harrison — Wed, 05 Mar 2008 15:23:11 GMT

I was recently challenged by a very good friend that the contnet of my blog was only really clear to people who did not need to read it. His comments challenged me on several fronts.

Why do I post blogs?
Who do I believe my target audience is?
What do I hope this audience gets from the blogs that I post?

There are several reasons why I post blogs. Sometimes I post a blog so that I can quickly find something that I struggled to figure out in the first place. In this case, the target audience is myself, and I hope to make it easier for me the next time that I do something similiar. If others find something useful there, that is great, but they are not necessarily the target audience. I admit that these blogs are rare, or atleast I hope that they are rare. Probably more blogs are written with me as the target audience than I intend.

Sometimes I post blogs with the intention of giving back to the community and helping others have an easier transition in learning something new, or encouraging someone to venture into new technologies that they may otherwise be intimidated by. In such cases, the target audience is someone new to DotNet or someone who has not really explored much beyond what was needed to get specific jobs done. This is where I probably have failed my audience the most in the past. The content may not always be as readily accessible as I would intend.

Sometimes I post blogs with more of a "Look at me, ain't I smart" attitude. I am ashamed to admit that this is more common than I wish and probably leads to the problems with many posts not being easily accessible to who I believe my target audience is. I challenge anyone reading my blogs to help keep me inline. Just be nice about it.

My friend recommended a format that he thought would make the content more accessible to a broader audience by focusing on:

What does this mean
How will this help me
How do I get started

This sounds like sound criticism and good advice. I challenge all of you who do post blogs to think about the three questions that I struggled with at the begining.

Why do I post blogs?
Who do I believe my target audience is?
What do I hope this audience gets from the blogs that I post?

How would you have to answer these questions? What do you think of my firend's suggested format?

Debugging Attributes

Nick Harrison — Wed, 20 Feb 2008 02:58:51 GMT

Debugging Attributes

Have you ever been debugging code and examined the properties of an object? You get both the public properties and the private member variables! Why is that? Can this be avoided?

This seems to violate the principles of encapsulation. It also complicates the process of examining the contents of an object at run time. You don’t really want to have to look at all of the private member variables which by definition should be irrelevant to the task of debugging.

Fortunately the violations to encapsulation pose limited risk. Even though the debugger will reveal hidden member variables, you still cannot access them in your code.

The confusing part is when you view an object’s detail and you have to filter through potentially twice as many variables as there are properties.

How do you remove this potential confusion in the objects that you create? Enter the System.Diagnostics.DebugBrowsable attribute:

Add a DebuggerBrowsable attribute to private member variables.

[System.Diagnostics.DebuggerBrowsable (System.Diagnostics.DebuggerBrowsableState.Never)]

Now these variables will not show up when you do a Quick Watch. This will clean out the entries from the Quick Watch that you did not intend to be visible.

Another debugging frustration is stepping into methods or properties that you are no longer interested in.

Before c# 3.0 introduced implied properties, business entities could be particularly frustrating since they often included several very simple properties that you never had any need to step into.

I would often try to step into a method and have to step into several properties’ get accessors to pass their values as parameters.

Not only is this annoying, it is also potentially confusing and time consuming as the debug bounces around in irrelevant code as you are trying to figure out why an errant method is not behaving as you expect.

If only there was a way to instruct the debuger to ignore certain pieces of code …

Turns out that there is!

[System.Diagnostics.DebuggerHidden] Causes the debugger to completely ignore the method.

[System.Diagnostics.DebuggerStepThrough] The debugger will not step into the method but will honor breakpoints in the method.

[System.Diagnostics.DebuggerNonUserCode] This attribute is similar to combining the first two attributes. This is intended for generated code or designer code.

Since these are attributes, you have to pay attention to the AttributeUsageAttribute.

DebuggerHidden and DebuggerNonUserCode can be tied to properties. DebuggerStepThrough cannot. It can be applied to methods though. This means that it would have to be applied to the get and set individually for a property and not to the property as a whole.

The DebuggerStepThrough attribute causes some problems for CodeDom since there is no way to associate attributes with the individual methods that make up a property. Use the DebuggerNonUserCodeAttribute instead.

Conditional Attribute

Nick Harrison — Wed, 20 Feb 2008 02:56:02 GMT

ConditionalAttribute

Certain methods especially in the System.Diagnostics namespace are decorated with ConditionalAttributes similar to this:

[Conditional("DEBUG")]

What is this all about? The conditional attribute provides a nice way to have code be conditionally ignored. Methods decorated with this attribute will not have their calls compiled to IL unless the condition is true.

In the attribute shown above, any calls to the method will not be made unless the symbol DEBUG is defined.

This creates some very intriguing possibilities. Some of which might be nice and some of which might be pure evil.

Code like this:

#define TEST
using System;
public class MyClass
{
public static void Main()
{
#if (TEST)
Console.WriteLine("TEST is defined");
#endif
}
}

Can be rewritten to code like this:

#define TEST
public class MyClass
{

public static void Main()
{
TestWriteLine("Test is defined");
}

[System.Diagnostics.Conditional("TEST")]
public static void TestWriteLine(string message)
{
Console.WriteLine(message);
}
}
Is this better? Consider this, you would have to wrap every method call the “if test compiler directives” to achieve the same effect of adding the attribute to one place.

If you are only calling the method from one place, this probably doesn’t matter, but if you are potentially calling this method from throughout multiple enterprise applications, this is unrealistic.

The compiler directives can cause confusion by interrupt the logic flow.

Here are some examples where this might be very useful and practical

Suppose you wanted to be able to support a build that could be used for code coverage testing without having to change code for a production build.

Suppose you wanted to have a build to support performance metrics without having to change any code.

Suppose you wanted to have a build to support debugging information without having to change production code.

Turns out, this last example is the whole reason this attribute was created. This is how Debug.WriteLine works.

Try this, sprinkle your code with calls System.Diagnostics.Debug.WriteLine(), compile in debug mode, and examine the assembly with Reflector. You will notice that all of your calls to WriteLine are there. Now compile in release mode and examine the assembly with Reflector. You didn’t change any code, but now none of the WriteLine statements are there.

We could create a method decorated with a conditional attribute requiring that the symbol CodeCoverage must be defined and then call this method at the start of every function. Compile the code defining this symbol. Now when we run through a round of testing, we will get a list of every method that was called. Recompile the code without defining this symbol and the overhead of logging function calls goes away.

As is often the case, there are a couple of caveats. This is not documented on MSDN anywhere that I have seen. Any method decorated with this attribute must return void and cannot have output parameters. This is intended to prevent the removal of this code from causing any unintended side effects. You would not want to rely on a variable being initialized by a function that may or may not be called.

How could you envision using such attributes?

Your project might be in trouble if …

Nick Harrison — Thu, 10 Jan 2008 03:02:52 GMT

I recently worked on a project that failed. There is no other way to put it. The project failed! It’s a hard thing to admit.

There are many reasons why bad things happen to good projects. There are many reasons why despite our best intentions, not every project is successful. There is always plenty of blame to go around. The business market changed. The technology changed. We could not find the right resources. Critical resources left. The project lost funding. The business lost interest…

Many of these reasons can be boiled down to, IT didn’t know what the business needed and the business didn’t know what IT was doing. In other words requirements were not well documented.

From my recent experiences, I have come up with the following red flags to help you identify when your project might be in trouble

Red flags

· If you have never met your subject matter experts, your project might be in trouble
· If there are no subject matter experts, your project might be in trouble
· If new requirements are deemed critical but ignored for the sake of the schedule, your project might be in trouble
· If a user that you have never heard of claims to be a project sponsor, your project might be in trouble
· If the requirements change so much from one week to the next that you feel like it’s a different project, your project might be in trouble
· If new people join the team and its weeks before you even meet them, the project might be in trouble
· If you look around and there is no one to QA your code, your project might be in trouble
· If you spend more time deploying than you do coding, your project might be in trouble
· If the same project has failed over three times already, your project might in trouble
· If no one can succinctly state the business needs being solved, your project might be in trouble
· If you have already deployed once, but still second guessing the platform, your project might be in trouble
· If you can submit last month’s status report for this month and no one notices, your project might be in trouble
· If you can’t tell last month’s status report from this month’s, your project might be in trouble
· If you have worked on the project for over a month and still don’t know where the database is, your project might be in trouble
Guidelines:

· Write requirements down
· Don’t get bogged down in format or structure just content
· Get consensus that what you are working on is what needs working on
· Talk to as many users are you can. They rarely will agree with each other
· Deploy new functionality as often as you can so that the users don’t worry that you have forgotten about them
· Keep deployment schedules spread out enough so that you don’t get bogged down in deployment overhead
What red flags have you seen? What are some guidelines that you have seen work?

Scared of Complex Technologies? Embrace Them!

Nick Harrison — Thu, 10 Jan 2008 03:01:23 GMT

Many people seem to be intimidated by some of the most exciting programming features in DotNet. Reflection comes to mind.

I once did a little client training and on the first day was lectured about this “Reflection Crap.” We often fear what we don’t understand. We often avoid technologies that we don’t have to use and cling to more familiar technologies and techniques. It’s no fun admitting what we don’t know, and it is often faster to do something the old familiar way than it is to use new unfamiliar techniques, even when the new technique is better.

The result is that many people never use reflection or regular expressions, or design patterns or threads, or … until there is no other way to accomplish whatever task they are working on.

The result is that their first exposure to the new technique is pretty complicated and scary. If the first time you use a regular expression is to handle data validation where nothing else would work, then your first regular expression will be a pretty tough one. If the first time that you try to understand a piece of reflective logic is while production is down and you are tasked with untangling a failed reflective call, without a doubt you will be tempted to rip out the “reflection crap”. If your first foray into multi-threaded program is when production is reporting concurrency issues that are costing the company money, you will hate threads.

If on the other hand, you play with regular expressions between projects and start with simple pattern matches and work your way up to more complex patterns, you will have no problem using a 20 character expression to parse a string instead of 40 lines of string manipulation logic code.

If you play with Reflection during design and see how easy it is to interrogate the metadata when you don’t have a business manager breathing down your neck, you will not be afraid to use reflection to loop through the properties of an object at runtime to initialize them to known safe values or loop through the methods of an object searching for new methods to run at.

Playing with these technologies when it is safe, gives you more confidence to be able to pull them out and show them off confidently when it may not be so safe, but when they are most useful.

What are you afraid of? What were you afraid of that you know use with confidence? What have you been putting off learning?

Reflecting on Software Metrics

Nick Harrison — Thu, 10 Jan 2008 03:00:07 GMT

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.

Much has changed in the land of Nick

Nick Harrison — Sat, 24 Nov 2007 02:43:19 GMT

As is most likely quiet obvious, it has been a long time since I have posted anything. There are a couple of reasons for that.

Most importantly, I met the love of my life, got married and have a new family that dominates all of my priorities. Meeting Tracy and falling in love has changed my life in so many ways and definitely for the better.

In the past, I worked simply out of sheer arrogance. The only thing that matter was what others thought of me. No real purpose. Now, I work as a means to an end. Taking care of my family.

In the past, no one really cared how long I worked. When you live alone, there is no one concerned if you come home late and there is no real motivation to keep your work and personal life in balance. If you don't have a life, it is eay to fall into a trap that keeps you from ever getting a life. Now, I have a lovely wife and adorable daughter waiting for me at home. They are a great joy to come home to.

I find myself filled with a new sense of purpose beyond the next deadline. Don't get me wrong. I still love a good challenge. I still love facing a challenge that others said could not be met and solving the problems. I still love learning new technologies, and I still love using leading technology to solve real problems. I just have a new love in my life. My family.

Keeping my work and family life in balance is not always easy. I would love to hear how some of you manage such a balancing act. I will also post about how I manage this balance or manage to throw the balance out of whack from time to time.

BCL Team posting on the CodeDom

Nick Harrison — Fri, 21 Apr 2006 13:40:00 GMT

http://blogs.msdn.com/bclteam/archive/2006/04/10/571096.aspx

They talk about how CodeDom is used in the designers for 2.0

There are also several comments and responces complaining about some of the short comings people have with the CodeDom. Some of these short comings are refuted with work arounds. Including a short coming that I have often complained about. :)

View State not Tracking on Dynamic Controls until after the second post back

Nick Harrison — Tue, 29 Nov 2005 01:14:00 GMT

For several days, I have struggled with a problem with the view state on dynamically loaded controls. I am using a fair number of dynamic controls on a little project that I have been working. Everything was working fine except in one section. In this one section, view state was not being tracked until after the first post back. Events were not responding until after the first post back. Everything seemed to be setup properly and it was working everywhere else.

Very perplexing. Who ever heard of a problem fixing itself like that? I have heard of dynamic controls NOT working after the second post back. This was really strange. Here I had obviously made some mistake in wiring up the dynamic controls that fixes itself after one post back.

I tried every thing I could think of to track this down. I overrode the LoadViewState method, PreRender, SaveViewState, UnLoad, etc. Everything looked good. Everything was behaving as expected after the initial post back. As hard as I looked, I couldn't see anything different between the sections that worked and the area that was misbehaving. A fresh set of eyes was needed.

Sometimes you can be too close to a situation to see what is in front of you.

I knew that it was important that the dynamic controls get the same ID when they are reloaded as they had when initially added. I took great pains to reload each control in the same order. I took great pains to unload controls that were no longer needed before adding any additional controls. What I failed to notice and only a fresh set of eyes could see was that in one place, coincidently the place having problems, I incremented the control count, added the control to the containing control's control array, and finally set its ID, using the control count. Everywhere else, I incremented the control count as the last step.

This means that for the problematic section, there would be no control 0 when the controls are originally loaded. Because I was incrementing the control count before using it, the first control would always have an ID of 1. On post back when I reloaded the dynamic controls, the control would load but be given an ID of 0 because I was using the control count and then setting it. There was no viewstate for Control 0 and there was no longer a control for the viewstate data associated with the control with ID of 1. After the first post back, the gap in the control ids was removed and from then on everything worked properly.

I hope that my struggles help someone else.

The joy of solving a problem

Nick Harrison — Tue, 29 Nov 2005 01:05:00 GMT

There is no greater joy, no finer ecstasy than solving a perplexing problem. The more perplexing, the greater the euphoria.

In many ways, I live for this rush.

Often the release that comes from the resolution of such problems makes up for the embarrassment when the root of the problem turns out to be a simple mistake.