Decisions, Decisions - Which Windows 8 Programming Paradigm Should We Use

When Microsoft first announced that they would support three programming options for their Windows 8 Store apps – C#/XAML, C++/CX/XAML, and JavaScript/HTML – many organizations such as my benevolent employer, CTS, asked the question "which model is best?" After all, Microsoft has gone out of its way to declare all of them "First class citizens," and in the spirit of egalitarianism, we need to analyze each option. Our Chief Engineer asked us for our opinions, paying particular attention to three questions:

• Does one platform perform better than another?
• Which platform leverages our predominant actual skill-set as a company?
• Do we have any insight into whether one of these methods will be an industry standard?

To answer our question of which model is right for us, it is important to understand how developing a Windows Store app is different than creating a traditional web app or .NET application, and why Microsoft decided to create the three different programming models. This will get a little geekier than some of my previous posts, so bear with me.

Intelligent Design Patterns Part 2: How Service Oriented is Your Architecture?

The other day I wrote about the inherent struggle between simple and complex software design, and promised to follow that up with some specific instances from small design decisions such as whether to use the facade pattern between your web and business layers, to fundamental decisions regarding your organization's theory of software development such as Test Driven Development. Let's start the series ambitiously with the granddaddy of them all - Service Oriented Architecture (SOA).

The concept of SOA has been around for a few years now, and really took off around six years ago when SOAP web services were saturating the development landscape, and Microsoft introduced WCF. Though strict adherence to SOA principles has declined as PM's have realized some of it's drawbacks, the theme of services has remained strong, and promises to do so with an ever growing suite of tools such as Microsoft's new MVC 4 Web API.

Intelligent Design Patterns Part 1: Black Coffee Software

Being a transplant of the great white north to the proud state of Alabama, I was thrilled when the state's first Dunkin Donuts opened about two miles from my office. We have a couple of Starbucks close by, but until about a year ago we were painfully without Dunkin. For those of you outside of the United States, in our country the Dunkin vs. Starbucks question has become sort of a cultural litmus test based on the true fuel of American innovation: coffee. An order at Dunkin usually reads along the lines of "Large Coffee, Black." Starbucks, of course, is famous for its ability to build drinks more complex than non linear algebra containing contributing ingredients from more countries than the international space station. A Starbucks order must be at least 18 syllables  and run along the lines of "Venti half soy, half 1 percent, cream mocha vanilla latte with splenda, add a split quad shot with whip and caramel. Extra Hot."

To Dunkin fans theirs is the choice is one of simplicity - of getting the job done with no bells or whistles. To them, a Starbucks coffee is complex for complexity's sake, and contains unnecessary ingredients that do little to advance the coffee drinking experience but increase cost and obfuscate any attempt to understand one another's drink orders. Its customers are pretentious at best, and quite possibly un-American at worst.

To Starbucks drinkers, theirs is the more evolved palate. Their orders simply cannot be appreciated by the cretins of DD, who they will not rule out as a potential lower life form stuck in a rigid coffee drinking pattern and unable to adapt to change should the need arise.

So which group of loyal customers is right and which is wrong? Of course this a question that can't be answered - there are simply too many variables, too many circumstances, and too many considerations of personal taste.

Deployment will Eat Your Lunch

They generally tend to congregate in Starbucks, Brooks Brothers outlet stores, and marinas – the business-person who gazes longingly, nay desperately, at his comrades using an user-friendly uber-trendy iPhone while he keys away on his standard-issue company Blackberry. Our friend’s golf-buddy observes his plight, and raises his eyebrow in just subtle enough fashion to perfectly communicate the commentary, “Blackberry? How very 2003.” The tragic part is that this is not our unfortunate friend’s fault. He didn’t choose to organize his work life using the mobile equivalent of MySpace and LA Gear – his employer simply issued him this sidearm because that was the company standard, and nothing so gauche as an iPhone could ever be allowed to connect to the corporate network.

Code Only a Mother Could Love: Writing Enterprise Software

If you ask a group of computer science students what they think they’ll be working on once they exchange tuition for paychecks, you’ll generally hear a mix of dreams and ambitions about projects and organizations that will allow them to impress members of the opposite sex at parties:

    Your company is not on this list

In reality, however, most of us will not end up writing software that the collective population of the computing world installs on their desktops, targets military drone strikes, or occupies the free time of a significant chunk of the world’s population. Instead, most of us end up writing Enterprise Software. On the face of it, we don’t think of enterprise software as being very hip – sure, you can feel good when you say you write mission critical “Enterprise Level” business apps, but does your mom get excited when she tells her bridge buddies that her baby boy spends his days writing a program that migrates sales data from Initrode, LLC’s online storefront to its data warehouse?

Well, maybe your mother’s catty friends won’t appreciate the finer points of a Multi-Tier Service Oriented Business Intelligence portal, but that doesn’t mean you won’t grow to love your bouncing baby codebase. Deep down, the reason we love developing software has very little to do with what our application actually does in the real world. No, our love of coding springs instead from something deeper – the process of creating something out of nothing with only our keyboard and compiler, and all the analysis, problem solving, and skill enhancement that comes along for the ride. That’s why we can have the time of our lives writing an Online Portal for Vendor Authorization Requests or some such nonsense.

Does this look familiar?

Unfortunately, most of the blogs out on the interwebs about writing software seem to ignore the lowly Enterprise Application, instead focusing on small start-ups, products downloaded by thousands of people, or public web applications. Enterprise Apps have their own set of issues, challenges, and considerations.

I intend for this blog to tackle the broader issues of software development from the perspective of The Rest of Us – those who labor long hours to build systems that less than a hundred people will ever use, who measure the install base of our products on one hand, who can talk to every one of their customers at the company picnic, and who regard the acronym “UAT” with equal senses of excitement and dread. The applications we write aren’t glam, they’re not cool, and they’re certainly not sexy, but we’ll agonize over a performance issue and hunt down a bug like it was a space shuttle launch controller. This blog is dedicated to Code Only a Mother Could Love.

Cross Posted at the Computer Technology Solution Blog