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.

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.

A camera of the future

In the future, when you take a picture of something, the camera generates a 3D scene of it and stores it in memory.

Camera will need 2 lens to work out the distances and generate the 3D model.

Camera will record and generate the textures that we can see.

When looking at the scene from the angle that the picture was taken at, the resolution is as good as a flat-picture camera.

Modelling the system

image

 

Here's a nice pretty diagram of the various components of modelling a (any) world.

In my case here, the world is a virtual world.  You would noticed quickly:

  • The strong MVC reference.  If you really don't see it, try look at the colours
  • World is made of models - which are actually no different from a business application.  The same model pretty much applies
  • SilverLight 2 Beta 2 has strong work done on the visual manager, which I think is best used to utilize for rendering the world
    • In fact, in most games, the graphics component is the main component, in my little model here, it isn't.
  • The command logic is largely work from WPF's command syntax - in a business application, this means we can wire up multiple events to the same command (aka, control-C, menu)
    • In the context of a game, it means we can offer key-bindings and the user can choose what keys he'd rather use instead of the defaults
  • The blue part is the least ironed out section of my little model here - in a pure MVC situation, perhaps the Commands should be responsible for directly making the calls to the server / modifying the game objects.
    • Should I wait for server response before making the object move?  or should I trust the client and let it start moving, and allow the server to 'validate' the client's behaviour

One final work remains in this modelling exercise:

  • Some sort of dependency-injection for making it all work in SilverLight, this way, I can work on each component one at a time and have them plug in/out
    • And unit-test separately
    • There's some good work in the AssemblyPart class
      • Not sure about security implications though

Lack of statistics for Windows spaces.live.com

The statistics capabilities for Windows Live wetted my appetite for better statistics reporting.  Why on earth:

  • Record only up to the last 3 days
  • No user detail breakdown - where from?  Unique visitors?  Returning visitor?
  • How are people finding my blog?  Word of mouth or blog reader or searching for keywords in Google where my blog showed up?

Anyway, the lack of statistics really is beginning to be a pain in the neck, makes me feel that no matter what I do, Windows Live spaces just doesn't support me to grow my blog, unlike other service providers like Blogger or WordPress.  (Both of them easily integrates with Google Analytics).

Which drives people back to use AdWords.

Sure we hate all things Google ;-)
But where's MS's offering?