Derik Whittaker : Featured

Removing words like Convince, Convert and Persuade from our vocabulary

Derik Whittaker — Tue, 04 Nov 2008 11:26:22 GMT

One of the common themes of this years KaizenConf was how to move a towards being a lean organization. During most of the sessions and conversations that I was part I cannot tell you how often I heard words like Convince, Convert and Persuade said. At first I had nothing against these words, but the more I thought about I know feel that we need to remove those words from our vocabulary when talking about moving a team or organization from one thing to another (in context of these conversations it is towards being lean).

Using terms like Convince and Convert has the feeling that 'I am right and you are wrong'. Even if you are not using terms like Convince and Convert in your dialog with people, I am going to guess that you have that as your goal, or your end game.

I am here to suggest that we as a community need to change our focus from Convincing towards Demonstrating. By changing our angle and our position to be more neutral and soft I feel we can archive our goal of bringing change easier and with less friction. It is like that old saying 'you can catch more fly's with honey than vinegar.

Lets take a look at the subtle differences between Convincing and Demostrating.

When we are trying to Convince someone of something many times we give off the following vibes.

That your way is wrong, and our is right
That we are better and more knowledgeable
That we are preaching

All of above tend to put people on the definsive and if someone is on the definsive they are less likely to be open minded and less likey to want to try to understand what it is you are trying to say.

When we are trying to demostrate something to someone we give off the following vibes.

Heartflet attempt to share knowledge
Cooperation
Alternative to, not a replacement for their way of doing something
Sincere intrest in helping them.

When you speak to someone with the above vibe, you are essentally telling them that I have an idea and I think that my idea can help you out. If you attack it from this angle you may be surprised by the level of reception you can receive.

Remember, convincing someone is never easy, but demostrating alternatives and allowing them to make their own decision can be.

Keep up the good fight and happy demostrating.

Till next time,

Should not be 'The Business', but should be 'Our Business'

Derik Whittaker — Thu, 10 Jul 2008 14:06:14 GMT

Last night I was listening to a recent HanselMinutes pod casts where he was talking with Tom & Mary Poppendiek. For those of you who do not know who Tom & Mary are, they are the 2 behind a lot of the lean software movement (books here & here).

There was a statement made in the episode by Tom that really stuck to me and actually caused me to have a 'ah-ha' moment. The statement that Tom made was that we as developers tend to refer to business owners as 'The Business' in place of referring to them as 'Our Business'.

The difference may seem subtle, but in actually it is quite substantial. By referring to business as 'The Business' we are making the statement that we have no say or no influence in the decisions being made or the direction to be taken. It also implies that we as developers (or IT personal in general) are in some way inferior to the people making the decisions.

When we refer to the business as 'Our Business' we are doing multiple things. First we are saying that we have ownership and knowledge in the business and have the ability to not just code, but to make decisions. We are also saying that we have more ownership in the product by including ourselves in the 'Business'

The differences between the terms 'The Business' and 'Our Business' may seem small, but in reality they are huge. Think about, reflect on it. Let me know your thoughts.

Till next time,

[----- Remember to check out DimeCasts.Net -----]

Foundations of Programming EBook - Great Read & ITS FREE

Derik Whittaker — Thu, 10 Jul 2008 13:38:36 GMT

If you have not hear, Karl Seguin has authored a great, short eBook which he is giving away free to the world. This book is based of his blog series of the same title.

Do yourself a favor and go download this book, it is pretty short and is a great read. There are great nuggets of information for developers at every level.

You can browse to Karl's post here.

Till next time,

[----- Remember to check out DimeCasts.Net -----]

Developer training, a real (non)success story

Derik Whittaker — Mon, 30 Jun 2008 12:42:55 GMT

About a year ago I created a few posts on the topic of Developer Ramp time and how companies can help the process as well as why different developers ramp up at different speeds. Developer ramp time and how companies can aid in speeding up this time is critical not only to a new employee's success, but also that of the team they are joining.

This is why I was so shocked to hear a story from a buddy of mine about his company and their philosophy on developer ramp time.

The story goes something like this:

My buddy (we will call him Will for this post) has recently been put in charge of the maintenance team at his company. Currently there are a total of 5 people on this team, 4 developers and him. Because his team is rocking and getting things done the company decided to hire on 2 more developer and put them on his team. Because Will is one of these guys that believes in doing things the right way and because he sees the value in trying to speed up/aid the ramp time for new developers he decided he would like to put together a plan of action for these new developers.

So Will spent a little time putting together a high level list of things he thought a new developer would need in order to become a upstanding member of the team. However, because he did not want to spend too much time on this with out getting buy-in from his boss (should be a walk in the park) he simply put together a outline of what he wanted to do and sent that to his boss.

Along with sending the outline to his boss, he also provided a summary of his intentions and goals for his training. Will was looking for his boss to give him the thumbs up on moving forward with this training and figured he would start putting together the materials in the next day or so.

Will was shocked when he received the reply from his boss that simply stated the following

'The new developers are both professionals and adults and should be able to learn all they need to on their own.'

Needless to say that when Will received this reply he was not a happy camper. How is he meant to help his team succeed if he is not allowed to help them ramp up?

The moral of the story here is that training new employees is painful, it is hard and it can be expensive. However, not training them can be even more painful and more expensive because they will be less productive and potentially make more errors.

Any company that does not see this or does not value this is not a place I would like to work, and keeping me around may be hard.

Till next time,

[----- Remember to check out DimeCasts.Net -----]

[ANN] Dimecasts.net is Alive and Kicking

Derik Whittaker — Tue, 27 May 2008 13:51:00 GMT

A few weeks ago while putting together a screencast series on how to use NUnit (and a basic intro to testing) I got the bright idea to launch a new site. I wanted to create a site that allows myself (and others in the future) to create, host and share short (about 10 minutes -- hence the name dimecasts.net) screencast's (I call them episodes) on how to do various different things.

I started bouncing this idea of other developers which I trust, and the feedback was awesome so I moved forward with the idea.

So, who is my target audience with these episodes....everyone. My thoughts are to create episodes that tackle everyday coding issues as well as show how to use various tools (NUnit, Mocking tools, IoC, etc). I want the episodes to range from 100 level (Intro to XYZ) all the way to 400 level (mastering XYZ) and I want them to be short and to the point.

I am launching DimeCasts.Net with 4 episodes, but have 10 more in post production ready to roll. I plan on rolling 1-2 a week (depending on my and others schedules) till we run out of ideas.

Here are the 4 initial episodes

Overview on how to use NUnit

This screencast is an introduction to NUnit as well as a brief overview of testing with NUnit. In this episode you will learn the following:

Use the NUnit IDE
Create simple tests with NUnit
Debug a test via the VS IDE

Overview on NUnit's Attributes

In this episode we will learn how to use some of the different attributes that are built into the NUnit testing framework.
The attributes we will review are:

Test
TestFixtureSetup
TestFixtureTeardown
Setup
Teardown
Ignore
Explicit
ExpectedException

Creating tests with NUnit

In this episode we will cover the basics on how to create various unit test using the NUnit testing framework. We will also review the different Assert helper classes that are part of the testing framework.

Unit testing events with NUnit

In this episode we will cover how to test events that are raised from an object. We will cover multiple different ways to do this.

Please let me know what you think. What you like, what you do not, or what you would like to see.

Till next time,

Thoughts on writing quality test code vs writing quality application code

Derik Whittaker — Wed, 21 May 2008 12:31:21 GMT

Anyone that is a practitioner of testing or specially TDD knows that the quality of your tests are a direct measure in the assumed quality of your tested code. Better put, if your tests suck, you can assume very low quality from your code.

So what is harder, writing quality code or writing quality tests? My vote is that writing quality test code is harder then writing quality application code.

When it comes to writing 'quality application code' the measure of quality is really in the eye of the developer. What one person calls good code may be called crap by another developer. But as long as the code meets the business needs, it should be at least considered quality (if not simply functional) code.

However, creating quality test code is a little more measurable. One possible way to measure this is by code coverage (please do not take that statement as high code coverage equals high quality as this is NOT the case). Another is to simple make sure the tests exercises as many different business scenarios as practical (notice here I did not say possible because at some point you reach the point of diminishing returns and should just stop). Finally, if you keep your tests compact and focused you should be able to create quality tests.

To me the real measure of quality test code is how maintainable is it? Is it very painful to refactor when the code under test needs to change? If you can maintain your test code with very little friction or effort, they I would say chances are high you have high quality test code.

Hints your test code may be poor quality.

Test code does not test the intent of the code
Test code becomes to brittle to maintain going forward
Test code is heavy (those testing multiple things)
You dread making changes to your code base for fear of having to modify your test code.

Hints your test code may be of high (er) quality

Causes very little friction during future code changes
Test code is light weight, tests only a single concept
You do not dread making changes to your code base for fear of having to modify your test code.

So, what do you think? Which is harder and why?

Till next time,

Strict Mocking Semantics Is the only way to Mock

Derik Whittaker — Mon, 19 May 2008 13:27:03 GMT

Recently I was giving a Mocking presentation and I made the statement that I prefer strict mocking semantics over loose semantics. At the end of presentation one of the members of the audience raised point to my liking strict over loose. We had a great discussion and I thought I would regurgitate it here and give my reasons for liking strict over loose.

Definition of Strict Replay Semantics:
Only the methods that were explicitly recorded are accepted as valid. This mean that any call that is not expected would cause an exception and fail the test. All the expected methods must be called if the object is to pass verification.

Definition of Loose Replay Semantics:
Any method call during the replay state is accepted and if there is no special handling setup for this method a null or zero is returned. All the expected methods must be called if the object is to pass verification.

Pros of Strict Replay

Developer creating the test must know EXACTLY what the codes does they are testing
Will cause the test to fail in the future if anyone changes the underlying code
Creates a 'what you see is what you get' scenario in your tests. Meaning that if you do not setup an expectation you will NOT have success.

Cons of Strict Replay

May appear to make the test brittle
Requires the developer to know EXACTLY what the code does (yes this is also a pro). Sadly a lot of developers are too lazy to completely understand the code they are creating, hence this being a con.
May create a lot of 'noise' (I.e. a lot of mock setups) if your code is not loosely coupled (this is a con, but is really a result of a code smell)

Replay of the conversation
During my presentation I had made comment that I prefer strict semantics over loose and simply left it at that. I did not really go into detail, but at the end of the session one of the audience members wanted to dive deeper into the why, so we did.

He made a very good observation in regards to strict mocking and that was that my test will fail if it was originally setup to expect a call to the 'db mock' 2 times, but later the method was modified to only need 1 call. I agreed with his observation, but told him I actually see this as a good thing.

When we create a test we are testing our code base at that point in time. We are also testing business rules at that point in time. When ever I setup my mocks (create expectations) I am doing so with knowledge that a given dependency will ONLY be called N number of times. If I need to refactor/enhance that method/logic and I change the number of times my dependency will be called, I want my test to fail. This failing test should prompt me to review my test logic to ensure that I am still testing the intent of the method.

By this logic, strict mocking semantics is the best way to go. If I had used loose semantics my original test would still pass when it should fail potentially hiding flaws in my test logic. Remember green tests does not equal good code coverage.

Till next time,

***** Updated *****
Removed a misinterpreted statement from Ayende over at Rhino
***** Updated *****

XLinq'n in the new world - Data access comparisons with Xml/XPath

Derik Whittaker — Mon, 12 May 2008 10:15:22 GMT

Originally this series was meant to be titled 'Any thing you can do I can do better', but to be honest after writing the Xml/XPath examples I realized the XLinq is really no better per say than Xml/XPath. However, what XLinq does bring to the table that Xml/XPath does not:

Does not need to use the XPath query syntax
Reads like English (mostly) when creating queries
Lower barrier to entry for someone new to Xml (my opinion)

In Part 1 of this little mini series we will examine some common data access scenario's and how XLinq's syntax compares to that of standard Xml/XPath access.

Before I get started I will show you a sample of the XML document I am using.

<?xml version='1.0'?>
<root>
<system>
    <list>
      <subscribers>
        <subscriber Type="Random">
          <id>63425813</id>
          <Email__Address>FakeAddress@comcast.net</Email__Address>
          <EmailType>HTML</EmailType>
          <Status>InActive</Status>
          <First__Name>RAY</First__Name>
          <Last__Name>Bob</Last__Name>
          <PIN__Code>NaN</PIN__Code>
          <PIPIN>33232</PIPIN>
          <UID>418444</UID>
          <ProgNum>0</ProgNum>
          <Title />
          <Username />
          <Password />
        </subscriber>
      </subscribers>
    </list>
    <list>
      <subscribers>
          <subscriber>
          <id>1271728821</id>
          <Email__Address>FakeAddress@yahoo.com</Email__Address>
          <EmailType>HTML</EmailType>
          <Status>InActive</Status>
          <First__Name>JOHN</First__Name>
          <Last__Name>Foo</Last__Name>
          <PIN__Code>NaN</PIN__Code>
          <PIPIN>1254512</PIPIN>
          <UID>1033488</UID>
          <ProgNum />
          <Title />
          <Username />
          <Password />
        </subscriber>
      </subscribers>
    </list>
</system>
</root>

Example 1 - Simple data access

via Xml/XPath

XmlDocument xmlDocument = XmlHelper.GetRawSnippetAsXmlDocument();

// notice the @ is on the status -- this is how u search a element
Int32 listCount = xmlDocument.SelectNodes( "//list" ).Count;
Int32 subscribersCount = xmlDocument.SelectNodes( "//subscriber[@Type='Random']" ).Count;

via XLinq

XDocument xDocument = XmlHelper.GetRawSnippetAsXDocument();

Int32 listCount = xDocument.Descendants( "list" ).Count();
Int32 subscribersCount = xDocument.Descendants( "subscriber" ).Attributes( "Type" ).Where( e => e.Value == "Random" ).Count();

As you can see both examples are pretty light on the code and are pretty straight forward. This is one case where the new XLinq syntax is really no better/simpler then the Xml/XPath syntax. The issue with the XPath syntax is that

Example 2 - Get a list of nodes that match our search criteria

via Xml/Xpath

// notice the @ is missing on the status -- this is how u search a node
XmlDocument xmlDocument = XmlHelper.GetRawSnippetAsXmlDocument();
XmlNodeList xmlNodeList = xmlDocument.SelectNodes( "//subscribers/subscriber[Status='InActive']" );

foreach ( XmlElement element in xmlNodeList )
{
    var id = element.SelectSingleNode( "//id" ).InnerText;
    var type = element.Attributes[ "Type" ].Value;
}

via XLinq

XDocument xDocument = XmlHelper.GetRawSnippetAsXDocument();

var item = from doc in xDocument.Descendants( "subscriber" )
           let status = (string)doc.Element( "Status" )
           where status == "InActive"
           select doc;

foreach ( XElement xElement in item )
{
    var id = xElement.Element( "id" ).Value;
    var type = xElement.Attribute( "Type" ).Value;
}

Now here is an example where I think the XLinq syntax is cleaner and easier to understand. There is no need to know or understand the XPath syntax, which can be a pain to learn. Also here you see how XLinq looks a lot like standard SQL syntax and should be familiar to most developers.

Well, above I have shown you a few simple examples that compare Xml/Path to XLinq, I hope you find this useful. The next post will compare how to update/add data to a document using the both Xml/XPath and XLinq.

Till next time,

Are you going the way of the Dinosaur???

Derik Whittaker — Thu, 24 Apr 2008 10:20:17 GMT

What are you doing to keep your skills current?

Do you learn new technologies?
Do you learn new tools?
Do you learn new languages?

If you did not answer yes to at least 1 of the 3 questions above, I have one last question to ask. What are you doing to not become a Dinosaur?

In my opinion developers today have more at stake then ever before.

Technology is changing at the speed of light
Business demands are getting larger and more complicated
Technology is getting more complicated (which is counter to its intent)

Over the past few months I have spoken to a few different developers that have become 'complacient' in what they do. They have no interest in learn a new language (Ruby, Java, F#, etc) or even learning to use new frameworks (RoR, MonoRail, MVC, NHibernate, etc) because they are happy with what they have. This is fine and this is dandy, but the day will come that they will regret this decision.

Let me tell you a little store.

Long, long ago there was a developer that was writing his applications in his language of choice, COBOL. This guy was as happy as a clam, he had no worries, no issues. The language did what he need and he could make it do all sorts of cool stuff. And most importantly he felt comfortable with his language of choice.

Then one day someone created a newer, hipper language (insert any OO based language here) and suddenly it became all the rage. Now the COBOL developer thought, should I invest the time effort to learn this new language, or should I stick with COBOL. In the end he decided he liked COBOL, cause he was happy and content. He also did not buy into all the press surrounding that language. He figured that it is just a passing fad. Now he may have been right, but where he made a mistake was he did not learn.

Now lets fast forward to today. In the past few years there have many new languages and frameworks/toolsets have been released. They all have their pros and cons and some will die off and become extent. But the ones that live on may someday push your language out of the way. If you don't at least have a working knowledge of what they bring to the table, what makes you think will will not be like our COBOL developer from our story?

So, let me ask you.... What are YOU doing to not become a Dinosaur?

BTW, before you ask what I am doing, let me tell you. I am currently learning Ruby, I am playing with IronRuby (I know, not much different the Ruby). I plan on playing with F# to become familiar with what a Functional language can do for me. I started learning the MS MVC framework and will be playing RoR (Ruby on Rails) to see where that is going. I did some MOSS work a while back. I am branching out and getting my hands on as many different tools/frameworks as possible (NHibernate, Linq2Sql, TypeMock, etc, etc, etc). I have not intention of becoming a master of any of these, but I intend on becoming knowledgeable enough to know what they offer and what they do not.

Till next time,

ReSharper 4.0, I love you but it may be time we break up

Derik Whittaker — Tue, 22 Apr 2008 14:01:56 GMT

I have been a loyal and faithful user of ReSharper for the past few years, and am generally happy with the product. But this 4.0 EAP is starting to kill our relationship.

I know that you are still in 'beta' but come one, what is taking so damn long. Visual Studio 2008 have been in full production now for 5+ months, not to mention the amount of time it was in beta. Again, what is taking so damn long.

I know and understand that this is not a simple application but really, does every build have to hurt me more then the previous one? It seems to me that every day I have more and more issues with you. A tool should be painless to use, not painful. I have now reverted back to build 767 as it is the most stable one for me.

I love the fact that have put it all on the line with the 'open beta' and I know it will make you better because of it, but I just don't know how much longer I can wait.

Please, please, please hurry up and go live with the real version....

Till next time,

**** LET THE FLAMES BEGIN ****

How to share configuration files between projects

Derik Whittaker — Tue, 15 Apr 2008 12:47:52 GMT

Sharing configuration files between multiple projects in Visual Studio is a simple task, but it is not intuitive in how it is done. In fact, until recently I did not know how to do it via the IDE, I would always hand edit the .sln file to enable this feature (sad I know). Today I thought I would throw up a simple set of screen shots to show everyone how easy it really is.

Overview:

We have a solution that has multiple projects and we would like to share our app.config along with our StructureMap.config files between each of the projects.

Step One -- Adding the config files to your soultion:

Create a solution folder in your solution. I like to add them here as a way of organizing my common files. Once you have your Solution folder created, right click and choose Add -> New Item (see blow) (If you already have these files, simple do an Add -> Existing item and reference the existing ones).

Now for some odd reason MS decided that Application Configuration files were not a valid option for solution folders so we have to do some manual work. Select the "Text File" template and rename the file to App.Config (see blow).

Finally because we did not choose the Application Configuration template we need to add the XML tags to the file by hand. Here is the XML to add.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
</configuration>

Step Two - Add reference to the each project:

Now that we have created our config files in our solution folders we want to add them to each project. We do this by right clicking the project and choosing Add -> Existing Item

This will open up a new dialog and this is where the magic happens (the part that always eluded me). Change the extension type filter to 'All Files(*.*)" allowing us to see the .config files. Choose the file you want to add, but don't click directly on the "Add" button. Click the little drop down arrow on the right hand side. This will give you 2 options. 1) Add 2) Add as Link. Choose Add As Link.

After you choose the 'Add as Link' option you will notice that the App.Config file will be added to your project. But it will has the shortcut image on the icon, this tells you it is a link, not an actual reference.

Step Three -- Setting up the Properties on the file

After we have added our config file we need to ensure that it gets copied to our output (bin) directory during a compile. *** NOTE *** You do NOT need to do this with an App.config or Web.config as the IDE will do it for you *** END NOTE ***

Right click the linked file and choose Properties. This will open up a new dialog (fly out pane) and choose 'Copy Always' or 'Copy If Newer' in the Copy to Output Directory action.

There you go, you now have a single config file for your solution that can be referenced by all the projects in your solution.

Hope this helps someone.

Till next time,

Simple extension methods to help with Asserting values

Derik Whittaker — Thu, 10 Apr 2008 12:49:43 GMT

In the past I have written about the Fail Fast principle. This is a principle I try to live my development life by. I would rather explicitly check for possible failure points then have a runtime error crop up. In the past when writing these failure check we have had to resort to a few 'cavemanish' techniques. But with the inception of Extension Methods (here or here) we can actually create something that is pretty simple as well as elegant.

Lets take a look at a few examples where we are NOT using extension methods to accomplish our failure checking.

public bool SomeMethod( string key )  
{  
	// In this case the key cannot be null or empty  
	if ( key.length == 0 ) { throw new ArgumentOutOfRangeException( "key", "Some Message Goes here" ); }
}

The code above works, it is pretty simple and will get the job done. But to be honest, having this sprinkled all over your code is kinda ugly.

public bool SomeMethod( SomeObject obj, Int32 someInt )  
{  
	// In this case the object cannot be null  
     	Assert.IsNotNull( obj, "Some Object" );  
  
	// In this case the int must be greater then 1  
     	Assert.IsTrue( someInt > 1, "Some Int not correct" );  
}

This code works as well and is more concise the the previous example. However, this code is still less readable then the example below.

Now, lets take a look at the same thing, but using Extension Methods

public bool SomeMethod( SomeObject obj, strnig someString )  
{  
	// In this case the object cannot be null  
	obj.AssertNonNull(); 
  
	// In this case the cannot be null or empty
	someString.AssertNotNullOrEmpty();	
}

Here is the code for the actual extension methods assert

public static void AssertNonNull( this T value )
{
	// Do our null check here.
	if ( value == null ) 
	{ 
		// Could even use reflection to gather info such as calling method, method exception was
		//	found in, etc.
		throw new ArgumentNullException( "Some message here" );
	}
}

The assert above using the extension method to me is the most elegant. It is easy to read (very important) and very concise.

Keep in mind, all the examples above do the exact same thing, but they do in varying levels of elegance. I would argue that the usage of extension methods here makes the code cleaner and easier to read.

Till next time,

Linq and Delayed execution

Derik Whittaker — Mon, 07 Apr 2008 18:11:57 GMT

If you have not taken a look at Linq (either Linq to objects or Linq to sql) you need to do so. I would say it is the coolest new feature that was released with .Net 3.5. But there is one thing that you MUST keep in mind when using Linq. It has been designed to perform lookups using delayed execution. When you declare your Linq statement all you are doing is creating the memory representation of the query as an express tree. The execution of this plan will NOT be executed until the first time you attempt to access the result set of the Linq query.

But before we get started I want to show the demo object model I will be using for this post.

public class Demo
{

    public string Name { get; set;  }
    public string Text { get; set; }
    public Int32 Count { get; set;  }

    public static List BuildDemoList()
    {
        return new List< Demo >
                   {
                       new Demo {Name = "First", Text = "Some", Count = 123},
                       new Demo {Name = "Second", Text = "Other", Count = 223},
                       new Demo {Name = "Third", Text = "Value", Count = 443},
                       new Demo {Name = "Fourth", Text = "Goes", Count = 224},
                       new Demo {Name = "Last", Text = "Here", Count = 5534}
                   };
    }
}

Lets take a look at a few examples to help demonstrate how Linq's delayed execution works

This first block simply shows how you can query a collection and spit out the contents

List< Demo > values = Demo.BuildDemoList();
var result = from d in values
             where d.Count >= 224
             select d;

foreach ( var demo in result )
{
    System.Diagnostics.Debug.WriteLine( string.Format( "{0}, {1}, {2}", demo.Name, demo.Text, demo.Count ) );
}

// output
// Third, Value, 443
// Fourth, Goes, 224
// Last, Here, 5534

This second block does the same as the ones above, but with a twist. Because we are changing the value of an item in the list PRIOR to using it we are going to change the results.

List values = Demo.BuildDemoList();
var result = from d in values
             where d.Count >= 224
             select d;

values[ 2 ].Count = 100;

foreach (var demo in result)
{
    System.Diagnostics.Debug.WriteLine(string.Format("{0}, {1}, {2}", demo.Name, demo.Text, demo.Count));
}

// Output
// Fourth, Goes, 224
// Last, Here, 5534

This final block appears to be the exact same as the second above, but with one small change. We have called the .ToList() on the Linq statement. By calling the .ToList() we are forcing the execution of the query immediately. Now when we change a value in the underlying collection and then iterate over the results we will NOT get the changes.

List values = Demo.BuildDemoList();
var result = ( from d in values
             where d.Count >= 224
             select d ).ToList();

values[2].Count = 100;

foreach (var demo in result)
{
    System.Diagnostics.Debug.WriteLine(string.Format("{0}, {1}, {2}", demo.Name, demo.Text, demo.Count));
}

// Output
// Third, Value, 100
// Fourth, Goes, 224
// Last, Here, 5534

The thing I would like to stress here is that Linq by default will NOT execute the query prior to the first use. I know this will cause issues for some, and may be very hard to spot if you do not understand this fact.

Till next time,

Simple Linq to Object example with Casting

Derik Whittaker — Fri, 22 Feb 2008 15:19:33 GMT

This is my first go at playing with Linq. So far it is pretty cool, but I wanted to share something because I found it painful.

I wanted query a list and then cast a anonymous type to a static type. I was not able to find anything on the net to help me with this (could be i just did not look in the right places) so i thought i would share my findings.

Below is the definition of the 'Sport' object

[Serializable]
public class Sport
{

        public virtual Int32 SportID { get; set; }
        public virtual string Name { get; set; }
        public virtual string Description { get; set; }

}

Here is the code to query some data out of a list of sports List<Sport>

List sports = new List();
sports.Add(new Sport { SportID = 1, Name = "Sport 1", Description = "Sport Desc 1" });
sports.Add(new Sport { SportID = 2, Name = "Sport 2", Description = "Sport Desc 2" });
sports.Add(new Sport { SportID = 3, Name = "Sport 3", Description = "Sport Desc 3" });
sports.Add(new Sport { SportID = 4, Name = "Sport 4", Description = "Sport Desc 4" });
sports.Add(new Sport { SportID = 5, Name = "Sport 5", Description = "Sport Desc 5" });
            
var query = from s in sports
	where s.Name == "Sport 2"
        select s;

The code below will show how to cast/convert from anonymous type to static type.

Sport sport = (Sport) query.First();

The code below will show how to cast back to a List<Sport>

List newSports = query.ToList();

Hope this helps someone else.

Till next time,

Things to think about if you want to be a consultant

Derik Whittaker — Wed, 02 Jan 2008 21:26:00 GMT

I was chatting a buddy recently and he was thinking about making the jump to the consulting world (not solo, through a consulting firm). As he has never been a consultant I gave him my 2cents on questions to ask during the interview as well as things he has to accept before making the jump.

Questions to ask the consulting firm

What percent of travel is the norm?
This is very important to know up front. Because if you don't want to travel much and they tell you they are 100% travel, then move on.

One thing you need to keep in mind, is that they can give you a number, that number is NOT in stone. It can/will change from client to client. In my 5 years of consulting, I never left the greater Chicago area. And for 2+ years I worked out of our home office.
What is your bench policy?
Ask what the policy is for being on the bench? More importantly ask the billable % expectation is for a consultant. This can be important because if they expect you to be billable 90% of the year then they may not be able to handle any rough patches. However, if they expect you to be billable for only 80% then they should be better set for rough patches.

I also found that if a company has higher expectations about billable %, they may not be willing to provide non-billable training as it eats into the bottom line.

If you are on the bench, do they have something for you to do? Can you go to training during that time? Or can you simply stay home and collect a check (i wish)?
What is your training policy?
Ask what type of training they budget for? Do they pay for conferences, weekly training classes? Do they EXPECT you to take some sort of training.

A good firm will have a defined budged that will allow for adequate training of all there consultants. Actually, it is in their best interest to keep you trained as you become more marketable.
What is the 'standard' number of billable hours you expect?
What is the standard number of hours do they expect you to bill for in a giving year? Is it 1800, is it 2000? This makes a difference because if they tell you 2000+ then are telling you they EXPECT you to work over time (more on that below).

A full year with no time off is 2080 hours (52 weeks * 40 hours). But if you get 2 weeks vacation and 10 paid holidays you are only at 1920 (48 weeks * 40 hours).

Again, now keep in mind that the 'standard' number is just a rule of thumb, but it is good to know. The higher the number, the less room in the budget they may have for when times get tough.

Also, keep in mind that during my 5 years consulting, my average work week was about 45-50 hours. So if you are looking for the 40 hours and go home, you may not want to do consulting.
How are bonuses/raises calculated?
Do they give bonuses/raises? Are they based on billable hours? If they are based on billable hours, that can be good and bad.

Example. My old firm would give a flat bonus, but if you worked 200 extra hours a year you got a bump, if you worked 300 you got an extra bump, etc.

This is good because i knew that the more i billed, the larger my bonus.
This was bad because i only got a sliver of the extra billable hours and in the long run did not pay off in the end.
How does overtime work?
Some firms don't do anything special for overtime (as is the case in most salary positions). However, some will actually pay you extra for your overtime (these places typically don't give bonuses). Other places bank your overtime and build that into your vacation (worked out well for my buddy).

But i would say that most common is that nothing happens with your overtime, except the companies profits increase at your expense.

Thing you have to accept as part of the job

The tech/environment will change with every new client
With every new client/project your environment along with the technology will change. For some people this is a show stopper, for others it is just another chance to learn.

Keep in mind that if you work on site at the client you will be expected to follow ALL their rules. So if they are business formal, you will be expected to dress in business formal. If they say you cannot come in till 9 and must stay till 6, then that is what you must do.

If you are not willing to accept this, then consulting may not be for you.
You may not always be working on 'cool/fun' tech
Since each project may change technology you may not always be working on 'fun, cool' stuff. You may go from doing cutting edge development on project to doing report writing on the next one.

If you are not willing to accept this, then consulting may not be for you.
You are the '***' of the client, at their mercy
Since you are a 'hired gun' you are the mercy of the client. Don't expect to have the same treatment as full timers (a lot of places today treat their consultants as part of the family, but not all). Don't expect to get subsidized meals (if offered) or gym memberships, etc.

Also, be ready to work in some of the worst spaces you can think of. On place i worked the consultants all sat in a single 15-20 office. They basically lined up desks along the wall and filled it with 6 people. I felt bad for them :).
The people you will meet
The coolest part is the people you will meet, the connections you will make. This is great because networking is the best way to move ahead in this business. I have meet some great people and have made some great contacts.

This was my 2cents to him.

Did I miss anything? Am I wrong? Let me know

Till next time,