Kirk Haselden

Loading variable values from a file...

This is another question that comes up a lot. How do I load a file's contents into a variable. This is one case where the script task comes in very handy.

Drop a script task on the designer and add the following code:

Public Sub Main()
        Dim errorInfo As String = ""
        Dim Contents As String = ""

        Contents = GetFileContents(Dts.Variables("FileName").Value, errorInfo)
        If errorInfo.Length > 0 Then
            MsgBox(errorInfo, MsgBoxStyle.Critical, "Error")
            Dts.TaskResult = Dts.Results.Failure
        Else
            MsgBox(Contents, MsgBoxStyle.OKOnly, "File contents")
            Dts.TaskResult = Dts.Results.Success
        End If
	End Sub

    Public Function GetFileContents(ByVal filePath As String, Optional ByVal ErrorInfo As String = "") As String
        Dim strContents As String
        Dim objReader As StreamReader
        Try
            objReader = New StreamReader(filePath)
            strContents = objReader.ReadToEnd()
            objReader.Close()
            Return strContents
        Catch Ex As Exception
            ErrorInfo = Ex.Message
        End Try
    End Function

Now, create a couple of variables. I've named them FileContents and FileName. Make sure they are of type string.

Set the value of the FileName variable to point to the fully qualified file name of the file with the text you wish to load into the variable.

Run the package and a message box will show up with the contents of the file.

Hope this helps,

Universe.Earth.Software.Microsoft.SQLServer.IS.KirkHaselden

Outsourcing experiences...

Introduction

I've had some experience with outsourcing now and wanted to share some of that experience. While I wouldn't wholly condemn the outsource model, I have seen other teams experience and personally experienced some of the problems associated with outsourcing. I don't contend that my observations are in any way scientific or complete. I offer these observations as a simple reflection on our experience that hopefully, other teams can learn from and improve on. My opinion on this is absolutely my own and I do not speak for Microsoft in any way.

We outsourced some of our work. I know of other teams that oursourced similar loads and up to entire projects. One team I know of outsourced 10 components. Of those 10, only 3 remained in the product and were at risk of being removed as well, for various reasons. I know of one team that was entirely outsourced to a vendor and it was a disaster, and another that was a smashing success. Our team outsourced ~6-7 components. All have undergone substantial code reviews and code reworks since being dropped as "complete" from the vendors. Some of this is due to the mere fact that static components don’t mesh with an ever evolving product. Most of it has to do with the fact that we didn’t establish firm and clear guidelines and controls early enough in the cycle to catch these issues when the vendors were still engaged.

Experience

We experienced a lot of problems with outsourcing, but I can't describe them all here. So, I'll stick with just one. The most problematic were that sometimes the outsource vendors would make design or architectural decisions without consulting us. Some of the time, those decisions were appropriate and well thought out. Sometimes they were not. Often, they would try to contact us and get feedback, but communication over an ocean and time differences make that very difficult. We would be at the end of a long day, and they would be at the very early beginnings of the next. You might say our bio-rythms just weren't in sync. In most cases, our team was dead tired and just wanted to go home. This is an aspect of outsourcing that rarely gets factored into the accountant's worksheet. Also, managing in this way is difficult because the working style was so different than what we experience at Microsoft. At Microsoft, groups are close together. Due to a fortunate and timely recent move, my development team are all very close, within a few doors of my office. This makes if very easy to "pop-in" for a question or ad-hoc discussion. Meetings are a simple as well. The tester for our team may be just down the hall and as she walks by can overhear a conversation and join in. A conference room is not more than twenty steps from my office. This makes it possible to pull together large meetings in a relatively quick fashion. It happens all the time. So, we're all fresh, we're all close, we're all "in our game" and we're all available.

Contrast that with the outsourcing model and you begin to see the intangible but problematic elements of outsourcing more clearly. To do something similar with my outsource partners, I have to wait until around 8pm. I have to send mail that day and hope they get in around 6 or 7 in the morning so they get the mail and call. Then, I could never remember how their time zones work in India. I could never remember if they are 30 minutes ahead or behind. 8:00pm our time turns out to be 8:30am their time. We're all tired and most have gone home. So, if problems or questions come up that need input from one of our team members, chances are that they're already gone.

This is just one of the problems we experienced. There are others. I've enumerated some of them below. It's good to be aware of these issues.

It's not all bad though. Through better management practices, better planning, better allocation of work and a better understanding of these problems outsourcing can be an advantage. I've enumerated some practices below as well.

Problems:

• Differences in time zones, language barriers, differing vacation schedules, holidays, holy days, and other such disjuncture.
• Long distance or email discussions are never as effective or efficient as eye to eye discussions.
• Differing priorities. They want to get it done as fast as possible. We want it done “right”.
• Decision turn-around often delayed on the order of days because of above issues.
• Management of vendor teams is more time and resource intense because of above issues which creates more burdens on management.
• Security issues - "They need access to our source code? What?!?" While mostly a legal and policy problem, still requires attention.
• Network issues - Then need to be part of the domain etc. While strictly a technical problem, it's nevertheless something that requires attention and management.
• Cost savings are offset by cost increases for flights, long distance calls, and other immeasurable costs like team frustration and diminished morale.

Positives:

• Undesirable work such as mechanical, repetitive or other types of tasks can be shifted to vendors.
• More substantial work can be shifted to vendors if proper management practices and controls are established
• Vendors that provide the full suite of functional teams, ie. architectural, test, dev and pm functions and if the vendors are willing to sign up for long term contracts, they can function well as virtual subteams. 

Elements of Success

• Establish high quality initiatives and policies _before_ signing the contracts.
• Build sustained engineering elements into the contracts.
• Roll vendor teams into overall team structure so that they are looped into all policy, process, priority and schedule decisions. They must be part of the team.
• Ensure that there is local (in city) representation with authority to effect changes in the vendor processes, including and up to change of vendor team structure and membership.
• Do not use vendors as a way to augment feature set.
• Do not create additional work because there is remaining outsource budget.
• Development work must be managed by developer managers. Test work must be managed by test managers, etc.
• Vendor teams must be on the same timeline and constraints as the rest of the team.

There are ways of making the outsource model work. Just be aware that there can be serious problems with it and how to work around them.

Universe.Earth.Software.Microsoft.SQLServer.IS.KirkHaselden