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.
I agree, far too much time is spent agonizing over frameworks and trying build "elegant" code that our development timelines don’t seem to be improving. I’ve seen far too much code where someone tried using one of the frameworks (CAB, MVC, MVVM, etc) and ended up with an incoherent mess because they didn’t know what they were doing. The end result is far worse than if they had just written code in the code-behind which lately has become the evil place.
Michael,
I think that’s an experience many people are running into. The cost in time and energy — and possibly mis-implementing a given framework — can take value out of the effort.
With Windows Phone, in which apps are typically small and not intended to either scale or grow, the value proposition is even more questionable.
That said, I do like what Laurent Bugnion and others have done to support WP7 development. If you have the time to learn a given framework, then you will gain something from it — your app may be
tighter and you’ll have a better understanding of the underlying platform as you try to implement a given pattern or framework.
No one should feel like they "have" to implement patterns or platforms if they know they don’t have the time or expertise, however — the benefits may not be worth the cost.
James
Hey James,
There’s quite a few insightful points here.
I definitely think there’s a time and a place for architectural rigor.
There’s a few thoughts that come to mind for me when I read your post.
I like the view of software development as a craft as much as an engineering discipline.
In this respect a craftsman has at his disposal an array of tools and the experience to know which to apply and when.
The craftsman understands balance. With competing priorities ruling our development experiences it is a fine balancing act to accomplish the right mix of simplicity, sophistication, elegance, expediency and maintainability. This balance can vary from project to project.
As much as tooling and requirements are dimensions in this variance, so too is the target developer part of the development / maintenance equation. I grant that in the app world, in many cases, the maintainer will be the sole developer forever. I also grant that in many cases the codebase of an app bears no resemblance in size to that of an enterprise application.
Another expression I like is if you’re only tool is a hammer then all you see are nails. I feel software developers worth their salt understand that it’s a life long pursuit developing the range of tools in one’s toolbox as much as they learn which to apply and when.
Lastly I would just like to say that in my time being involved with the windows phone developer forums since the early days, whilst I will grant there is a diversity of competencies coming to the forums (which arguably is responsible for a lot of the forums material substance), I’ve also had the good fortune of crossing paths with a great many talented craftsmen, yourself included.
Nice work on a thought provoking post 🙂
Regards,
Mick N.
I have not fully comprehended the content here in the article about Consider the Cow. I imagine I figure what you are expressing. I perhaps know what you are articulating, but you lost me in the start. There is no smoke without fire and on that point there are no comments without postings.
Lastly I would just like to say that in my time being involved with the windows phone developer forums since the early days, whilst I will grant there is a diversity of competencies coming to the forums (which arguably is responsible for a lot of the forums material substance), I’ve also had the good fortune of crossing paths