Friday, June 01, 2007
12 Breeds of Client and How to Work with Them

I found this via UXMag.

It's advice to freelance designers but it works in so many different arenas. Consulting is the obvious play, but think about this in terms of your politics at your corporation and even in your personal life. If you've coached soccer or anything, you'll have at least 6 of the 12 types below as parents.

The twelve that he talks about with my own little summaries are:

1. The Low-Tech Client - This client is disoriented by tech and wants everything no the phone or fax.

2. The Uninterested Client - This client just wants you to handle everything.

3. The Hands-On Client - This client is disillusioned that they could do your job and will tell you so.

4. The Paranoid Client - This is the legal nighmare with NDAs and you fearing that you'll be sued.

5. The Appreciative Client - This client is sugary coated suger with sugar filling. It's not a bad life to be honest but don't get used to it.

   <update>A comment was made offline that one should watch the Appreciative client to make sure that they are not a "Stab you in the back with their management" client...</update>

6. The Get-a-Good-Deal Client - This client never saw a price or deadline they couldn't negotiate in their favor.

7. The I’ll-Know-It -When-I-See-It Client - This client will cause revision after revision after revision.

8. The Always-Urgent Client - This client thrives on drama and adrenalyn and everything is a fire.

9. The Decision-By- Committee Client - This client never saw a decision they could make.

10. The Doormat Client - This client lets you walk all over them.

11. The Budget Client - This client wants the same service for half the price. Similar to the Get-a-Good-Deal, but with less money.

12. The You-Should- Be-So-Lucky Client - This client will make sure that you know how lucky you are to be working for them and in the industry that they are in...

For each of these, he talks about How to Spot One, the Highs, Lows and How to Work With One.

For example, with the "Get a Good Deal Client", the How to Spot One talks about always haggling over procing and promising more lwork later. The Highs talk about repeat and referral business but the Lows are that you are constantly having to negotiate and might get taken advantage of. In the How to Work With One section he talks about coming in high and being very assertive on points of payment and workload.

All of this is absolutely priceless advice. The reality is that in a corporation or contract of any size, you're going to have a mix of some or all of the types above and you have to be ready to deal with that. You need to know who it is that actually writes the checks and who they have to report to. If your contact is an Appriciative, but their boss is an Always-Urgent, you need to know that and act appropritely. There's no point in satisfying your contact if the checks are signed and decisions are made higher up.

The question is, can you name your boss's type? What about your current contract?

Link to » 12 Breeds of Client and How to Work with Them

 

Technorati tags: ,

Articles | Consulting | Tangent
Friday, June 01, 2007 12:27:02 PM (GMT Standard Time, UTC+00:00)  #  Comments [2] 

 Friday, April 14, 2006
Security Focused Article in Visual Studio Magazine

I'm an officially published author now. It's very cool to see my name and BIO on article. I think that this will be the first of many.

This was a joint article between me and Gabriel Torok of PreEmptive Solutions.

It covers 8 specific ways that you can Reduce Your Code Vulnerability to various attacks.


Articles
Friday, April 14, 2006 12:55:05 AM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

 Monday, March 13, 2006
Keith Elder, .NET Pimp

Keith Elder used to be one of the biggest PHP advocates around. Now, he runs a site called http://www.dotnetpimps.net where he is the foremost .NET Pimp. He pointed out on his blog that he’s put up and article on why he made the conversion. More at http://dotnetpimps.net/blogs/theelder/about.aspx.


Articles | Development
Monday, March 13, 2006 3:11:11 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

 Thursday, February 10, 2005
NUnit Stands the Test - Follow up

Patrick Steele made a good point about my last post on Unit Testing. The code that I wrote just happened to use the Test keyword at the beginning of each of my methods. That’s not required. I just happed to like that convention because it reads well.

I do use the attributes and encourage everyone else to because, as Patrick also points out, TestDriven.NET and other tools don’t use it.

Look for another article on TestDriven.NET early next week.


Articles | Development
Thursday, February 10, 2005 7:33:23 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

 Tuesday, February 01, 2005
NUnit Stands the Test

Unit testing is only enjoyable and productive with the right toolset. NUnit is the foundation of this toolset. It is a unit testing framework for any .NET language.

NUnit leverages Reflection and Attributes to dynamically discover and execute your tests. The structure of a NUnit unit test is as follows.

Imports NUnit.Framework

 

<TestFixture()> _

Public Class DemoTests

    <Test()> _

    Public Sub TestGetIntegerFromConfigFile()

        'Some code that tests the desired functionality

    End Sub

End Class

 

You add the TextFixture attribute to notify NUnit that a class is a suite of tests. You add the Test attribute to mark a method as a single test case. You can have as many tests in a given test fixture as you want and as many test fixtures in a project as you want. The class that is the TestFixture has to be public and have a default constructor so that NUnit can use reflection to dynamically instantiate it. The methods decorated with the Test attribute have to be public, not take any arguments and return no values (Sub in VB.NET and void in C#) for the same reason.

The next step is to write the code that tests the desired functionality. It’s best if the tests are fairly straight forward and simple.

    <Test()> _

    Public Sub TestGetIntegerFromConfigFile()

        Dim demo As VBDemo.Demo = New VBDemo.Demo

        Dim result As Integer = _

            demo.GetFromConfigFile("MyValue", 0)

 

        Assert.AreEqual(1, result)

    End Sub

 

Assert.AreEqual is the really crucial bit of code from this test. This is one of several types of assertions. An exception of type NUnit.Framework.AssertionException is thrown if one of the assertions fails.

Assert.AreEqual(value a, value b)

Tests if b is equal to the expected value a

Assert.AreSame(reference a, reference b)

Tests if two references point to the same object in memory

Assert.IsFalse(Boolean)

Tests if the Boolean is False

Assert.IsTrue(Boolean)

Tests if the Boolean is True

Assert.IsNull(reference)

Tests if reference is Null as expected

Assert.IsNotNull(reference)

Tests if reference is something as expected

More complex tests can be accomplished with normal if statements and the Assert.Fail method.

If (Not SomeReallyComplexStatement) Then

   Assert.Fail()

End If

 

The code that this test exercises takes the name of a configuration setting and a default value. It will return the value from the configuration file or the default value. The test above assumes that the configuration file has a value as follows.

<configuration>

    <appSettings>

            <add key="MyValue" value="1" />

    </appSettings>

</configuration>

 

A small thing that I’ve discovered is that it’s helpful in cases where there is a config file that the tests are in a console application because VS.NET will manage the app.config automatically for you. In addition, if your tests are in a console application, they could be self sustaining and run whether someone has a NUnit test runner, like NUnit GUI, installed or not. You would have to call the tests from the Main of your console application. You know that the test failed when if there is a NUnit.Framework.AssertionException thrown. I have found that this is helpful in a “Clean” environment where developer tools are not allowed.

If the code is as follows.

Public Class Demo

    Public Function GetFromConfigFile( _

            ByVal settingName As String, _

            ByVal defaultValue As Integer) As Integer

 

        Return defaultValue

    End Function

End Class

 

And you run the test; the result will be as follows.

This is expected. Now you need to fix the code so that it will not result in a red bar.

Now modify the function as follows.

    Public Function GetFromConfigFile( _

            ByVal settingName As String, _

            ByVal defaultValue As Integer) As Integer

 

        Try

            Dim reader As System.Configuration.AppSettingsReader = _

                New System.Configuration.AppSettingsReader

 

            Dim resultAsObject As Object = _

                reader.GetValue(settingName, GetType(Integer))

 

            Dim result As Integer = _

                Int32.Parse(resultAsObject.ToString)

 

            Return result

        Catch ex As System.InvalidOperationException

            'Either the value didn't exist or it was not an Int32

            'Fall through to the default value below

        End Try

 

        Return defaultValue

    End Function

 

Once it is, you are rewarded with a green bar as follows.

Since the normal path is working, you need to test the alternative paths as follows.

There are a number of alternative paths that we can investigate. You can pass in garbage, Nothing (or null in C#), the name of an item that’s not an integer and so on. You could decorate the method with an additional attribute, ExpectedException, if we expected this code to throw an exception rather than handle all of its exceptions. For this example, you simply need the non existent config value and the non integer config value cases.

    <Test()> _

    Public Sub TestGetIntegerFromConfigFileNonExistant()

        Dim demo As VBDemo.Demo = New VBDemo.Demo

        Dim result As Integer = _

            demo.GetFromConfigFile("MyNonExistantValue", 0)

 

        Assert.AreEqual(0, result)

    End Sub

 

    <Test()> _

    Public Sub TestGetIntegerFromConfigFileNotAnInt()

        Dim demo As VBDemo.Demo = New VBDemo.Demo

        Dim result As Integer = _

            demo.GetFromConfigFile("MyNotAnIntValue", 0)

 

        Assert.AreEqual(0, result)

    End Sub 

Now you have a well tested function and tests that can be run over and over again.

We have covered the basics of setting up a unit test with NUnit. There are more features that we will cover in a future post. These include the ability to specify setup and teardown methods, categories of tests and suites of tests.

The code for this post can be downloaded below. It does require NUnit.


Articles | Development
Tuesday, February 01, 2005 2:35:12 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

 Wednesday, June 02, 2004
New White Paper

Articles | Compact Framework
Wednesday, June 02, 2004 9:22:58 PM (GMT Standard Time, UTC+00:00)  #  Comments [0] 

 Thursday, April 22, 2004
CodeDom Article

I know that it's not a really big deal to many authors, but I got my first article published on the Fawcette Reports web site.

I didn't know that it was actually published until I started getting emails about it - but it's linked below.


Articles
Thursday, April 22, 2004 1:53:43 PM (GMT Standard Time, UTC+00:00)  #  Comments [0]