For a while now, a trope has been going around (I think started by Jesse Liberty) to the effect that if you know Silverlight then you already are a Windows Phone 7 developer.
Having spent a lot of time lately on the Windows Phone 7 forums answering questions, I’m actually amazed at how many posts come through that demonstrate a lack of basic knowledge about Silverlight.
… and that’s kindof cool.
My first emotion, however, is always shock and resentment that people are trying to write Windows Phone apps and yet are asking elementary questions about data binding, about how to template a control, about the purpose of the DataContext, about how to skin a listbox.
Not uncommon are questions such as:
“Please to show me how to write a complete Twitter client with samples and with security built in. Thanks in advance.”
What I find impressive in all this (my second emotional reflex) is that the developers who are trying to do the most with Windows Phone are not experienced Silverlight developers – the people we all originally assumed would adopt the Windows Phone platform.
They are not interested (to my chagrin) in the nuances of the Silverlight platform and the best way to prop up an MVVM framework.
Instead, they are looking to accomplish a task and then move on. I suspect that while I am still putting the finishing touches on my tombstoning infrastructure and my comprehensive solution to page transitions in a phone app, they will already each have 20 applications ready for the Marketplace, all of them beautiful, functional and competent.
The philosopher Hegel, at a certain point, extols the virtues of the cow, and recommends that people should consume concepts the way a cow will consume grass, quickly and efficiently. Nietzsche, in a similar vein, considers the cow’s contentment chewing her cud while the philosopher worries about what will make him happy.
One oddity of modern (by which I mean in the past 5 years) programming is that application development time has not gotten any shorter despite the prevalence of frameworks and syntactic sugar in our languages to make the development process easier. Is it that with better tools, we simply take greater time to create our software edifices?
Windows Phone applications, by contrast, are small and light. They certainly gain by sophisticated architectures – and I’ve read many a screed decrying the lack of TDD and IoC experience among the new breed of phone developers – but do they really need it? Do I need architecture at all for a three page application? Do I really need unit tests? Continuous integration?
In the consulting and corporate worlds, being able to talk to TDD, IoC, SCRUM and a host of other acronyms sets an expert developer apart and justifies higher rates. In those particular environments, it makes sense to hone these skills and to guard them jealously as they give us a competitive advantage in the consulting marketplace and along the corporate ladder.
Phone development, however, is judged by a different marketplace. A phone application doesn’t have to appeal to architects and CEO’s. It simply has to appeal to the twitchy fingers of a phone marketplace consumer who has no idea what is going on underneath the slick appearance of an app. It seems unlikely that any phone application will achieve high ratings based on the beauty of its architecture.
So consider the cow. As consumers of phone applications, this is what we all are. An app must catch our interest quickly. The moment an app loses our interest we forget about it. An app is either successful in maintaining our attention or it isn’t, and if it isn’t it is soon consigned to oblivion.
And now consider the virtues of the cow developer. The best ones share common characteristics with and understand their audience. They have little time for finding the “best” way to skin an app (after all, there’s always more than one way to do that). Instead, they want a quick solution so they can move on to getting the colors right, the sounds right, the overall experience right. If someone else can provide the quick solution, all the better.
There is no particular pride to be taken in coming up with a solution by oneself. Pride doesn’t feed anyone. The primary objective is to create apps that delight the consumer and make him want to buy (or chew, to extend the cow analogy a little too far).
Perhaps it is time we, as developers, began admiring the cow rather than the architect of our plumbing.