Windows Development – When to Upgrade Windows Developers to the Latest Release

How I Learned to Stop Worrying and Love the MS-Stack

You can still run VB6 apps on windows 8. Retro-compatibility for good or bad has always been a trend in the MS ecosystem. You shouldn't worry about the survival of technologies like WPF / Silveright, and even winforms for that matter.

On the other hand, you have to accept that for a long term project, you will never have the latest, cutiest technology.

In fact the questions you should ask yourself about the choice of a technology are :

• Is my team comfortable enough with that technology to be productive?
• Is my team happy to use that technology?
• Can I recruit people for that technology?

That's the combination of the answers to this questions that should lead your choice, and not the trends forged mainly for marketing reasons.

For more about this thematic of ever-changing technology, you should read "Fire And Motion" By Joel Spolsky :

The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it's just cover fire so that they can move forward and you can't, because this is how the game is played, Bubby. Are you going to support Hailstorm? SOAP? RDF? Are you supporting it because your customers need it, or because someone is firing at you and you feel like you have to respond? The sales teams of the big companies understand cover fire.

And that was written nearly ten years ago.

Architecture and Technologies

Architecture and Technologies are two separate things and choices to do :

• You can do MVC with winforms.
• You can do MVVM with WPF/Silverlight.
• You can do MVC with ASP.NET.
• You can do whatever you want, including MVC and MVVM, with WINRT as far as we know.
• You can go functional with F#. Why not ? There are domains where it would make sense.
• You can mix all of them, to have different entry points to a common system, then be mocked because it gets too complicated, etc.

You can use services, resources, third party controls, ORMs, etc. with all this technologies, and maybe, or maybe not, with the next ones.

You can twist and bend MVC in many ways with all those technologies : Binding or not ? code behind view or not ? Controller or not ? ViewModel everytime or only when needed ? There are so many ways to implement a design pattern, even within the scope of one specific technology.

That would be irrealistic to force you into one of them without advanced knowledge of your project and team. It would only be based on personal preferences, and would end-up in a "my technology is better than yours" showdown.

The only thing that can be honestly and objectively suggested is to use the best practices you can apply to create an architecture that will stand the test of time, and maybe, really maybe will be portable or reused at least in parts with a future unknown technology. And that upgradability/portability shouldn't even be the main purpose of your architecture.

The main purpose of your architecture and choosed technology is to deliver a product to your boss/customer that meets his realistic requirements.

MVC (and it's younger brother MVVM) proved more and more to be a basis for robust architecture since 1979 in the OOP languages arena and beyond. But choosing what specific technology should be used in a 10 years long project should remain your decision.

Using feature flags could help. Basically a feature flag tells the system whether a user should see a given piece of functionality. For example, if you just added a user settings option then you could wrap that with a feature flag to control who sees the feature. Some of the criteria a feature flag can consider include:

• Global setting (allow everybody or nobody)
• Specific users (allow specific beta users)
• Random users (allow a percentage of users, e.g. for A/B testing)
• Timestamp (allow use after the launch date or during a specific time of day)

Feature flags can compliment use of load balancing and staggered deployments. For example, if you want to go live with a feature at a precise time, you'd do a staggered deployment and then flip the switch. More generally, this allows you to change the behavior of the running site without being as dependent on how deployments are timed.