Starting another journey, again

I've finished one leg of my journey at Oakton www.oakton.com.au and have decided to return to my old company www.ssw.com.au to continue my consultant dream.

The reasons are long and numerous, but I'd just say that the biggest factor is there was a really good situation for me and I grabbed it before the window of opportunity disappeared.

In a sense I feel I've learned a lot in the three years I've spent wandering around in the wilderness, I've experienced:

• Product development - where I'm not doing consultant work
• Contract work - where there's excellent money but difficult career progression, or choice of technology
• Working with teams on different time zones
• Big team development - working in a 20-man team is fun too, but with lots of draw backs.
• I've worked with proper BA now.  Finally!  Big thank you to the Vero BA's, you know who you are, wherever you are now.
• Big complex organisations
• Enterprise level projects
• I nearly jumped in with a startup and would have definitely done some fun stuff, but I just don't know if I'm ready to settle down on one project

But some things remains the same

• Agile rocks
• Waterfall flops
• Unit-testing is great
• But hard to do in a web app
• Windows application is sweet
• Until you gotta deploy

(Thanks to Dinesh for fixing the rhyme on "flops" for me - second line)

I leave my old colleagues with what I've always firmly believed consultants do

• We work hard, we write good code, and at the end of the day, the clients are happy and we are happy.

So with a happy fondness for all the great memories, I bid my old colleagues farewell for now.

Your windows service started and stopped

The name-of-your services on Local Computer started and stopped. Some services stop automatically if they have no work to do, for example, the Performance Logs and Alerts service.

I had fun with this one for a bit.  Developing Windows Service is one of those "I rarely do this" activities.  So when I got one of these errors when I start my service, immediately I switch into "Ah I must have forgotten something" mode.

• May be the process started and didn't do anything and finished
• May be the timer didn't go off
• Perhaps I need to spawn a thread to listen / sleep

I couldn't attach a debugger to the service given that it doesn't stay running.  So that limited my options a bit.

Turns out, the "informational message" was pretty misleading, I had the following in my event log.

Service cannot be started. System.NullReferenceException: Object reference not set to an instance of an object.
   at MyService.MyService.OnStart(String[] args)
   at System.ServiceProcess.ServiceBase.ServiceQueuedMainCallback(Object state)

Oops.

Fixed that error, and the service starts successfully.

this.consulting.life

Being a consultant is:

• Walking on a tight rope
• Crazy business requirements people on one side
• Poor internal dev teams (the maintenance guys) on the other side
• I try to be nice to my fellow devs, they deserve a great system to work with, not a hacked up thing
• Dual-Whip-wielding project managers chasing you from behind (think: Balrog)
• (Though to be honest, they are probably chased by stake holders)
• And if your project is slightly short on money, you might as well dose the whole circus in petrol and set on it on fire.

---

Mark: When you charge a fortune

Mark: The clients expect a miracle

John: So we are "miracle workers"

Mark: Pretty much

---

Client: We have a situation here

Client: One miracle worker may not be enough

Client: We need a team of Moses, to part the Atlantic ocean, cause this thing is sinking pretty fast

---

There are good consultants and great consultants.

• There are crap ones - those that talk a lot and never get anything done.  To me these people should stop dirtying our work and go find something else to do - they give consultants a bad name.
• There are good ones - those that gets things done but are too expensive.
• I don't defend the cost of consultants - the service and the skills are what's being paid for.  But I think a great consultant is one that gets things done, and simultaneously manages the client's expectations appropriately.

---

A consultant (especially an expensive one) is a secret weapon used (usually by newly-appointed upper management) to wedge open layers of old office politics to introduce change.

It is often excruciating for the consultant.

A consultant has to preach new technology, methodologies and win converts.

People do not like change.  They will resist change.

Sometimes they will threaten to leave, and blame it on the consultants.

Ultimately, the company will realize the changes were for the better, but the consultant is never around by then to see the benefits come to fruition.

---

A process takes an internal dev guy 5 days to do.  Because he needs several permissions and find a time that's suitable for everyone involved to have a meeting.

It usually takes an external consultant 2 hours to come to the same decision.  Because an expensive consultant is too expensive to keep around for 5 days.  Management will move mountains, switch appointment times, even *gasp* cut short their lunch break to make a meeting.

Price tag is everything.

Quick tip: Initialising Dictionary inline

var dictionary = new Dictionary<string, string>
{
{ "key1", "value1" },
{ "key2", "value2" },
{ "key3", "value3" },
};

var list = new List<string>
{
"value1",
"value2",
"value3",
};

You might notice that I like to leave the comma behind the last element in my inline initializers - this is actually unnecessary.  But having it there means that I can copy/paste entire lines and move them around without worrying about missing comma right at the end.

For example, this is valid code:

var list = new List<string>
{
"value1",
"value2",
"value3"
};

But if I had to swap the order of the elements and end up with this code, this is not valid.

var list = new List<string>
{
"value1",
"value3"
"value2",
};

Generic EventArgs implementation (but isn't really all that useful)

public class EventArgs<T> : EventArgs
{
private T t;
public EventArgs(T t)
{
this.t = t;
}

public T Value
{
get { return t; }
set { t = value; }
}
}

To use this class:

public EventHandler<EventArgs<String>> Notification;

protected void OnNotification(string message)
{
var handler = Notification;
if (handler != null)
{
handler(this, new EventArgs<String>(message));
}
}

While this code is all nice and dandy, I wonder if it's all that useful.  One of the things with custom event args is that they may grow over time, and this implementation doesn't support future scenarios that well.

My colleague Dinesh mentioned that perhaps I'll end up going down the Func<> route, ie:

EventArgs<T>, EventArgs<T, U>, EventArgs<T, U, V>

Personally I think that's a bit challenging:

If I had to add an future int property to my EventArgs<String>, changing the event to EventArgs<String, int> doesn't automatically fix the issue - as all my event hooks will now stop compiling, because EventArgs<String, int> doesn't imply it inherits from EventArgs<String>

Anyway, nice looking bit of code but I'd say not greatly useful.