Microsoft OPEN.NET

Late last week we learned that Microsoft is de-funding the Iron projects (IronRuby, IronPython). Many have suggested that the community should take over the projects, but without access to the DLR, CLR and the compilers success would be limited.

However if Microsoft opened up the DLR, CLR and compilers for what I'm going to call "Open .NET", we in the community could make some interesting things happen on .NET.

I know it sounds crazy to open source the .NET platform, but I don't understand what competitive advantage Microsoft maintain by keeping it closed.

I want to mention a couple advantages they would gain by opening it up.

Allowing the community to create libraries and offer bug patches to the CLR, DLR and compiler we (the community) would feel involvement in the platform. This involvement would translate to more community created libraries and solutions.

Microsoft wouldn't have to create tools and libraries that already exist (ala MsTest) and focus their efforts on expanding the platform.

I'm not proposing that all products and innovation that is created by Microsoft shall be Open. They can build new technology within and around the open platform and release those changes to the community core projects after the product announcements.

Create native extensions for Windows that increased performance and scalability. Create products that only run on IIS or SharePoint. Microsoft's current "enterprise" customers would continue to use the proprietary and supported versions of the compilers and runtime.

Without an "Open.NET" Platform, projects like IronRuby and IronPython are not feasible outside of Microsoft. This innovation while secondary to Microsoft's corporate strategy is important to many of us in the community.

Scheduled Restart

I haven't been blogging for a while and have missed it. Twitter allows for quick quips and lunch/bar conversations allow for a deep introspection but I've been missing a venue to formalize my thoughts and to improve my writing ability.

Topics I will cover:

• Lean Software Development
• Test Driven Development
• Automated Acceptance Testing
• Technology Reviews
• Book Reviews
• Experience Reports
• ...and random posts when I need more that 140 characters.

Team Foundation Server forces teams toward open source solutions

Source control is the lowest common denominator with software development. All (...ok...most) software development teams have a system in place to manage the version of their software source code.
Within the Microsoft eco-system there are 2 options provided by Microsoft:

• Microsoft Source Safe
• Microsoft Team Foundation Server

SourceSafe has a bad reputation so within the last couple years, teams that develop on the Microsoft stack have been forced to limp along with Source Safe or upgrade to Team Foundation Server.
I don't want any one to get the impression that I don't like TFS; because I do. I like the integrated lifecycle, powerful reporting, task and project management tools. I like these things when they are needed. However, most mid-market software development shops don't need (or can't afford) all those tools.
But what if you want the tools? Have you ever tried to determine the pricing for a Team Systems rollout? Can somebody tell me how much it will cost to roll out TFS for a development team of 10 developers? I've tried to do the pricing, but can't navigate the licensing.
So what should you do if you need a source control tool?
a.) Spend a couple days putting together a proposal to submit to your boss, who will submit it to her boss which will ultimately be rejected for "Budgeting Reasons".
b.) Do you stick with Source Safe? Not because you want to or think it's the best solution but because it's the only other alternative from Microsoft?
c.) Or do you install a Subversion Repository (free + time) on an existing server (free), install TortoiseSVN (free + time) on the developer workstations and hold a day of training with the development staff (time)?

Agile defined with one photo

I got this photo today at work when a co-worker recommend a couple alternative strategies. I love it and had to share!
 
From: http://www.michaelsalamon.com/?p=20

Full-time "Gig"

After a short contract at a major financial company, I have accepted a full time job at Two Rivers Marketing.
We have a fairly large team (~15) of software developers, user interface designers, and Flash designers.
Tools are not the most important part of a company, but they can tell you about the "development eco-system". What do these tools tell you about our eco-system?
Subversion
NHibernate
NUnit
Log4Net
Rhino Mocks
NAnt

Twin$

Jody, Sadie and I are expecting twins (one boy/one girl) in April. . We are excited and freaking out all at the same time.
To prepare, we are building a new 4 bedroom home west of Jordan Creek Town Center.
Wish us luck!

One Simple Metric

At our last Agile Iowa meeting on Thursday, Jared Richardson, he was talking about Agile Testing Strategies. He mentioned a metric he used that I found very interesting. He took three variables and created a report that listed the top 10 method/assemblies that were at risk.
Here is the (simple) equation:

Cyclomatic Complexity (CC):
Usage (U): How many other methods/classes rely on this code.
Test Coverage Percentage (TC): The percentage of the code that is exercised by a unit test
Risk Factor = CC x U x (1 - TC)

Let's look at a couple examples:
This first table shows a method used by 50 other methods (Usage) with a Cyclomatic complexity (CC) of 20. I then vary the code coverage for this method. Without any unit tests, the risk factor is a cool "g" (or Grand). As the test coverage increases the Risk Factor decreases. When the test coverage reaches 100%, the Risk Factor is reduced to zero. The function is linear, so decreasing the usage or the complexity will also reduce the Risk Factor. So it make sense that if a method isn't used, it has a risk factor of zero.

CC	Usage	Code Coverage	Risk Factor
20	50	0	1,000
20	50	0.1	900
20	50	0.5	500
20	50	0.9	100

The following methods all have the same risk factor of 250. Do you think this is reasonable? Should one of these factors be weighted heavier?

CC	Usage	Code Coverage	Risk Factor
10	50	.5	250
50	10	0.5	250
50	50	0.9	250

For now I'm going to see how I can get the usage and the code coverage numbers automated... I can tweak the algorithm more later.