Thick Skin and Deep Knowledge

The Internet is a funny place full of contrasting experiences - from friends made in virtual places that one day become great real life moment makers to ugly trolls who fit the bridge dwelling cliche to an uncanny point.

I've been blogging for a while now in many forms. I have an online presence and a persona that is purely my own. In fact, it is so well established that I have met people for the first time who read my writings, and had them tell me that I don't think that but would express it much differently on my blog.

Blogging and technical blogging in particular can be an interesting experience to the new comer. They have read blogs and participated in online forums that are all about being constructive and helpful. Then they hit a world where expressing their opinion or even stating a solid fact is attacked, poked, ridiculed and salted with personal insults.

When that first happened to me, I took it very personally. I wondered why someone would attack me so cruelly and unprovoked. Why a statement that I'd made resonated so deeply in them that they threw acid in my face.

Then I realised that it wasn't about me.

Those who produce content and express a view or share knowledge may go out intending to share what they know and learnt but may not always be received that way. People can disagree with you or you may be incorrect but if the feedback you get is insensitive or purely mean then it says more about the giver than the receiver.

I love feedback. I go out seeking it. I want to know what people I respect and care about think about me. This however is my soap box and if you want to get on it then you must be constructive in some way or go out and start your own blog with a weekly dedicated post to how much you dislike my thinking. I'd link to you :)

If you blog, you must develop thick skin. You must trust in yourself that you are putting out there what you understand and what you believe to be right at the time. You must trust yourself and ignore the haters. You can put just raw facts or express your own opinions. Whatever you choose is fine. Try to add something with each post.

Don't worry too much about those who come up to poke you. Happiness is intrinsic. Kindness is deliberate. Nastiness is a sign of a deep insecurity or self loathing. It isn't your problem.

Stay strong and keep blogging.

Measurement and Sentiment

A good friend of mine and former colleague is working in an environment of legacy applications, with legacy developers who don't want to take part in any development practice change. He is charged with moving all of their pre .NET apps to a later and greater version of Microsoftness. They are encouraged to come along on the journey but are not really interested in changing their ways much at all.

While thinking of advice to give a friend, I came to these conclusions.

The first thing with change is to understand that it is human nature to resist it. The ones that push back are not the freaks, those of us who chase the mutations are. We are the minority but we are the ones who shape the world around us.
That is why buy-in from your team members (the pigs, not the chickens) is extremely important.

Rigorous practices is what makes an agile team. Those practices are determined to work based on two things - measurement and sentiment.

Measurement is the data that proved that a practice applied rigorously achieved a measurable increase in quality or quality or clarity or whatever your sliders are set to.

Sentiment is the buy-in to the practice by the team members. That is devs and BAs and testers and business reps and anyone else involved in using that practice to get the best results. Without buy-in, the practice should be dropped after trying it for one or two iterations.
On a new agile team with people who are feeling consciously incompetent and not believing, you can fail to gain buy-in or lose what little you had.

Without sentiment, measurement is unsustainable. Without measurement, sentiment is unjustifiable.
When I teach engineers or any member of a team a new way of doing something, I explicitly ask for buy-in. If they don't give it then I sit with them and try to understand what the pain point is that they are experiencing. Then I address that concern, beit with understanding or a different practice or explanation or discussion.
Try do this at an individual level if you have relationships already or think the discussion will build rapport or technical respect.
If it is the whole team you need to address then use a retrospective that allows everyone to air what doesn't work in a constructive setting. Self organising teams must decide what is best for them with some guidance but they must choose for themselves. If they choose then they commit as part of the deal.

Often those who suggest the ideas are the outspoken ones and the leaders of the descent anyway. Use them as a force to encourage change.

Presenting at the Premier Field Breifing

Today was a day for Canberra Premier Field Engineers to share their knowledge with an open house, at our second Premier Tech Briefing for this financial year.


My colleagues were out in technical force and dressed like Microsoft ninjas. I got to wear my Swarovski crystal Microsoft shirt which was I admit, a highlight.

Jimmy Fitzsimmons presented on Windows 8 Dynamic Access Control as Steve Moore, the Lync genie spoke in an opposing room.

Imtiaz Khan then gave a SCCM 2012 Tech Overview, while Grant Holliday and I did a joint session on Agile Development with Visual Studio and Team Foundation Server 2012.

There were wild cheers; huge amounts of delicious food; virtual graffiti of another engineer's face as a demo; and a free autographed book from our local published TFS guru.

We had a fantastic turn out with attendees from 25 organisations from across Canberra.

The immediate feedback has been very positive.

Next time, we will have a full dev stream. Stay tuned.

A Lifetime of Events

Last week, I sat with a developer in an effort to solve an issue with broken Suspend-Resume handlers in Metro. The developer told me that he was getting inconsistent behaviour with his Suspend handlers and that he suspected a bug in the Metro framework.

When I got him to repro the bug, showing me how the error was caused and what the resulting output was, I found that he was not suspending and resuming but instead, suspending and on-launching.

He was exiting the application.

Metro triggers the suspend handler at that point. Suspend handlers run when you exit the application. Exit can be either suspending and leaving for a bit or quitting the application forever.

Now, one thing you should know about the Suspend handler is that it is paired with the Resume handler. If you can not see the Resume handler being called subsequently, after you add code to the Suspend handler then you are putting it in the wrong place.

The developer I was helping was putting his code in the wrong place. He was assuming that if he told Application.Current to persist something then it was so for as long as he waited to relaunch the application. He was wrong.

Web developers don't seem to hit this learning point but desktop developers do. It happens because they don't live inside life cycles. They have never been forced to understand that objects have lifetimes and you have to interact within the rules of that world.

When this developer called the Suspend handler and traced the persistance back to a file that stored the serialised version of his data, he assumed that it would be there when he started the app again.

That is an incorrect assumption.

Application lifetime lasts for the a the amount of time that the application is current. That means that when you launch it and when you exit it, the application is live. Outside of those boundaries, Metro does not guarantee anything. Files persisted to storage by the Application object are not always there and not always called the same thing. If it goes to disk, it could just as well go to memory and it is then just as fleeting.

There are matching pairs when it comes to exit-entrance handlers. With Suspend, you can count on Resume. With Exit, you can count on Launch.

Don't assume anything will be consistent, outside of the lifetime that your event belongs to.

If you want to ensure data or state persist then you must explicitly handle that persistence when it does not obey Application lifetime.

Metro Design Anti-Patterns

Metro app development is young compared to other environments.

It is not a browser app.
It is not a Windows desktop app.
It is not an iPhone or Android app.

Although it isn't one of those well-known environments, it is built on two solid presentation layers. XAML from Silverlight fame and HTML+CSS+Javascript from well, everything-that-is-useful-on-the-Internet fame.

The technology space underlying Metro is not hard to adopt. It's the world from a Silverlight or web perspective with design constraints.

I have reviewed around 30 Metro apps in the last month and I keep hitting the same learning hurdles from the early adopting developers.

To start, developers that are early adopters are quite fearless. They march in, sometimes as canon fodder and sometimes as knights leading a rush. With this comes an exaggeration of all the things that could happen. An amplification of the mistakes and an enlightenment of the amazing successes.

Here are the patterns that I have seen so far in Metro application development and what you should think about when you build apps in this brave new world. This also applies to mobile devices in general.

Obey the Rules

Stay within the bounds of your framework and design constraints. If you have to exert enormous amounts of effort to achieve something that you think should be available then you might be doing it wrong. The guide lines are there to ease your progression, not counter it.

Some developers have a tendency to solve the same problem with every solution. They change languages but still write code that looks like their default language. They construct interfaces (programmatic of visual) that satisfied a past problem domain but don't satisfy the current one.

If you are going to change then change. If you don't want to leave what you know then stay with it. Concepts and constructs can be taken with you. Concrete implementations can not.

Metro is a new presentation layer but its strong guidelines are walls that don't entrap you but instead hold you up.

Don't Isolate Yourself

In a world where there is one dominant thing on their screen, users do not want to be locked in to that one thing. A feeling of isolation within an application is a major reason that users dump your app.

Often a screen shot is the only way to share out information from a mobile based app and there is often no real way to bring data in to the application.

Metro has the idea of Share Contracts. You can implements different interfaces quite simply that let others treat your app as a Share Target that can pull data in to your app or as a Share Source that lets you push data out of your app.

You can provide a multitasking operating system but without enabling easy sharing, you might as well promote isolation.

Move in one direction

Working with phone apps really restricts the dimensions in which you let your users scroll. Often returning to the larger real estate of a tablet makes people lazy or 'laxed or carefree because they forget the rules of touch and fall in to their old desktop ways.

Think about how you use a touch screen or watch a child and you will observe flick motions and movement in one dimension. Introduce another dimension and watch the confusion.

Google considers a link unvisited if you follow it and then click the back button and then click the next search result. Navigation is bad if a user moves in a direction and then moves back quickly because they didn't mean it.

Consider all of this when you build mobile apps.

Metro won't stop you from using multi-dimensional scrolling but the design principals discourage it.

If content is your primary navigation mechanism then don't distract from your content and purpose with confusion due to scrolling.



Let the guidance guide you.

Windows 8 and Metro Development

Before we go any further... oh wait, let's start first. So before we start, let's get one thing clear:

Windows 8 and Metro are not one in the same thing. Windows 8 is an operating system. Metro is a tablet focused environment that runs on top on Windows 8.

When we talk about Metro development, we are talking about a set of design principles that are primarily focused on tablet and ARM devices and the powerful set of development tools that .NET now offers.

In the same way that iOS dictates that you will live inside it's pome ecosystem, Metro is guiding its developers through tools, libraries and UX guidance how to easily produce an application that is friendly to the touch world and still plays well with mouse and keyboard.

One thing I love about iDevelopment is that Apple has pulled the level of developers up again in to a world where you can wield the power of your respectable language with the aid of the brilliant Cocoa framework.

Metro is offering you the same thing but with the benefits of living in the Microsoft universe with access to a pool of technology, consumers and a development framework that is proven in all environments from the enterprise world to small teeny systems.

For developers, there is so much noise around Metro that it's hard to know where to start.

Start here...

Metro dev == (all things .NET) + WinRT + WinJS

Do not be overwhelmed. It's easier than walking in to a new language; going from desktop to web development; or learning graphic design skills. There are simple starting points that allow an attainable entry point.

Download Windows 8 Release Preview (Win8 RP) and Visual Studio 2012 Release Candidate (VS2012 RC) and choose any first class .NET language.

Create a default project and then make changes to it and see how simple it is to start and produce a good looking, easy to use and robust application.

After running Microsoft Metro App Excellence Labs for over 2 dozen applications, I can only say that the less you fight the world presented to you by Visual Studio and the easy-to-interpret design principals, the better your app will be. As with all new interactive experiences, you may try to make it act like something you know better but it actually works better to let it be itself.

This is an echo of the advice I gave about writing iOS apps. Work with your environment. Learn what it does well and use it. Reinventing the wheel is self-validation for hackers.

Go forth and Metroply!