A tip on learning Silverlight. Throw away your code

You can stare at that blinking cursor inside Visual Studio all you want, it’s not going to give you an immediate insight into how you should architect your Silverlight solution so that it can be reusable and scale.

It’s not that you’re an idiot or aren’t good at programming, it’s just that you are trying to juggle learning Silverlight and building it at the same time. You’re already stressed, at making some bets around adopting the product or maybe you’re trying to still decide if this is still a good bet. Don’t add more layers of stress by trying to find a way to keep your entire code base re-usable.

Yes, your background in ASP.NET or WinForms is going to help you a lot going forward and i bet you have a bunch of best practices or albeit ones that you’re comfortable or at peace with (screw that guy who tells you you’re doing it wrong, did you ship? yes, well back off is what I'd say).

Silverlight is going to be different though, it’s going to require you to rethink a lot of things you’ve learnt in the past. Now you can blame the product for making you change your behavior, sure that can be an easy way out i guess, but you’re smarter than that and you adopted this for the right reasons. You’re rising to the challenge, and i’m telling you now, the code you right in the first phase of your adoption isn’t going to be poetic.

Stop wasting your time trying to build a framework that is scalable, you’ll do that in a few months. Instead, get used to the feeling of producing a solution one that you can throw away – yes i said it, throw away – in a few months from now.

Just ship. As time passes you’ll get experience, just like you did with the technology you’ve just spent x number of years spanking to death. Only this time, you’re going to be in the next early majority and you know what, it’s going to be more fun – i guarantee you.

I’ve spent close to 15 years programming for the web, i miss it. I enjoy it and I've used nearly all languages associated with the web (you name it, I've written an app for it) and for me as a Product Manager for Silverlight, I often grow jealous of the work you do.

Do me a favor though, practice more. As when I leave Product Management for Silverlight and I one day jump into the hot seat with you, I expect – no – demand you teach me what the best practices are.

The guys on my firewall can’t help you just yet, as we’re busy building the actual product itself, but soon once it stabilizes our teams over at Patterns & Practices and Framework crew, are going to show you the Microsoft way, but that doesn’t mean its the right way, it’s just our preferred way.

We hope by that stage you’ll contribute back and we’ll move forward in Rich Internet/Interactive Applications (RIA).

Throw away your code, trust me, you’ll be better next time.

Comments (3)

  1. By far the best article I have ever read on Silverlight.

  2. Couldn’t agree more.  Silverlight offers you a lot that other frameworks don’t (ASP.NET, Winforms etc) and people get caught up too quickly with MVVM, Commanding, Prism etc and over-architect applications. You think FaceBook was launched with a perfect architecture?

    I got into a discussion with someone recently about MVVM and how all new Silverlight apps need it.  I laid out a scenario "interactive BI application" that needed a lot of drag and drop, multithreaded activities. After talking for about 30 minutes, we agreed that an MVVM solution would require significantly more plumbing code to get it to work.

    This is why I agree moving to Silverlight is not trivial if you are not coming from WPF.  Unless you are really bright and have some R&D time on your hands…you won’t architect the perfect application the first time.  This is why "just ship it" works for me.

    BTW…currently working on my 3rd Silverlight business app and the architecture keeps getting better.

  3. Dale says:

    "Throw away your code, trust me, you’ll be better next time."

    I agree with you that throwing away code and starting with a clean sheet is lovely thing to be able to do.

    But in some of the (legacy) code I’ve worked on in the past, that’ll would need mapping out all the business logic, and then re-writing.  A code conversion/re-use would be much quicker.

Skip to main content