ASP.NET MVC v ASP.NET

Having used ASP.NET MVC since it was in Beta in 2008, I am asked every time I mention those extra three letters why you'd bother moving a mature ASP.NET application to the new framework.

ASP.NET MVC is a framework that helps you build applications (note: I did not say web applications only) in a Model View Controller pattern. It breaks your applications presentation layer in to three distinct parts: The Model is the data. The View is the presentation. The Controller is the glue that holds it all together and manages interactions.

Traditional ASP.NET Application Architecture

In a classic ASP.NET application, the application logic is presented up to consuming applications through an ASP.NET container that returns web pages. If you want to access that logic through another consuming application that isn't web based then you implement web services that allow API access to that functionality. This is what you'd do to allow Javascript calls from your web application that didn't want to go through full ASP.NET page lifecycles to get standard HTML page data. Getting a JSON response is usual for an AJAX type call.

ASP.NET MVC Application Architecture

With ASP.NET MVC, one fundamental thing has changed. The ASP.NET application takes an HTTP Request and returns an HTTP Response of any type. That means that it can return HTML+CSS+Javascript to a browser if that is what it asks for or JSON or XML or any data format you want. It is just a generic HTTP response.

What this means is that you no longer have to build separate web services to expose application logic to consuming applications that do not want standard HTML. Those applications instead make requests and the ASP.NET MVC application is extended to process those requests and return whatever is required. The consuming application can be Windows-based, a mobile application, another web service or pretty much anything you can imagine.

There are a lot more differences between ASP.NET and ASP.NET MVC but this is an architectural one that will save you a lot of implementation time. Instead of wasting time on software infrastructure and scaffolding, you concentrate on writing business logic and exposing that business logic in consumable ways.

It is totally worth considering if you are have a greenfield project or are moving to later versions of .NET and are reconsidering ASP.NET.

Troubleshooting is Technology Agnostic

There is a concept of Technical Depth within Microsoft. It describes how well a person understands a specific technology. It focuses on specialisation in a domain.

Our straight out of university graduates sit around 100 depth. Our beloved Evangelists sit at 300-400 depth but posses impressive breadth of areas of knowlege. Premier Field Engineers sit at a depth of at least 500. The guns of Microsoft who know things inside out are referred to as CTS. They sit at a depth of 700. Ask them a question on a specific technology and they will recite the code to you. It is awe inspiring.

There have been many situations that I have been called to that required me to act as a problem solver and quasi therapist on. Usually, the client was in a horrid position where they felt they needed Microsoft to bring sanity to the overall moment.

I am a developer. In Microsoft, my role is as a Developer Premier Field Engineer.

In the situations that have required that I march onsite within odd working hours and when the sky is falling, me being a developer seemed essential. The truth is that on these occasions, they did not need a developer. They needed a problem solver.

Often when the sky is falling and your managers, your big big managers, need everything sorted then that is when you call for us. You want a voice of reason. A voice of order that bring calm to a situation. It never seems to matter if I am an expert in WCF or low level debugging. It is more having a person who can clearly see through the haze of panic that brings calm to the situation.

That doesn't mean there aren't people on the ground with that skill. It just means that the kudos of being from the Big M seems to hold some sway. It helps temper the mood. It lets us belay the journey to the solution.

There is merit in this skill. In the skill of slowing the moment and redirecting the effort. There is benefit in working towards a goal in Matrix time.

It has taken me a long time to understand the profit in reactive PFE skills. Now I see what we bring. We bring zen. We bring the martini with a twist. We bring calm to an angry ocean.

Microsoft PFE is trust and effort and knowledge combined. I like that idea.

I talk good, I does

Inside Microsoft, there are lots of different moving parts. The company is made up of around 100 000 full time employees. One of the newest but rapidly growing parts is Services. The group I work for sits under Services and is called Premier Field Engineering (PFE).

Premier Field Engineering does not sit under a subsidiary like Australia but instead exists under a global group. It is different to other Services parts like Microsoft Consulting Services (MCS) who do belong under Australia.

This design certainly gives us a lot more mobility and the ability to act as a pool of resources for other parts of the business.

In the world, the Universe and everything at last count, there are 3009 Premier Field Engineers (PFEs).

I have been with PFE for just on 9 months now. At the 7 month point, I was nominated for an opportunity called the PFE Industry Leadership Program. It runs every six months and this is the second round.

Out of 3000+ PFEs, 32 of us were nominated by members of our local PFE management group for being current and often loud participants in the areas of 1) blogging and online presence; 2) public speaking at conferences; and 3) video presentation skills.

When I was nominated, I was chuffed until I found out that I had a month to produce a blog post (easy copy-paste job from my blog), a short Powerpoint presentation (oh no, I don't do short presentations) and an even shorter video (see previous "oh no.."). Nothing in life is free and for me, nothing in life is harder than saying what I need to say in a very short amount of time. For me, filling an hour with building rapport, articulating technical content and allowing time for digestion of the information and questions is what I do every day and what I do very well. To be asked to achieve a similar outcome in a shorter time scared the hell out of me.

It frightened me so much that I left the tasks until the very day that they were due.

Now, that doesn't mean that I didn't put effort in to them. If anything, I put a short and succinct amount of effort in to them. Without too much time to over-think it all, I had to put what I had to say in to a little space within a small amount of time. I think that made it easier, rather than harder.

In my life, I have spent a lot of time painting. For what I lack in talent, I make up for with enthusiasm. One important thing I learnt a long time ago when I started to embrace my inner artist was to know when to stop. Perfectionist are awful at that. We want to go and go and go in a quest for unattainable perfection. In this case, I made the videos and honed them and then stopped. Without one of those big Ang Lee panorama cameras on a big pole with a chair I could sit in, I was not going to make a Tropfest winning short so I stopped with what I had and moved on.

A couple of weeks later came the interview. New rules were instigated so that you would not be interviewed by anyone from your own region. My interviewers were a PFE manager in Bangalore and a PFE with god status, also from India. It was a one hour interview with a lot of challenging questions about how I do things and why. It took only 29 minutes and I figured that I was either awesome or completely rubbish.

Two weeks later again and my boss texted me to say I'd be heading to London for a week of training with a company that specialises in making people great presenters in all the areas I mentioned above. People pay a lot of money to be trained by them. They aren't Microsoft people. They are an external group. PFE is funding the whole thing and investing in the 16 PFEs who were chosen.

The reason I am telling you this is because I am pretty proud of myself. Not as hugely proud as my family is but still pretty stoked about getting this chance.

Out of 3009 PFEs in Microsoft and 516 in Asia, I competed and won a place to extend my current skills in an area that I do just for the fun of it.

I am famous for sharing my first world problems and complaining about how work isn't funding a handsome underwear model to rub my feet while I work from my home on a yacht in the Greek Islands. Ok, that isn't true. He's just a jeans model.

The point is, I like blogging and talking at people and presenting and improving those skills constantly. I like sharing the passion and the knowledge and the opinions with those funny people who for some reason read what I write. This is something I do for no benefit than my own sense of contributing and participating. For the first time, I am being actively encouraged to do so and to learn more.

Well done me. Now I'm off to London to visit the Queen.

Don't Virtualise Everything

There seems a need in the dev and the ops world to virtualise everything. Everything!

People talk of it as the second coming. We can scale. We can spin up any environment without over-preparing or extra investment or asking permission.

Like the cloud, talk of virtual machines solving every problem imaginable is all the go.

Like all new technologies, they bring you benefits but they are not the answer to everything.

Good engineering and common sense must always be applied, especially in times of wonder.

One place that you can not 100% virtualise is in testing.

Twice in the last four months, I have had to walk in to situations where the issue was testing an app in an updated SOE that had only been tested in a purely virtualised test environment.

One had issues with drivers and the other with an out of date BIOS version.

When you are running in a virtual machine (VM), it is an emulator. As much as possible is handled inside the emulator but one thing that makes a VM so portable is that it is piggybacked on the host operating system. One thing you can count on is that when it falls back to embedded calls to hardware that it falls back to the native OS and its drivers.

Underneath that is the BIOS and although you can mostly count on that, nothing is guaranteed.

In the two cases I saw, the problem happened under load and pushed the boundaries that would never have been tested because it was impossible to simulate in a non-native environment. Although operating systems were tested, bespoke applications were assumed to pass all tests if they did so inside the VM.

There is no need to test everything outside of a VM though but you should at some point in the testing journey. My suggestion is...

Unit test in a VM.
System of Integration test in a VM.
Functionally test in a VM.

At least Performance or Hardware Integration test on the native hardware with the native operating system.

Nothing beats reality.

Nothing.

Agile Explained

Why I'm an Engineer and Not a Pastry Chef

On the Internet, people joke about First World Problems (FWPs) when they stub their toes on their BMW run-flat tyres while wearing their new Louboutins, in an attempt to avoid stepping on their Paspaley pearl earrings.

On my team at work, we have PFE World Problems (PWPs). They make an FWP look like torture. As a job, it isn't so bad. I'd go as far as to say it doesn't suck. It is time I reminded myself of that.

My latest PWP was hitting what in Microsoft is called the 7 month itch. No jokes about antibiotics please. It is a point when after being at the company for a while, you are passed the honeymoon period and straight in to the everyday work ritual.

When people told me I would hit this, I sniggered. Well, it was probably more of a giggle but now I find myself sighing mostly and realising that Monty Python was right in the Life of Brian...

Brian: No, no. Please, please please listen. I've got one or two things to say.
The Crowd: Tell us! Tell us both of them!
Brian: Look, you've got it all wrong. You don't need to follow me. You don't need to follow anybody! You've got to think for yourselves! You're all individuals!
The Crowd: Yes! We're all individuals!
Brian: You're all different!
The Crowd: Yes! We're all different!

Truth is that joining a big company with so many possibilities is awesome to start and keeping that momentum going is up to you. In this case, it is up to me.

I identified the two things that are not Mana-friendly and now I must find a way to fix them or get out.

They are...

The Lack of Team (the journey)

PFEs work mostly on their own. What I do is called transactional work. You go in and provide knowledge or a solution or give someone a hug and then you move on to the next client. Those who are lucky like me, go back to the same clients and sometimes the same systems.

If you've met me IRL then you know that I can build rapport with anything and anyone from a CIO to a dev to a grumpy crocodile to a brick wall in under 3 minutes. All of that comes from genuinely caring about what clients want and how to help them achieve that. My work is not about me being a superstar or about credit or acclaim. If I wanted that, I wouldn't be in PFE. I'd be a pastry chef.

Anyway, you build rapport and you like the cause. You work towards the cause and you actually add value. Then you leave and start all over again. It is fun but it isn't the same as being part of a dev team building software.

This means that I have to find a way to belong. A way to feel part of something without being in the middle of a dev team slaving over the coals. That's my first action item. I must find a way to enjoy the journey that satisfies the way I like to work... with people.

No Finish Line (the destination)

Ask anyone who identifies as pragmatic and they will tell you that delivering something from start to finish is more satisfying than gold plating or talking about it for ages.

In my current day to day work, there are very small blocks of work that I have to complete. People often say they like the work but not the wrap up report or presentation at the end. I love it all. I love the start, the middle, the race to the finish, the wrap up and the bloody post mortem.

As an agile dev, breaking down big things in to small achievable parts is a talent I have. I can deconstruct any requirement and put it back together, while holding the holistic view and goals in my head.

There is my second task, to find a way to take on bigger chunks of work that let me satisfy my need to build awesome stuff.


It took a lot of sulking to come to this realisation. It also took a colleague to give me a good slap and tell me to step up and do something about it. I am often that person to others but oh so famous for not taking my own wicked advice.

Thank you, unnamed colleague. You are lucky there is a continent between us :)

Now to make it better or get the hell out.

Team Players Are Worth More Than Superstars

A lot of time, I am involved in putting teams together and getting them to mash.

Sometimes, I am given the raw materials and have to make the most of what is given me.

Other times, I get to pick and choose and use excuses like "we need the best combination to deliver what the client wants."

Often when we hire developers, we look for technical skills and client facing skills and design skills. This is all well and good as long as we also look for collaboration skills.

The environment that I play in is full of superstars who really do know their stuff. The thing is that when I'm choosing a team that knows my stuff, I want one thing in particular. You have to know how to collaborate.

A developer can know an API front to back.
A developer can talk about the intricacies of their technology stack.
A developer can describe everything they have ever built and impress you.

However, I want someone who can work with others.

I am not fussed if they are a member of Mensa or can recite 6 digit primes by heart. That doesn't make a useful developer.

What is most important is that you can work with others. You must be able to say what you have done. You must be able to describe your intentions. You must be able to write code that doesn't identify itself as yours but instead mold with the team.

Yes, there are so many average devs but a good dev who can communicate and collaborate will wipe the floor with them.

Be a good team player.

A superstar is worth nothing alone.