Apr
24
2012

Consultants vs Permanent Hires

Over the course of my professional career, I've had the ability to both work as a consultant and as a permanent hire at various firms. I've actually been able to transition from a consultant to a permanent hire at the same company at one point in time. I've been witness to both successes and failures with consulting. Here are a few of my take-aways.

Consultants are subject matter experts, not experts of your business

Consultants are paid to help your company accomplish a particular task. They may be brought in for a specific set of skills that your company does not feel the need to keep on staff. Or, they may be used to produce a particular deliverable. They, however, are looking out for the best interests of the consulting firm they are working for. This means that while they will want to deliver a high quality product, they are not looking out for your business's best interests long term. When decisions need to be made that have a broader impact they must be made by someone permanently hired by your company. It's easy to fall into the trap that "the consultant knows best", but their knowledge is on the particular field/task not on the best decisions for your company. Corners may be cut to meet a project due date, when the best decision decision for the business as a whole is to extend the length of the project. Without permanents hires acting as champions for the business, the wrong decisions may be made.

Consultants will leave

Unless you're planning on a contract to hire, once your consultant's contract is up, they are going to leave. With them, they take a bank of knowledge that now likely needs to be transferred to a permanent employee. Moreover, you've spent nonproductive hours getting them up to speed on the project that you're now going to likely need to re-spend on another individual. The experience that this consultant has gained is now leaving the company, and you're going to have to pay someone else to acquire it.

Permanent hires have non-project tasks

One of the biggest benefits of consultants, is that 8 hours of their time means roughly 8 hours of project/task work. While this would seem to be true for any employee, permanent hires are often responsible for other tasks. These tasks may include maintaining objectives for HR, attending team building activities, participating in department/office meetings and the list goes on. While these activities benefit the organization as whole (or if they aren't, should be up for review), they are not furthering the project at hand. If you're estimating a task to take 40 hours, the consultant is far more likely to get it done in one week than a permanent hire.

Permanent hires are not accountable on a hour by hour basis

Typically, your permanent hires will be salaried. This gives the flexibility to your permanent hires to work how they work best. It also means that high levels of support one month isn't going to add additional cost to the department. Consultants generally bill each hour. This allows to more carefully track a project's expense, but isn't as forgiving if additional work comes up. You may push your permanent hires to work additional hours for a time period to meet a particular objective. Doing so with consultants is going to require additional capital. However, consultants are also much more accountable for what they are billing, and you're more easily able to challenge if they are performing the work they are billing for.

Summary

In the end, there is room for both consultants and permanent hires in most IT ecosystems. The struggle will also be finding the right balance. From my experience, consultants should be brought in for specific knowledge gaps, or for short term staff augmentation when a project calls for it. Using long-term consultants as your primary IT solution can lead to poor solutions for the business in the long term and a wealth of knowledge that could walk out the door.

On a personal note, if you're looking for IT consultants in the Fox Valley, WI area, feel free to message me, I'd be happy to provide a referral.

Feb
13
2012

Using the Format Property rather than an Expression in SSRS

When I started developing in SSRS, I quickly learned the power of the expression. Using expressions I could aggregate data, run various mathematical operations and format data. It's the later that I'm going to dive into a bit here.

As a programmer, when I begin using a new tool, I'm looking for ways to have the most control over what I'm doing. This often means trying to find a SQL editor, or something like the expression editor within SSRS. As you can see in the screenshot below, there are plenty of operations we can perform on a piece, or pieces, of data through the expression editor.

Having discovered this expression editor, I typically was doing my formatting using the various Text Functions for formatting. However, I was editing a report a colleague of mine made, and noticed that formatting was occurring despite no expression being declared. It turns out they were using the Format Property of the text box itself, rather than an expression.

This format property is actually much easier to work with, because you can select multiple textboxes and apply a format property to all of them at one time. The question remained, what was the effective difference between the two methods? When the report is run, the results are virtually identical. I pondered this, and eventually opened this question on Stack Overflow. A quick response later, and it turns out, one of the biggest differences is when the report is exported. Any columns that have had an expression defined with a "Format" in that expression is treated as a text column. However, columns with a format property can export as a numerical column with a format applied. This becomes very apparent when you attempt to use Auto Sum in Excel. See below: 

Row 4 has AutoSum applied to columns A and B. It has AutoAvg applies on columns C and D. Columns A and C were generated using the Format Property and no expression defined. It's clear that the columns are treated as numeric and thus the math formulas succeed. Columns B and D are defined as text and thus the math formulas fail. There are also green earmarks in these cells to warn the user that numeric data is being treated as text.

With this in mind, the best practice is to use the Format property as much as possible. It will make exporting much cleaner. However, if you need to do custom formatting, the expression editor allows for much more flexibility.

Have other use cases for one method over the other? Feel free to leave them in the comments!

Oct
14
2011

Visually Determine Changes Between Versions of SSIS Packages

One of the greatest tools to come to application development has been source control. If you've ever worked with a project before and after introducing source control, you'll know just how valuable it can be. One of the benefits of this tool is the ability to compare versions of source files to determine what has changed. When working with code files, this works great. At a glance it's easy to determine what's changed and what the new code is doing. The challenge comes when working with non-code files, such as the dtsx files that SSIS packages are stored in.

The good news is that SSIS packages are stored in XML and a text comparison is possible. If you're going to go this route, I highly recommend using a third party comparison tool. Visual Studio supports using a third party tool to do the comparison, and I highly recommend Beyond Compare to do this. It's supports three way merge to use when performing code check-ins. I'll be posting a follow up blog post on how to install Beyond Compare into Visual Studio. The main difficulty with this approach is that SSIS is a visual tool, and it can be difficult to discern differences from a series of text sections.

This is where having multiple workspaces can fill the gap. Visual Studio Workspaces are defined in the Source Control Explorer as seen here:

If you've been working with Visual Studio, you've likely already set up a workspace that you prefer to use. The workspace is simply a mapping from a folder on source control to your local computer. In order to perform the comparison we're looking for, we're going to create a second workspace using the same source control folder as your main workspace, but selecting a second location on your hard drive. I simply create another folder next to my existing mapped folder and append "_BACKUP" to it. 

Now do a "Get Latest" with the new workspace created. What this does is create a second copy of the source control files on your hard drive. With this in place, I perform comparison by the following steps:

  1. Open the solution in visual studio from the standard (Non-BACKUP) folder
  2. Make the requested changes
  3. Open up a new instance of Visual Studio
  4. Using the new instance of Visual Studio, navigate to the BACKUP folder and open the same solution file
  5. With both Visual Studio instances open, you can compare the changes side by side
  6. When your satisfied of your change, check it into source control from your first Visual Studio
  7. Perform a "Get Latest" on the backup copy so that it also gets the change
Using this process you can continually compare SSIS changes visually. If you want to compare different versions than the latest, just perform a "Get Specific Version" on your backup copy, and compare it to your main copy. This technique is best for trying to understand what was changed at a high level. If you need to see precisely what changed, down to a character level, the textual compare is still your best bet.
 
Thanks for reading and feel free to send any questions my way!
Sep
20
2011

Adding and Using a Linked Server

One of the most common tasks when managing databases is data transfer between them. When this process is complex or involves different kinds of data sources, I usually recommend a tool such as SQL Server Integration Services (SSIS) or Pentaho. However, sometimes a quick transfer option is needed between two SQL Server instances without the overhead of building out a full ETL solution. This is where linked servers can jump in.

A linked server is a virtual connection that allows one instance of SQL Server to know about (and query) another. This then allows fully qualified queries that can references tables across servers. Before diving into creating one these, it should be noted that the you must be a SysAdmin on the SQL Server instance in order to create a linked server.

To start, expand the "Server Objects" node under the selected instance within SQL Server Management Studio (SSMS).

Note that we have a folder for linked servers displayed. Right click this folder and select "New Linked Server" which will bring up the following dialog.

Within this dialog, the first option to select is either SQL Server or "Other data source". The other data sources include several OLE DB options. Typically, I only recommend using linked servers when you can select the SQL Server radio button. I'm unsure of the exact behavior of the "Other data source" and generally avoid it. 

With SQL Server selected, type the name of the server that you would like to link in the text box at the top. The next step is to set up the security for connecting to the remote server. A Local Login will need to be added. Here's a quote from MSDN regarding adding this login:

Under Local Login, select a local login account to connect to the remote server. Check Impersonate if the local login also exists on the remote server. Alternatively, if the local login will be mapped to a remote SQL Server login you must supply the Remote User name and Remote Password for the remote server login.

I typically select the account I want to use locally under the Local Login column, then select "Impersonate" as I'm often using domain accounts. The Remote User and Remote Password are used if you wanted to use SQL Server Authentication. The second half of the security page allows you to define a default connection to use for logins not listed in the table. If you'd like the logged in user to attempt to connect to the remote server with their log in, select "Be made using the login's current security context". The last option basically allows a connection to be made with a hardcoded username and password regardless of who logged in to the local (non-linked) server. This option is the least secure, and I don't recommend using it.

With these options finished, click "OK" and a new item will appear within the Linked Servers folder corresponding to the server name you entered. To query this linked server, we simply reference it from our query as seen below:

SELECT *
FROM [DAXSERVER1].[DAXDB1].[dbo].[CUSTTRANS];

From this fully qualified query, one can see that I'm querying the DAXSERVER1 SQL Server, with the DAXDB1 database and finally the CUSTTRANS table within the dbo schema. Now, if you've got access to create a linked server to DAXSERVER1 why not just connect to it directly with SSMS and query it there? If all you're doing is querying, then a direct connection is definitely more appropriate. However, as I mentioned earlier, this is very helpful for data transfer. See this query:

SELECT *
INTO [dbo].[CUSTTRANS_9172011]
FROM [DAXSERVER1].[DAXDB1].[DBO].[CUSTTRANS]
WHERE [CLOSED] = '';

This query actually transfers the records from the CUSTTRANS table (where they don't have a closed date) to a table named CUSTTRANS_9172011 in the local context. This can be used to copy data off of the production server, onto a separate location to essentially "freeze" the data for a point in time. This is extremely helpful when working with very rapidly updating data.

I hope this sheds some light on how to create a Linked Server as well as how one can leverage them to expand their querying reach without having to use another tool.

As always, I welcome any questions/comments below!

Sep
7
2011

Quick Plug for SQL PASS Training

For those that don't know, PASS (Professional Association for SQL Server) is currently holding their 24HOP (24 hours of PASS) training today and tomorrow. This is comprised of 24 one hour training sessions. These are extremely informative and are a great way to gain an insight related to a specific SQL Server topic. Registration and information can be found here. These sessions serve to whet one's appetite for their PASS Summit which takes place October 11-14th. While I haven't made it to the summit before, I can say that these short training sessions are extremely valuable and are best of all, free!

About the author

Something about the author

Month List