While talking about cohesion with a fellow colleague I noticed that there were some confusion about the differences between routines, functions, procedures and methods. Please let me clear this out.

Functions

A function is a small isolated portion of a program designed to perform a specific task. Most often you will see it as “one value going in, another coming out”. What is specific about functions is that they should only have one purpose and no side effects. That is why they also always will return a value.

• double Cos(double x)
• User GetUser(Guid id)
• int Sum(int[] salaries)

Procedures

A procedure is a set of actions that has to performed in a specific order. In programming a procedure is most often an extracted piece of code that you want to reuse in your program. What is most important is that a procedure will change the state of your program, but never return a result value. (returning error codes could be legal if you have no exception model, or if the exception model is not enough)

• OpenDBConnection()
• Console.WriteLine(“They are all routines”)
• BuildConfiguration(IContainer container)

Methods

A method is a function or a procedure that resides within a class. When it comes to functions, they will never change the state of the class by modifying an internal member. It may read private data from the class to calculate the result, but not change the internal data, which would be a side effect to the function.

A procedure in a class could be a setter/getter, a procedure to initialize the object or some other procedure that will change the state of the class.

I think it’s very important to distinguish functions and procedures from one another in object oriented programming. Never write a function that has side effects and never write procedures that also return results. Following that rule will make your program easier to follow with much lower maintenance.

Routines

A routine is something of the above. Without saying anything of the use, a routine is a piece of code that has been isolated from the rest. We use routines every day and still we don’t tend to give them much thought. This is too bad since it is probably the most used structure in programming as of today.

I attend a book circle reading Code Complete 2 by Steve McConnell, where the discussion about defensive programming and asserting came up. I told the group about my assertion mechanisms with extension methods and it was all well recieved. On my way home, I started thinking about it and found a small danger about assertions.

public string Reverse(string argument)
{
    argument.AssertThat(s => s != null,
        "Failed assertion: Argument was null");
    // ... logic ...
    // return result;
}

What is wrong with this? An AssertException will be thrown if the argument passed to the method is null, where an ArgumentNullException would be much more appropriate.

public string Reverse(string argument)
{
    if (argument == null)
        throw new ArgumentNullException("argument");

    // ... logic ...
    // return result;
}

Why on earth could this be important? Because you could be catching ArgumentNullException further up in the call stack. You won’t be catching the AssertException, and why is that?

1. An AssertException does not tell you what is wrong and there is nothing you can do to save the day. It is the same thing as catching Exception and hope to recover from it.
2. If an AssertException is thrown there is something wrong in your development code. These exceptions should never be thrown in production environment, because they are written to make development defensive and not for error handling in production.

This was a valuable lesson learned today. Now I’m going to review all my code that has to do with Assertions. Good evening!

With the word micro-optimization I’m referring to changing units of code so that it performs better and contributes to the main performance of the application.

Patrick Smacchia wrote a blog post about micro-optimization and that might be the first thing I’ve heard from him that I can’t agree upon. He talks about the importance of micro-optimization and how all software out there could use a fair bit of micro-optimization.

He gives some samples of how you can easily optimize your code base by a few simple tricks. Knowing this reflection guru, he’s probably right in all his suggestions, but I would never give in and apply any of them to my code.

• Micro-optimization will start to make a difference when you process a lot of data or method calls. If you do not already have performance problems, stay away from micro-optimizations.
• Micro-optimizing your code will make it harder to read. Never exchange maintainability for optimizations! The time you loose in maintainability is worth more than the money you could spend on hardware upgrades.
• Premature optimizations is a waste of time. Start micro-optimizing when you’ve exhausted all other resources.
• There are performance problems and then there are perceived performance by the user.  As long as you can maintain a high perceived performance you don’t have to micro-optimize your code. This means giving the user constant feedback about what’s happening and displaying progress.

I’ve still not found any situation where I had to loose maintainability and downgrade my code for optimizations. That also means that I’ve only been working on low to midrange performance heavy applications. And when I come to think about it, most applications are in that span.

Don’t give in to optimizations while there are better things to spend your time on.

A micro domain is a single responsibility of a task, piece of code, or anything at all. It was suggested to me that micro domains is a good thing and you can use it to ensure productivity. These were the reasons to incorporate micro domains in your company.

When using micro domains you will give each developer a responsibility in the code that only they care about. They will make sure that this piece of code is well documented, maintains high quality and takes care of any changes that has to be made.

This will increase productivity because everyone knows their micro domain and may produce change at highest rates and also should be able to maintain highest quality. As good as it may sound this is an illusion.

• While productivity may be at high rate in the micro domain, changes that affects several domains will be very slow when developers has to get along, decide about a common interface between their domains and it will take several meetings just getting the simplest of things done.
• What if Developer Joe gets hit by a bus?
• Micro domains will create islands of coding standards and it will not support distribution of knowledge between co-workers. It will also result in much worse quality than expected, since only one pair of eyes have watch a piece of code at any time.

I think that we’ve established by this time that micro domains are evil.

Why do I see micro domains everywhere?

As soon as you have people, you have micro domains. That is because we like to own responsibilities, and we don’t like to share success. I guess this is much worse in a hierical organization than a flat, but I do manage to step on peoples toes from time to time, when I thought we had collective responsibility and I didn’t see the clear line of your micro domain.

As you’ve already noticed there are micro domains in everything

• You’re a project manager and can’t take critique or suggestions about how your project should be run.
• You’re a database administrator and you won’t listen when a suggestion about normalization in your database is proposed.
• You’re a CEO and you can’t criticize the developers about their code quality without making people upset.
• You’re a consultant that manages to create more work opportunities in a existing client, and gets frowned upon by the sales department.

When micro domains hinders me from doing my job properly, I get frustrated. When I have to ask for permission doing a database changes, instead of giving suggestions, it has gone completely out of hand.

Kill the micro domains!
Embrace collective responsibility.