Monday, April 16, 2007

Silverlight: Based on the Microsoft .NET Framework

I came across a blog post from Brightcove which made my day. It indicated that Microsoft’s new name for WPF/E was Silverlight and that Brightcove would be looking at using the technology. So I hopped over to the supplied links and did a few searches. Some useful web pages on the subject include:



The main Silverlight web site contains these wonderful words:



“Based on the Microsoft .NET Framework”


Man that’s good to hear. The last CTP of the WPF/E technology had no CLR functionality at all and I was starting to worry. The .NET CLR functionality opens up a whole world of functionality to Torq Software business partners (my customers). I was surprised to see news of any of this sort of announcement until the Mix07 conference started. It will be good to start seeing some technical details of the Silverlight CLR functionality presumably by next month.


The only disappointing aspect is that there is absolutely no mention of Linux support. This would make the claim that it is “cross platform” much more reasonable instead of being limited to Windows and Mac. We’ll have to see how things pan out, but I’m hoping Microsoft “sees the light” and either provides a Linux version or at least not hamper the open source versions of the technology that will likely result.

Posted by Apolon at 2:18 PM | | Comments | links to this post

Tuesday, April 03, 2007

The Fallacy of Local Optimization

Scoble has an interview with the founders of Fog Creek. I smiled at this quote from Joel Spolsky:



That’s the big joke inside of Microsoft. Developers are rewarded for writing a lot of code and fixing a lot of bugs. So the incentive is to write a lot of code and write it very quickly.. Churn it..piles of code… buggy as all hell and then you get a bunch of bug reports and you fix them all and you will look a lot better than a slow methodical developer that gets from point A to point B in the same amount of time or even in less time because of the funny way that that metric might be used.


This is an example of “the fallacy of local optimization” which I first came across as a concept in the Poppendieck’s Lean Software Development book. Basically if you try and optimize locally (increase software development and reduce software faults/bugs) then you are likely to be far less effective and even introduce unwanted second order effects than if you optimized the whole. Lean principals are based on optimizing the whole and not optimizing a portion of your system (whatever it is). So basing incentives and on measuring some aspect of your business/process one level higher than you would expect is more effective for the business as a whole. Providing incentives or penalizing developers based on source code output and bug fix counts can potentially move developers to produce much more buggy code rather than the end goal of better quality software at an acceptable development cost. What I love about the lean principals is that they are “truisms” that apply to more than just software development.

Posted by Apolon at 9:25 AM | | Comments | links to this post