Stop writing your own frameworks

I am in Darwin for Christmas. This is where I grew up, went to University and came back to work for a very short time in 2010 while trying to work out whether I wanted to stay and face the challenges of my profession.

It was very a short stay because this place is like many small Australian cities - there is a need for IT but it is satisfied by a small pond populated by a lot of medium-sized fish acting like sharks. After a very short time, that gets old.

My career is about focussing on building software that people want to use, not flexing my under-developed biceps and splashing wildly in a muddy pond. So while I was here, I did my best to learn something from the situation and not cause too many ripples. Yeah, me... the ripple maker.

As I walked in to different clients, developers on the client-sites kept asking me what frameworks I had brought with me. At first, I smiled and said .NET but then I realised they meant bespoke frameworks that I had created. They wanted to know what I carried in a swag on my portable hard drive that helped me build systems. In their case, this was for small systems of simple client-sever apps. And every dev had their own framework.

You're probably wondering what I mean by a small system. In the context of software, it is a system that services a small number of concurrent users and does not require capabilities like scalability and robustness under load. Yes, yes, you may argue all systems do but for more affordable systems with simple requirements that change infrequently, this can seem like over-kill. The developers who build these know that they are coding write-once applications. So the bits they do find themselves repeating on the next project, they build reusable frameworks for. These frameworks can then be used over and over again as they build the same designs over and over again. Reuse. Good, right? University told us reuse is good.

This is not that different to what I have seen in a lot of medium to large organisations though. It seems more common in groups that build small systems but it does cross all worlds and all demands. The difference is that the big places don't ask for my custom framework. They instead tell me about theirs.

The Problem With Your Custom Framework

Every time you build software, you should regress to the point of origin: The Requirements.

Every piece of software you implement. Every line of code you write. Every ounce of effort you exert in making the machine grind should be traced back to a requirement that a user needs in order to achieve their goal while using the software.

If you've worked with me then you still have my voice in your head droning on about the importance of requirements traceability. For the rest, expect a blog post in the very near future.

Custom frameworks are not an exception to this rule. In fact, they are the one part of any system that should be justified to kingdom come. If you can't find a business reason to build it then don't. I have very few to no exceptions to this rule.

Now, the reason this is important is because software has to be maintained. It must be extensible, robust, reusable, testable and above all else relevant. The software should never be held back by the tools and materials used to build it. They are not important. The end-user software is.

If the requirement of your job is to build software that other software uses to satisfies its requirements then framework away. If not, then you will spend a lot of upfront effort and infinite future work maintaining your framework just to keep it relevant to the systems it consumes.

People like Microsoft have many teams of many elite developers building many generic frameworks for you to build your castles upon. Unlike the sand that yours will be built of, theirs are backwards compatible, constantly updated and relevant. All you have to do is recompile or re-consume their changes and keep focussing on your business needs. You focussing on supporting multiple systems and stalling natural evolution and progression is more detrimental than helpful.

In most cases, there are two reasons developers insist on building their own frameworks. The first is that they took what they were told at university about reusability to mean that they must reuse code or they have failed. The truth is that design patterns are more reusable than code in a lot of circumstances. If you do need code reuse for one system, it will not often translate to another system unless great care is taken in the first place to design it that way and the agreement to maintain it is consciously agreed to by all parties including business.

The second reason is that developers like to build stuff that they can point at and say they built. I think this is sad and verging on the point of needy. As far as I am concerned, I should be able to look at a code base and have no idea at all what each developer wrote. Code is not about a developer tagging the mountain of obfuscated code that represents their prowess to others. It is about making something that can exist long after your are gone.

Let the nicest thing anyone said about you be that your code was clean, correct and easy to understand.

How To Know Your Framework Is Holding You Back

If you spend a lot of time working on your framework and not on features then your framework is not helping.

If you spend time justifying why systems dependent on your framework can't be advanced to later versions of general software (like newer version of .NET) then your framework is not helping.

If you write a new system with exactly the same design as the last system then you must ask yourself if you are solving the problem domain or complying with the saying that if all you have is a hammer then everything looks like a nail.

So You're Saying My Framework Should Be Thrown Away?!

Yes.

Most frameworks are built to satisfy a need that an underlying framework (like .NET) does not yet satisfy. As soon as that general framework does, you should deprecate your compensation.

Stop wasting your time working out the best way to forge steel and instead buy it from the great steel works and then go about constructing great structures.

I'd much rather build the Empire State Building upon the shoulders of others than a half good piece of metal alloy that may or may not support a bridge tomorrow.

Stand-Up or Scrum Etiquette

My new role is on a team that has a scrum with almost 20 participants. At this point, it is important to obey the ethos of a scrum (or stand-up) or there is a potential to waste the time of many people.

Here is my basic Scrum Etiquette. It is good to remind people of it at the beginning of a scrum at the beginning of a new sprint or when things are out of control.

Scrum Etiquette:

• Turn up on time. The scrum will start without you;
• If you can not attend the scrum then give someone your update and they will go through it on your behalf;
• Your update should consist of… 1) What I've done since the last scrum. 2) What I'll do between now and the next scrum. 3) Any blockers;
• Your update should take about 30 seconds;
• All other conversations should take place after the scrum in a Dev Huddle (for tech talk) or BA Huddle or Tester Huddle or specific delivery teams; and
• Speak to the team and not just the scrum master. It's about sharing with your whole team and not just reporting your status to the boss.

Scrum Anti-Patterns (for the Scrum Master to look for when running the scrum):

• More than one person acting as the scrum master;
• Everyone speaking to the scrum master;
• Long updates with too much detail;
• Technical discussions that other team members aren't interested in;
• People not mentioning blockers. People should explicitly state if they have no blockers; and
• People looking uninterested.

I did google this and there weren't enough clear definitions. Every team is different and you will adjust to yours. This is a good starting point.

Go forth and scrum.

Your compiler is your friend

Today, I spent a small amount of time helping a developer solve a problem.

That may be how I start a lot of my posts for a while since I am working with some smart chaps who are learning to be better devs. The thing about learning to be a better developer is that you learn it from writing a helluva lot of code and from working with old grey haired devs like me.

Ok, I don't have grey hair but I do this wise Gandalf voice that really deserves some grey hair.

When I started developing, a compiler wasn't much without a linker. We spoke of lint and didn't mean the stuff left in driers. We had pet dinosaurs.

One thing that understanding the parts that come together to be the Build that we all speak of now is that we learnt to listen to what each part was telling us. No, no, I don't want you to go out and conduct some native American dreaming ceremony but I do want you to listen to your compiler warnings.

In today's adventure, I paired with a developer who was having issues adding a set of XSD schemas to a .NET schema collection. The thing is that this class was deprecated after .NET 2.0 and the reader feeding it was also of the past.

The compiler told us so.

The thing is that although many developers are warned over and over again that they are using an old API function and to use X instead, they persist. They ignore that and many other warnings. This however is the most common one I see outside of warnings about variables being initialised but not used.

Your compiler is telling you this for a reason. It isn't because it has had a slow day or it is having a grumpy moment. No, it consistently warns you that there is a better way to do things now and even suggests how you should attempt this.

So, we solved our issue today by listening to the warnings and using the latest and greatest (be it 3 years old) and all was well.

Yes, we have evolved as a profession to obey our build errors and not check in a broken build to avoid the hisses and boos of our colleagues. Now we must grow to listen to the warnings. They are not wasted cigarette lighters at a Pink Floyd concert. They are not a gasp of exclamation in a sea of squealing teenage girls at a boy band concert. They are not platform high heels at a Kylie Minogue concert. No.

To be a better developer, you will listen to the advice you get from your build, your static code analysis and your IDE refactoring suggestions. You will do it because it will make your code better and more up to date. You will do it because it will stop the bad things happening that happened to those before you. You will do it because it will stop my soul from hurting.

Be it Visual Studio or IntelliSilly, your IDE is your friend. Your compiler warns that there be dragons and you must listen.

We Are So Progressive

While waiting for my clearance to clear (that's all for another blog post), I've been talking to different people about short term gigs. I am not in any major hurry to find anything so the conversations are not stressful job interview types but more a chat about whether we can work together.

One interview was such an entertaining conversation that I was impressed at my ability to keep a straight face the entire time. Instead of giving you a blow-by-blow of the whole session, I'll just share the top three highlights that made me smile afterwards.

"I don't believe in unit testing. It gives people a false sense of security. I believe testing gets in the way, which is why we fired the dedicated testing team."

This came out of me asking what the automation in their dev and deploy processes is like and what kinds of testing (automated and manual) were in place. The development manager and architect (who is the same person) went on to lecture me on the false security blanket that unit testing is and that it is an overhead that in no way helps assure a quality code base. He used words like coverage and feedback loop and other buzzwords but not in any way that seemed to fit in with any kind of practices or processes I'd ever heard. It's very possible I was hearing of very new ideas. Yeah, possible.

In the end, he had reduced his delivery team to a business analyst and a bunch of developers who pushed code through to Production in 20 minutes with his surety and trust that they simply didn't write buggy code.


"We have Continuous Integration right there. *points at monitor hanging on wall* That screen shows our 16 production apps. It pings them every few minutes to see if they are still working. If they are, it's green. If they aren't then they appear red."

Now, that is a dashboard but it in itself is not CI. I've been seeing the term Continuous Integration used a lot of by people who think it is based on red and green lights. I'm guessing the amber light of traffic lights must make them really confused.

In this case, I asked if they had any automation around their build or deploy process. Again, I was dismissed as some kind of charlatan with ideas from yesteryear. This was the point where I became most distressed, in that burning-building-and-the-lifts-are-out-and-I'm-on-the-75th-floor kind of way.

The dev manager said that "yes, our profession is going towards automated testing but that's a phase." He said he was going away from it having proved it wrong. He said "I am progressive." After later whinging to some ThoughtWorkers, we decided he was progressing backwards and so was technically correct. *sigh*

"Data modelling is over-kill."

Now, I'm the kind of girl who watches Fast and Furious 6 and thinks there weren't enough car scenes. I even read reddit and wonder why the comments ended. Over-kill is not something I claim or proclaim much at all.

In this case, he (dev manager guy) wanted to know what I liked about ASP.NET MVC. He wanted to make sure I hadn't just read the FAQ. I just spent the last 18 months as the Microsoft PFE ASP.NET MVC Lead in Asia so when I say I know MVC, I wrote the FAQ. Either way, test away.

I gave my reasons and went on to talk about DDD and the merits of building a domain true to your users. He sniggered. That's ok. People snigger.

In this case, he challenged every idea of modelling to the point that he said he'd discarded Entity and any persistence layer at all and thought a Dataset passed straight to the templating engine wasn't awful.

I sighed again.


So those were my favourites. I commend myself on my ability to listen and consider all that was said. Even his impressive 20 000 requests on his 16 web applications per day had me keeping a straight face. Ask any of my colleagues who've worked on farms that do that in a second. Oh well.

One thing I took from this whole experience is that everyone has a world that seems huge to them. What we must learn is how to judge up and out. There are people out there who don't want a pissing contest. They just want to help you build software that scales, is robust and can be extended.

In my world, I always want to strive to work in better places that teach me bigger and more amazing concepts. Everything I know is tiny and insignificant compared to what I have to learn.

At least, I know that.

Agile - Start with paper walls

Clients often come to me to ask how they should set up their instance of TFS ALM so that it will reflect their software development lifecycle.

My usual response is a question: What is your software development lifecycle?

Now, that is actually quite difficult to answer for most developers and development team managers.

Most people either say waterfall or agile.

It is rarely waterfallers who are asking for more process or tools. It is usually the neo-agilistas who want imposed structure . Everyone is doing agile or they did it once and it didn't work.

There are many tools out there promising to agilify your software development "process".

They will promise that it doesn't matter what standard your developers are at because the tool will raise them up.

They will promise that it doesn't matter if all you've ever done is waterfall with an avalanche of specifications and documentation because you can just stop doing that.

They will promise that if you sign with a little blood then everything you do will be faster, better and leap buildings in a single bound.

Let me tell you honestly and with great confidence that there is no software tool on the market that will do any or all those things for you.

Spending thousands of hours building, mentoring and empowering agile teams has taught me three very important immutable facts:

1. You need to train your teams to be agile and that can only be done by introducing experienced agile coaches;
2. No tools will ever save you. Tools will aid you in recording and tracking your progress but they will not set that progress in motion or maintain its momentum; and
3. Communication and transparency are the keys to building great software, which means your teams must talk, you must talk to your business who set the requirements and you must be honest about what works and what doesn't.

When I start an agile team from scratch, I start with a bunch of cards, some Sharpies and a will to encourage people to talk to each other by creating a safe working environment.

Jira or TFS ALM or whatever silver bullet you have been promised is nothing if it isn't accompanied by experienced agile practitioners and an acceptance that you will learn along the way.

Start with paper walls and good people.

Canberra Developer Blogs

These are the Canberra developer blogs that I have gathered so far. This list will be updated as I find more. Here is the list:

• Brian Farnhill blogs, speaks and knows about SharePoint;
• Dale Anderson writes The Ravings of a Software Engineer . He is the author of the Tribe platform;
• Pia Waugh is an open government and open data ninja who is freeing federal data;
• Rod Weir and his team produce software for helpdesk and support services;
• Manickam Ramanathan is a passionately curious .NET developer;
• Jeff Lau is a Java dev with good insights for all devs; and
• Damana Madden is me. I am a .NET developer with a tendency to code in lots of different non-Microsoft languages but C# has my heart.

Visual Studio Tricks - UML Validation of your Intended Architecture

Now for the third post from the series of Visual Studio Tools I Can't Live Without on using UML diagrams to validate your intended architecture.

Part of what I do when I run a code review is to extend it with a report on design divergence. That is when I look at what the intended application design was and what has actually been implemented.

This takes several long and probing interviews with the application architect or technical lead, asking questions about what they think has been coded. Then I look at the code at a high level, with more attention paid to sections with more complexity.

Sometimes it is pretty spot on. Sometimes it is very very different when we get in to the code.

As mentioned in other posts, I will use tools like dependency graphs to get a quick high level understanding of a code base. Another tool that Visual Studio gives me that I didn't have in the past is UML diagram validation of code.

Visual Studio has a project type called a Modelling Project that allows you to create different kinds of UML diagrams that communicate what your intended application design is or are created from code and show the implemented application design.

Again, there is a lot of documentation on how to create these diagrams. The main thing to know is that there are many different types of diagrams and once you put them in place, they can be used to validate the actual code.

Using these tools, you can reverse engineer a code base quite quickly and take in the high level design visually, which is for me the fastest way to understand an application architecture.

It is also quite revealing in that it can show boundary violations between components that cause future extensibility pain. In one case, we identified calls being made from the view directly to the data access layer, bypassing business logic layers. The architect there didn't realise that some of the less experienced developers didn't know they shouldn't do things like that.

Layer and Class diagrams are my favourites. The ability to drag and drop a file from the Solution Explorer in to the diagram makes them a breeze to create.

Once I have diagrams in place, I communicate to the technical leads how to continue to use and create them for regular checks and even in gated check-ins.

A picture really is worth a thousand words.

Visual Studio Tricks - Dependency Graphs

In the second post of this series of Visual Studio Tools I Can't Live Without are Dependency Graphs.

When I conduct a code review or set up a gated check-in, static code analysis will give a list of all the things that are wrong based on a predetermined set of recommended practices. These are mostly superficial and not 100% indicative of whether a code base is bad or terrible or should be burnt to the ground.

Usually, people will look at the number of of errors and warnings found by static analysis to draw conclusions. These can often be the same issue over and over due to things like copy and pasted code, generated code or agreed practices that counter recommended practices.

In any code review I carry out, there is more than just a list of errors. There is an understanding of where those errors sit in the the scheme of things, how serious they are and if they are an indication of worse things to come.

To draw theses kinds of damning or freeing conclusions, an engineer must understand the code base. We have only days to get to this point so we draw on everything we can to help us with understanding what we are judging.

Years of experience will help.
A walk-through with the technical lead will help.
And a picture that speaks a thousand words will certainly help.

With Visual Studio 2012 (VS2012), I have embraced and celebrated the idea of Dependency Graphs along with Analyzers.

There are a lot of instructive posts about how you go about this. There is no need for me to walk you through it.

What I do want to do is make you aware that there is a way to look at the complexity in code in a visual way. You can find and explore circular references, unreferenced nodes and hubs which are highly referenced nodes.

One place this is valuable is in code reviews of pending change sets. VS2012 can filter to just pending changes. This allows a technical lead to ensure that unnecessary complexity is not introduced with bug fixes or added features.

If you need to understand how your code is connected then use this tool. You may even become dependent.

Visual Studio Tricks - Code Clone Detection

It seems that the tools I take for granted are not used by all. This is the first in a series of posts where I will be sharing some of my essential Visual Studio tools that every .NET developer should be aware of. If you already are then avoid me stating the obvious and go read something else.

Call me Code Review Girl and hand me a cape. In my role, it is common for me to travel the depth and breadth of Asia, Australia and New Zealand to conduct a code review and design divergence checks on very large government and commercial code bases.

Microsoft has internal tools that let us do that with great ease. This is always where we start. However, we often go further with remediation plans and sit with developers to show them the kind of things we found in their code that need improving. We don't just show them how to fix it but explain why these issues are issues and how they can be tracked down. In my case, I use pair programming to start. Teach a dev to fish and all that.

When I pair program with a developer, I will never let them copy and paste code. They can either type the whole thing from scratch or they can write a method and call it in both places. Copy and pasting code is an anti-pattern that will result in bloated code bases and often carried errors.

Now, that is all well and good when you are writing new code with another developer but for the times when you aren't watching and enforcing that rigour or for past crimes, Visual Studio 2012 gives you Code Clone Detection.

I won't go in to too much detail repeating what the link above explains but I will give you a quick summary of what you get and how to use it.

Code Clone Detection looks at code statements of 10 or more lines that appear in methods and properties across entire projects or solutions. It works on code with up to 40% of its tokens changed and with statements that have been rearranged.

There are two ways to use it:

1. Highlight a specific piece of code, right-click and choose to Find Matching Clones in Solution; and find that specific code repeated; or
2. Use the Analyze menu to Analyze Solution for Code Clones and find all occurrences of repeated code.

There are ways to exclude certain files like generated code and you will want to do that with large generated code bases.

I find this one of the most useful tools when looking at how to attack a large code base that needs a refactoring machete. This is a tech lead's best friend. Or at least one of them.

Let the clone wars begin.

Have you heard of a magical place called the Internet?

I am a little bit of a spoiled brat when it comes to the wired world. My web presence started with Geocities when we embraced animated gifs and blinking HTML. Then I moved on to pimping MySpace in the mid-noughties and then discovered the pedestal that is having your own blog. Yes, I lived in the even older text based world of newsgroups and spent hours surfing the web with Lynx.

These days, I feel sad when I meet "IT people" who think they are somehow carrying a banner of normality by not being on Twitter or Facebook or LinkedIn. They ask "why would I want that?" and to be honest, I couldn't care less that they haven't worked out that the world is leaving them behind.

In fact, it shocks me to come across "computing people" who snigger at the idea of an online brand only to wonder why no one hires them based on all the silent good deeds they have done. I call that a home brand. Yet, they go on to tell me that the world is a meritocracy and no good deed goes unpunished. I don't snigger back.

In my job, I build bloody big web sites for super large companies. I build mobile line of business apps for multinationals. I build dumb games for smart phones. I talk about design of architecture and of user interface. I demand usability and an enjoyable user experience. I make interacting with the virtual world easier for people who don't spend their whole lives online like I do and for those who do.

It is unsettling to see the same mistakes being made over and over again. To watch cluttered interfaces be embraced by technologists who I think should know better. To see people tell me that this is the way the world is when I sit in their retro worlds and think of how young I once was when the thing they are championing was actually the new black.

In the past, I would try to educate them. Explain in detail the reasoning behind good design in visual ways and in code. It would take time and patience and not slapping them but I'd invest and finally help them understand the modern way.

I'm not even talking cutting edge. Just what is accepted now.

Everything is different now. Things old people once said to me are now coming out of MY mouth. Things like "I choose which battles to fight these days" and "they will learn in time" and "it is not my job to teach everyone."

When it comes to a client and delivery at work, I give my all. The long conversations seem worth it. When it is my peers and people I watch or interact with because of work and who aren't my clients then I seem to stand back now. It still irks me or even hurts my soul to not interject but something in me simply doesn't care enough anymore.

There is this amazing thing called the Internet. Stuff is moving fast. What you understand as the "best practice" or the "standard" may have been that once but it isn't now. I spend so much time looking at better ways to do things and new reasons for doing it that way. That is not an assumption I can make for others.

Keeping up with progressing technology and ideas is a job on top of your full time job but for those of us in technology, it should be a given. You can't just work 40 hours and go home and base everything on what little you did or learnt in that time. If you want to do that, study ancient history or paleobotany. The world of technology is not the place for you.

Hey, you kids! Get off my lawn!

Geek Girls Coffee and Microsoft Webinar

On Tuesday the 12th of February, I participated in a webinar (an online seminar) that was a collaboration between Girl Geek Coffees Sydney and Microsoft.

Pip Marlow

It was run in a panel format and the panel members were all from Microsoft:

• Pip Marlow - Managing Director of Microsoft Australia;
• Me;
• Andrew Le Lievre - Human Relations;
• Michelle Tea - Head of Services in Microsoft Australia; and
• Susanne Krohn - Early Career Employee and recent graduate.

The audience was a good mix of women in technology who are currently studying, recent graduates and those working in ICT at the moment.

Michelle Tea

The aim was to address audience questions around:

• What is it like to be a woman working in ICT?
• Was it a straight road to get to where you are?
• How have you dealt with negative experiences due to being a woman?
• What is important when companies like Microsoft are hiring people?
• (and the very important) What do you always carry in your handbag, other than a mobile phone?

Damana Madden (me)

There were great stories and a lot of good insight from all the panel members. The audience was able to ask whatever was on their mind and comment on different questions. It was a wonderful chat all round.

Susanne Krohn

These kinds of events are an awesome chance to get to talk to people who are working in the thick of it, in large companies like Microsoft with women participating in all roles.

Andrew Le Lievre

Kudos to Katrina Wong for organising this, along with GGC Sydney.

This is Not a Democracy

When I see people who I consider good leaders, be they of any age, gender, height or ethnicity, I see one thing that they do very well. They make decisions quickly. Quickly does not mean recklessly. It just means that they make a decision knowing that if it isn't right then they can correct at a later time.

Too often, I see people who decide for whatever political, career or other reason that they want to be a leader without understanding the fundamental decision maker trait. They go in to every situation and in particular meetings, as if they are chairing a committee that must come to a full consensus before a decision is made.

This is one of the worst things you can do.

Of course, it is right to listen to the group and take input and feedback at all times. That is a given.

The big mistake is to ask permission to move forward at every stage in a journey. This slows things down because of two important factors: 1) You can't always get everyone to agree; and 2) People don't always want to have to make the decision for you.

The latter is important. That is one reason why people like leaders. The responsibility to deal with consequences often falls to them. Others will assist but they don't want to have to be the ones who decided that things be done. This in itself is not a bad way to be. Not everyone wants to be in control of every situation. That is why we sometimes lead and we sometimes follow.

Making every decision by committee can also mean that the "wannabe" leader loses trust because they look indecisive.

If you want to lead then just lead. People will forgive you errors if you can fix them. If you share the same goals and want the same outcomes then there is nothing bad about deciding now and apologising later.

Not every group has to function as a democracy in order to work.

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.