Apparently, with no hockey to watch, I am passing the time running numbers in Excel. I was thinking a little bit more about the NHLPA’s bullshit claim that the NHL should have used either their ten year revenue average of 9.4% or five year average of 7.8% instead of the 3% number they used when determining the impact of the NHLPA’s last proposal. I debunked that a few days ago, but I thought of another interesting angle -  if the players association really believed that revenue average, then I think they would be willing to accept a salary cap. Here’s why:

Based on the NHLPA’s proposal, it’s pretty clear they want the average team payroll to be around $50 million. Their proposed payroll tax doesn’t even start until you get to $45 million and is a pretty lame 20% until you get to $50 million (at that rate, a $50 million payroll would be taxed only $1 million) The current average team payroll is around $50 million and would be $40 after the NHLPA’s proposed 24% salary rollback. (Note – I realize $40 million appears to be a rollback of 20%, but there are some components of team payroll like benefits and payroll bonuses that are unaffected by the rollback.) Now, under the NHL’s proposal, the salary cap would be linked to overall revenue – as revenue goes up, salary cap goes up too. If revenues really went up by 7.8% per year, in three years the team salary cap would go up to $49.7 million. At 9.4% growth, the salary cap in 07-08 would be $51.7 million! So you get the NHL’s cost certainty while still driving salaries up to a level that the players want.

This disparity is really obvious when you look at the NHLPA’s revenue projection using five year historical league averages of revenue and player cost growth. In this model, revenue increases at 7.8% per year and player costs at 7.3%. If that were really true, wouldn’t the salary cap system actually be better for the players? Since their share of the overall revenue would stay the same, that would mean the total paid to players would also grow at 7.8% per year. At those rates, the NHL’s plan of linking player costs to revenue would mean nearly $20 million more for the players in 07-08 than their own plan.

So either the NHLPA is really bad at math, they want the owners to make more or even they don’t believe their own bullshit. I’m guessing door #3.

Chris jumped all over this Long Tail stuff after I sent him a link to the article and got me thinking. Maybe this thought has been expressed else where, but isn’t the Long Tail an updated version of the direct-to-video phenomenon? I mean, NetFlix may have more virtual shelf space than your neighborhood Blockbuster, but that video rental store has a similar size advantage over the local cineplex. A 10 theater cineplex shows around 200 different movies a year, given that most movies have a 2-3 week run. That’s a similar percentage compared to Blockbuster as Blockbuster compared to NetFlix. I wonder what percentage of Blockbuster (or NetFlix for that matter) rentals are never shown in theaters.

It took a while, but the major production houses eventually adapted to this phenomenon. Disney has had huge success with DtV including sequels of it’s biggest blockbusters. I would imagine that the media companies will adjust to the long tail phenomenon in the long run as well.

After seeing it on TSS.net, I checked out the X-develop product website. X-develop is a new multi-language cross-platform IDE that supports both .NET languages like VB.NET, C# and J# as well as Java. It includes support for all the .NET 2.0 features like generics as well as new Java 5.0 features like generics, varargs, enums and boxing.

When I checked out the website, I noticed a section covering “Custom Languages“. Here’s another example of bias against DSLs – this time in favor of “full grown OO languages”:

“The [X-develop] language plugin API is not limited to toy languages or little domain specific languages. Instead it supports full grown OO languages. In fact the support for Java, C#, J# and Visual Basic.NET is implemented as language plugins.” (Emphasis added)

This reminds me of the same kind of bias that was leveled against classic VB. Classic VB was valuable primarily because it was limited in scope and capability. But what it gave up in capability it gained in productivity. Along the same lines, DSLs are valuable because they are little, because they only focus on a single problem domain.

What exactly would be the value of another “full-grown OO language”? What features would be in a new full grown language that isn’t already in Java/J#, C# or VB.NET? The only feature I can think of is dynamic language support such as type inference and duck typing a la Ruby and Boo. What non-domain specific language features are you still waiting for?

Speaking of DSL Tools, Software Factories co-author Jack Greenfield just started blogging. He has jumped into the running debate between IBM’s Grady Booch and a variety of MS folks including Steve, Alan and myself. He does a good job summarizing the argument including pointing out where he and Booch agree:

In particular, we share the conviction that packaging knowledge for reuse in patterns, languages, frameworks, tools and other form factors is “the right next stage in cutting the Gordian knot of software”.

Jack rightly points out that while we all agree on these mechanisms for packaging knowledge that the devil is in the details. I look forward to seeing more on these details from Jack in the future.

Maybe it’s not as exciting as what my 2 year old has on tap for Xmas, but some of my Xmas came early when I got the new release of the DSL toolkit. The website isn’t updated yet, but the download is available.

This release is way beyond what the team shipped right after OOPSLA. For example, the code generation engine is in there now. So where you could only design the concepts of your modeling environment in the last release, now you can build a set of concepts in what is now called the Domain Model Designer, design a notation for that model using the Designer Definitions file (visual designer for this file to be a part of a future release) and build a set of code templates that can in turn generate code during the compilation process. Very cool.

I’ve only played with the updated walkthrus so far, but I’m pretty impressed. Major congrats to the team for getting this out. I saw Jochen in the cafe on Friday and discovered that the entire team has moved to building 25 which is right across the street from building 18 where my office is. Now I can go bother Jochen, Keith, Jack and the rest of the team without having to track all the way across campus! 😄