You gotta love that some at Microsoft actually have a sense of humor! From the PopFly FAQ (emphasis mine):

Why did you call it Popfly?

Well, left to our own devices we would have called it "Microsoft Visual Mashup Creator Express, May 2007 Community Tech Preview Internet Edition," but instead we asked some folks for help and they suggested some cool names and we all liked Popfly.

Ok, for those who have been keeping up with Mike Gunderloy this is old news but I just ran across it. Mike is one of the most prolific writer/developers I know and one of those rare breed that can evidently learn new technologies in no time flat.

Mike has been working with Microsoft technologies for about fifteen years, but it seems he's gotten fed up with Microsoft. Even though he is continuing his blog of links to info and tools of interest to .NET developers at The Daily Grind, he has started a new blog named A Fresh Cup where he explores his search for an alternative development platform. 

Here is an except of his initial post:

...I’ve spent the bulk of the last fifteen years developing some amount of reputation and expertise in the Microsoft universe...

Unfortunately, over that time I’ve also come to the conclusion that, even though it is staffed largely by smart and ethical people, Microsoft itself represents a grave threat to the future of software development through its increasing inclination to stifle competition through legal shenanigans....

...I can’t afford to just walk out on a career that brings in good money. But I rather desperately want to find an alternative. This blog will record some of my explorations as I hunt around in other corners of the software world, trying to decide if there’s a viable business plan for me that can include weaning myself off of Microsoft software.

So it seems like I'm not the only one who has gotten frustrated with Microsoft as of late.

David Laribee just referenced my IIS 7.0: Too Little, Too Late? post and he made an interesting comment that I hadn't previously pondered but that is very relevent:

It’s a major bummer that there’s no such thing as a virtualized “.NET Application Container” for the new scalable grid computing and provisioning services coming out (Amazon EC2, MediaTemple’s Grid-Server). Essentially .NET programmers can’t easily take advantage of new long tail models with easily-sourced infrastructure services. Going out on a limb, I’d suggest these limitations contribute to a lot of top/entrepreneurial developer talent moving over to various flavors of the LAMP stack, Ruby, etc.

I think this is yet another area where Microsoft is missing the ball. And it is related to the fact that people can't build and distribute Windows-based stacks as appliances (i.e. because of licensing issues) in the same way people can build and distribute them for Linux. Mark my words, these two aspects are a significant achillie's heel for Microsoft and will have significant import in the further decline of the Windows Server and .NET platform.

Back in January 2006, I blogged about how much I wanted an IIS 7.0 that handles extensionless URL rewriting. Well this week I just got my March 2007 copy of Microsoft's MSDN Magazine in which they ran a detailed technical preview of the features and functionality of Internet Information Server 7.0. Reading through it, I found myself salivating over it's capabilities that I've needed for literally a decade. Those who follow some of my other escapades know that the #1 feature I want it to provide over IIS 6.0 and prior is the ability to fully control the URL with our without an extension.

Yet, something is different now. Five years ago I would metaphorically have killed for that functionality. Even a few years ago, I wanted it badly. But reading about all the great things in IIS 7.0 today for future availability on server hosting platforms next God-knows-when (i.e. after Longhorn ships *and* most Windows-offering web hosts upgrade) sadly comes across to me as just too little, too late.

Too Little

Too little because Microsoft won't deliver IIS 7.0 to run on Windows 2003 Server necessitating a costly and in some cases problematic operating system upgrade. This will drastically limit the number of situations in which people can choose to switch to develop for the new features of IIS 7.0. For example, when the funds for operating system upgrades are not in the budget or simply because the developer doesn't have the corporate clout to convince management of the need to upgrade. 

And the only people who will even be able to experiment with IIS 7.0 will be those with Windows Vista. And since upgrading to Vista also requires funds and often new hardware, it is not a foregone conclusion. Consequently there will only be a small percentage of Microsoft-centric developers writing web apps that uses the functionality of IIS 7.0 over the next several years. Given the limitations of IIS 6.0, I just find this scenario to be unacceptable.

Too Late

Too late because Microsoft's outdated process and slow release cycle, which I blogged about last month, has given rise to compelling alternatives on the Linux platform.  And Apache has has many of the key features that IIS 7.0 provides, most importantly via it's mod_rewrite functionality, that by the time IIS 7.0 is ready for prime time, there's a good chance only a tiny percentage of web developers will care. I for one need to develop web apps I can run on web hosts today, not wait around and dream for some yet-to-be-determined future brighter day.

Microsoft, the rules have changed and you are not immune. You can no longer schedule product updates years out and expect people to wait to pay you for them years from now when free-to-use open-source alternatives addressing the same need exist today. I can no longer bring myself to design or run a web app on IIS 6.0[1] when the URL management functionality I crave is already available on Apache. And by the time IIS 7.0 is released I doubt I'll even consider running an IIS server.

Unless...

However Microsoft, there is a solution if you will only listen, which I highly doubt. Microsoft You should know more than any other tech company that your key to success is getting developers to write programs for your platforms. Yet on the web developers are voting with their feet and most new web applications not sponsored by a "You don't get fired for buying Microsoft" large company IT organization are choosing to build on Linux and Apache.  IIS was once the leading server on the web, but today it can barely eek out more than 1/3rd market share. If you don't stem this time, things will only get worse. Much worse.

Here's what to do: Release IIS 7.0 as an update for Windows 2003 Server and Windows XP that gets installed automatically via Windows update. Offer it in parallel to IIS 6.0 so it must first be configured by an admin and IIS 6.0 disabled, if necessary. Feel free to restrict it in whatever ways you must given 2003/XP's lack of Longhorn/Vista infrastructure, but don't use that as an excuse to eliminate key features such as URL management and HTTP response filtering. Doing this won't change the minds of those who have already given up on Windows, but it will certainly minimize the profuse bleeding.

Footnotes

1. Given how much I dislike ASP.NET and how frustrated I am with IIS 6.0, I can't wait till I find the time to move my blog to another program besides dasBlog.

While I'm not in the habit of link blogging, Jason Kolb blogged a similar take to my recent themes about Microsoft entitled Five Not-So-Easy Steps to Save Microsoft. Jason starts with:

Let me stick a disclaimer on the front of this post: I cut my teeth on Microsoft technology and have been a big supporter of them in the past. I would really like this company to survive because otherwise I’m going to have a lot of useless knowledge cluttering up my brain. However, I am a realist and this is a company in a dangerous situation. It saddens me to see this once great company slowly dying, and I hope they do something to stop the bleeding before it’s too late.

Microsoft is in an interesting situation right now. Their monopoly is fading fast, and the only product they have that’s driving any significant level of buzz is the Xbox 360. They’ve gone from  absolutely dominating the technology space to almost falling out of the cutting-edge technology consciousness. They’ve done very little in the past couple of years to enhance their standing as a leading technology company, and I think a lot of people view them as living in the past.

He continues with (emphasis mine):

I think Microsoft is in a precarious situation right now--it’s on the verge of becoming irrelevant. The reason Microsoft has been so dominant over the past twenty years is because they have not only courted programmers, but they (it) made much easier for programmers to use their technology as a platform than anything(body) else. This resulted in the majority of mainstream software being written for Windows. Which resulted in more people buying Windows, which resulted in more developers writing for Windows. It was a catch-22 in favor of Microsoft, and they made money hand over fist because of it.

That's what I've been saying recently, though my posts came from a slightly different angle. Jason's take is that operating systems and language no longer matter (emphasis mine):

The result of this software lifecycle shift has been that developing for a mass audience has a lot less to do with the operating system and a lot more to do with the end-user experience. The language and platform no longer matter, it’s just the end result now. In fact, more than which operating system or language is used, it’s now the ability to scale on an as-needed basis that is the primary requirement for applications. Microsoft fails miserably at this requirement because of their licensing model and the way they try to monetize their software, which they haven’t really changed since the 1980’s.  Just from keeping an eye on the Net I sense a mass migration to open source development platforms, and the search trends seem to back that up--as a bonus bad omen, the news volume for their languages is practically non-existant.

While I don't disagree with his main premise, I don't completely agree that the language and platform don't matter; they are still what is used to create and host applications, be they local or on the web, and those things take time to learn and build expertise in. Jason even acknowledges that at the start by saying "...otherwise I’m going to have a lot of useless knowledge cluttering up my brain."

In my (humble :) opinion, the problem is more in Microsoft's licensing model which makes it so much easier for people to choose open-source. And I believe people are choosing open-source in droves over Microsoft's solutions as I know I am starting to. Jason addressed this point in the last paragraph above by saying: "Microsoft fails miserably...because of their licensing model and the way they try to monetize their software, which they haven’t really changed since the 1980’s."

Jason then goes on to recommend the following five (5) "not so easy" steps to fix Microsoft, which I think are spot-on (except for the last one, that's at the same time both obvious and too vague to be an action item):

1. Release .NET as open source.
2. Release Windows as open source.
3. Release a SaaS version of Office, ASAP.
4. Find a Steve Jobs clone.
5. Start innovating again.

Jason of course goes into far more detail and his post is definitely worth a read if you care about these things. Oh, there is one final pull quote I'll reference on his second step to drive the point home (emphasis mine):

What’s really going to hurt them, however, is the licensing model for the server products. When you compare the cost of running and scaling a Windows-based application versus running and scaling on Linux, it becomes a no-brainer. I can’t think of a single good reason for developing a SaaS application for Windows when you’ll be paying Microsoft licensing fees every time you need to scale, and you could be getting that software for free using Linux. Microsoft needs to consider the operating systems loss leaders and an incredibly powerful way to market their other products, before everyone stops developing for them and everyone stops using them as a result.

Via Ben Coffey.

P.S. I have numerous posts that are in various stages of completion covering some of this same ground from, again, a slightly different angle. But when I finalize and post them, please don't think them a copy-cat of Jason's post. :)  This is such an obvious area to discuss these day's, there are lots of similar independent thoughts, for hopefully obvious reason.

 

 

Microsoft's Developer Network has lots of cool stuff this month. From all the different components of Office Ultimate 2007 such as Groove 2007, InfoPath 2007, OneNote 2007, Project Professional 2007 and Project Server 2007, to Windows Vista, to the .NET Framework 2.0 and .NET Compact Framework 2.0 and more, there's lots to keep Micrsoftistas busy this month. :)

Don't have a subscription? You really should consider getting one; it really is a great deal.

See below for a list of the discs shipped (I omitted the index CD because they always ship that):

Disc 2426.23

• Windows SharePoint Services with SP2 (All Languages)
• Windows Vista Software Development Kit (SDK)
• DirectX SDK (October 2006)
• Speech Application Software Development Kit 1.1
• Windows Server 2003 with SP1 DDK
• Platform SDK for Windows Server 2003 R2 March 2006 Edition
• Microsoft .NET Framework Version 2.0 (English, German, Japanese)

Disc 2429.5

ISO Images for:

• Windows Vista
• Windows XP Professional with SP2

Disc 2434.16

• Microsoft Office Business Scorecard Manager 2005
• Office Groove 2007
• Office InfoPath 2007
• Office OneNote 2007
• Microsoft Office Project Professional 2007
• Microsoft Office Project Server 2007
• Office SharePoint Server 2007
• Microsoft Office Ultimate 2007
• Office Visio Professional 2007

Disc 3345.2

• Microsoft .NET Compact Framework 2.0 SP1 Redistributable (English, French, German, Italian, Japanese, Korean, Potruguese-Brazilian, Simplified Chinese, Spanish, Traditional Chinese)
• Microsoft .NET Framework 2.0 SDK (x86, IA64)
• Microsoft .NET Framework Version 2.0 Redistributable Packages (x86, x64, IA64) (German, Japanese)
• Windows Vista Windows Driver Kit (WDK)

Disc 3707

• Windows Vista

Disc 3708

• Windows Vista (x64)

In October 2005 I blogged about the need for a Server for End Users. I guess Microsoft was listening. ;-)

From Larry Dignan over on ZDNet.

Contents

• Defining "Occupational Programmer"
• Professionals need Industrial Strength
• Hobbyists need to Learn
• Occupational Programmers need Productivity
• Occupational Programmers need Discovery
• Occupational Programmers need to Experiment
• Occupational Programmers need Progressive Disclosure
• Occupational Programmers need their Skills Grown
• But Don't Sandbox Occupational Programmers
• Focus on Languages and Frameworks, not GUI Tools
• Not Hard to Serve this HUGE Market
• Other References
• I'm Available...
• Comments

---

Defining "Occupational Programmer"

I made two posts recently that muddled serveral issues so I am creating a seperate post here to isolate them and provide a location for comments specific to this issue:

Microsoft is not meeting the needs of "Occupational Programmers."

The first thing I should do is define the term "Occupational Programmer":

"An Occupational Programmer is one whose job is something besides programming. The programs they write are related to their main job such as streamlining tedious processes or automating labor intensive tasks. These people only spend a small percentage of their time programming."

Professionals need Industrial Strength

Occupational programmers have significantly different needs than professional programmers or even hobbyists. Professional programmers need industrial strength developer tools. I could blather on forever defining that but I think most professional programmers know what they need as that's what they focus all their time doing.

Hobbyists need to Learn

Hobbyist programmers main need is to learn. For them each learning experience grows on the past. Further, I would argue most hobbyist programmers are either younger (i.e. in elementary school, high school, or even college with a lot of free time on their hands) or older (i.e. retired and looking for something fun to exercise their brain.) I'm sure there are many hobbyists in between but I'd argue they are not the majority. Hobbyists goal is often to get better at programming, and I believe they are by definition both passionate about it and interested in learning in ways that occupational programmers simply are not.

Occupational Programmers need Productivity

Occupational programmers don't have time to learn; they've got a real job to worry about. And occupational programmers often don't care about learning the intricasies of programming at a professional level. Most importantly, occupational programmers don't program frequently enough to transfer their learning from short to long term memory. Tellingly, Microsoft has a Coding4Fun website for hobbyists, but doesn't have a Coding4Work website for occupational programmers!

Occupational Programmers need Discovery

Occupational programmers also need to be able to discover how to do things without lots of prerequisite knowledge. They need to be able to be highly productive every time the sit down to code. In that vein Microsoft's "My" object is intuitive enough and addresses discovery.

Occupational Programmers need to Experiment

On the other hand, occupational programmers need to painlessly try things to see what works and not be distracted by lots of complexity. It is here where even Microsoft's Express Editions fall short. They need a far simplier environment that allows them to type in a single line of code, highlight it, and then press a key to run it; no other prerequisites required. And if, for example, the code won't run because of a missing reference the environment should pop up a suggestion based on an index of all available components on the user's system, the occupational programmer should never be left trying to figure out where to go next to solve his problem.

In other words the occupational programmer needs a powerful interpreter but one that works more like SQL Query Analyzer than a command line interpreter. SQL Query Analyzer's is it's "canvas" that allows one to leave lots code lying around in various states of completion while it only executes the code that the user has currently highlighted.

Occupational Programmers need Progressive Disclosure

occupational programmers need Progressive Disclosure. They shouldn't open up a development environment with numerous items competing for their attention. They shouldn't have to worry about projects or properties or toolboxes, they should have a screen where they can start writing code and the equivalent of a (well designed) "Start" button and menu/wizard system.

Occupational Programmers need their Skills Grown

Additionally, the languages and tools used by occupational programmers should empower they to continually improve their skills without even trying, as they end up building significant systems over time. Some will even change careers to become full-time professional programmers eventually. If they are sandboxed with dead-end language and environment, think VBA or Visual Studio Tools for Applications, that's no good either.

But Don't Sandbox Occupational Programmers

And occupational programmers should be given the same languages professional developers use, but in a less-restrictive form; one potential example being a dynamic version of VB.NET with duck typing, etc. This is so professional developers can reuse and refactor the occupational programmer's components and code. Occupational programmers have specialized knowledge that professional developers simply don't have and putting them in two different sandboxes doesn't make sense.

Focus on Languages and Frameworks, not GUI Tools

Further, the tool builders should focus on language and framework first, not the visual tools. Although this applies across the board for developer tools, it's especially important to state related to occupational programmers because the tendancy is to just throw lots of GUI at less experienced developers, but that approach is fraught with peril (anyone remember Visual InterDev Design Time Controls?) I can acutally write a long post on this topic alone, and plan to, but suffice it to say that the focus should be on making it very easy to implement something in code using the language and the framework, and then create the visual tools to streamline this last.

Not Hard to Serve this HUGE Market

I believe there are tremendous number of occupational programmers out there whose needs are not being served and the irony is that I'm not proposing anything complex. On the contrary, Microsoft has partically all the technology it needs to build and ship the first version of what I'm envisioning within six months or less assuming a 3 to 5 person "SWAT team" that's sheltered from politics (by 3 to 5 people I mean everyone; development, testing, documentation, marketing, etc.) It would be a tiny investment, and if it was released below the radar and sans Microsoft's full hype machine it's benefit to prospective users could be evaluated before they committing Microsoft to supporting any legacies it might create. And Microsoft could call this tool "Power Developer" (I chose that name because of PowerShell.)

There's a lot more I could say on this issue (and I've said some of it in the past), but I'll leave it at this and await your comments.

Other References

P.S. Here are some posts I made over 2.5 years ago on this and related subjects:

• Why .NET needs the (option of) less strictness (2004-March-19)
• Woe be it for the Hobbyist Programmer (2004-March-15)
• A Modest Proposal: VBScript.NET, aka "Helping Mort use .NET" (2004-March-11)
• Development Tools Need Transitionality (2004-March-10)

And these are some posts over people have made and/or posts with related comments, in no particular order:

• Reclaiming the Soul of VB
• Save the Hobbyist Programmer
• Many responses to Kathleen Dollard's op-ed piece on Occupational (aka Hobbyist) programmers
• Thoughts on creating a .NET language targeted at "occupational" programmers
• Why do hobbyists matter?
• Article: In pursuit of perfection. New Year Resolutions for Java
• Windows Powershell: Encoding Operations Knowledge
• The Hobbyist Renaissance at Microsoft

I'm Available...

P.P.S. If any decision makers at Microsoft are listening but don't currently have the right person on the inside to champion this idea, they should be aware that I am, at the time of this writing, available to help. :)

I made two posts recently that muddled serveral issues so I am creating a seperate post here to isolate them and provide a location for comments specific to this issue:

Microsoft is loosing the battle with its open-source competition in languages and web frameworks because of their obsolete processes and release cycles

In summary, it's my belief that the processes and release cycle for designing, building and releasing developer tools as well as for attracting developers that worked so well in the 80's and 90's are now obsolute when compared to the process in use by the open-source community. Further I believe that if Microsoft doesn't completely rethink how it manages it's processes and release cycle for designing, building and releasing developer tools in a manner that is competitive with the open-source process that it will slip farther and farther behind until it's developers tools become irrelevent. Of course as that happens Microsoft's platforms will also slowly decline in relevence until it is simply no longer the main player but instead one of many.

That's not to say they are not doing some things right, they are. But they need revolution not evolution to stay the major player in developer tools.

I made two posts recently discussing Microsoft's Developer Division. Although I had strong feelings about the issues, my thoughts were still too unclear to be succinct. But writing clarifies thought and I had already waited too long to post so a'posting I went.

Reading the comments it became clear I had muddled several issues:

1. How Open-Source competition for languages and web frameworks are exploiting Microsoft's obsolete process and release cycle
2. How Microsoft is not addressing the needs of the "Occupational Programmer"
3. My own personal frustrations as an occupational programmer with Microsoft's obsolete process and release cycle

Since few if any likely to care about my personal frustrations if they are not framed in broader need, I won't belabor point #3 but I will address points #1 and #2 as seperate issues in my next posts.

UPDATE - (2007-Jan-01): Both of those posts are now live:

• Microsoft's Obsolete Process and Release Cycle
• Will Microsoft Meet Occupational Programmer's Needs?

Contents

• I Ranted and Eric Rebutted
• While I Respect the People at Microsoft...
• ...They Become Detached
• Eric Unconsciously Supports my Thesis!
• Dismissing the Proposal, Not Solving the Problem
• Not More Power; Transitionality!
• Today's Potential Didn't Address Yesterday's Deficiency
• Nor Does an Orphan Address Yesterday's Deficiency
• And a Potential isn't a Solution
• Yes, there's Powershell, but...
• A Correct yet Irrelevant Point
• Interest Doesn't Necessarily Change Process
• A Solution Offered; Wrong Product, Years from Now
• Too Little, Too Late: Acknowledged
• Studying Users Isn't Feeling their Pain
• Trade-offs that Shortchange Developers
• Experiencing Pain Empowers Real Solutions
• Yes it is a Paradox...
• ...But Solve it You Must, Or Else
• Change, or Be Changed
• What if I'm Not Wrong?
• Comments

---

I Ranted and Eric Rebutted

The day before yesterday I wrote a long winded and rambling rant about how Microsoft's release cycle and process for creating developer tools. I commented on how I believe it is making them fall behind and causing many formerly loyal Microsoft developers to look at open source solutions on non-Windows platforms. I referenced a post that Microsoft's Eric Lippert wrote over 2.5 years ago titled Top Minds Are Working On It[1]. In retrospect it might have appeared I was being critical of Eric but that wasn't my intention, and if that's how I came across I apologize. Instead I was referencing Eric's comments as symptomatic of the Microsoft culture at large. And yesterday I awoke to find that Eric had issued a rebuttal.

While I Respect the People at Microsoft...

But before I address his comments let me talk about Eric and all the others I've met from Microsoft. Eric is actually a brilliant guy, and very likeable. I've met Eric face-to-face and it's obvious he's much smarter than me. But then I could say that about most of those I've met from Microsoft; they don't hire dummies. As a rule I've been impressed with every Microsoft employee I've met. They are super bright and AFAICT they do really want to do "Good Things(tm)".

...They Become Detached

But group dynamics being what they are, when you get a group of super-bright people together they become competitive, hone their debate skills, and learn to be strong advocates for whatever their own positions. And they can become detached from the outside world, much like politicians in high office. Politicians are also typically super bright, and most enter office wanting to do Good Things(tm), but once "on the inside" they loose touch with the concerns of their constituents. So I am not condemning Eric and his Microsoft colleagues, I am merely commenting on the culture that results and collectively channels them.

Eric Unconsciously Supports my Thesis!

So I started yesterday's post saying I'd been planning to blog on the topic for a while but the reality was I still didn't know how best to explain my concerns. But for better or for worse I did write a rambling essay yesterday, but ironically Eric's comments made my points far better than I! My central thesis was that Microsoft isn't meeting developer's needs because of their processes and infrequent releases and consequently open-source alternatives are meeting developer's needs instead. Eric's both debated my examples and pointed out they now plan to address some issues I referenced. But not only did Eric not address my central thesis, he ironically supported it given his rebuttal's choice of focus!

In my post I wrote the following:

"Microsoft's culture is to argue semantics when reality doesn't match their world view"

And Eric's comments proceeded to do exactly that! In my post from 2.5 years ago[1] I called for Microsoft to address things that PHP, Ruby, and Python are addressing today, which Eric rebutted at the time. In yesterday's rebuttal Eric referenced his earlier comments stating (emphasis mine):

"Second, my 'esoteric' reasons for not implementing a scripty version of VB on the .NET platform were hardly esoteric then and are hardly esoteric now. They are (1) fracturing the language further causes confusion amongst customers and is massively expensive for little gain, ..."

Dismissing the Proposal, Not Solving the Problem

Now I'll freely admit Eric is far more qualified to evaluate my suggestion on technical merit, but that wasn't the point of my 2.5 year old post. Customers with needs a company's not addressing will often propose solutions they believe will address their needs, yet often their suggestions aren't workable for whatever reason. People who specialize in addressing customer needs know that rather than dismiss suggestions as unworkable it's far better to determine the customer's actual needs and implement a workable solution instead. And often, many other customers have those same needs. So Eric dismissed my proposed solution but didn't address my unresolved needs that prompted the proposal. I don't attribute this failing to Eric, I attribute it to Microsoft's current culture.

Not More Power; Transitionality!

Eric then went on to say:

"(2) we can do things to make VB.NET more powerful without fracturing the language,..."

Ironically, I didn't ask for a more powerful VB.NET; I asked for one that was easier to start using and one that developers could then easily transition to more powerful usage. Though they believed they were providing an easier to use Visual Basic 2005, they addressed the language but not how people develop applications. Though they made strides with the Express Edition, my biggest concern was with the complexity of the development environment and the language. I suggested an interpretive environment with a transitional language design that allowed new developers to start easily yet be able to effortlessly grow their expertise with use. What I envisioned was something like Boo, but I wanted it 2.5 years ago with a simple interpretive environment, and I wanted it from Microsoft so that it could possibly generate a large and immediate and user base with a thriving community and significant peer support.

Today's Potential Didn't Address Yesterday's Deficiency

Eric continued with the following...:

"(3) Microsoft makes scripting languages like Iron Python"

...but omitted the fact that a robust Iron Python was just a gleam in Jim Hugunin's eye 2.5 years ago and is still not ready for prime time. Further, Microsoft's approach is to host IronPython in Visual Studio which does nothing to bypass the complexity of Visual Studio!

Nor Does an Orphan Address Yesterday's Deficiency

Eric then said:

"...and JScript .NET, use the right tool for the right job."

To which I did a double take wondering if he were really serious! JScript .NET is such the orphan that I can't even believe he suggested it! The JScript .NET newsgroup has less than a screen full of messages, JScript .NET hasn't been updated since 2003, and nobody's even written about JScript .NET in years! So could Eric really have been serious when he suggested JScript .NET? Well, assuming he was, then:

• JScript .NET does NOT have an easy-to-use interpretive environment, and
• JScript .NET is a complex language; NOT simple-to-use, and
• Again, JScript .NET has NO user-base!

And a Potential isn't a Solution

Moving on Eric said:

"The .NET framework is already amenable to the development of scripting languages."

So why do we still not have a viable scripting solution for .NET supported from Microsoft more than half a decade after the .NET Framework's first release?

Yes, there's Powershell, but...

Okay, that's not quite true. Eric didn't mention it but in the spirit of honest debate, there is Microsoft's PowerShell. But while I will freely admit PowerShell is really nice, PowerShell:

1. Was only just released so doesn't address the past 2.5 years,
2. Doesn't have a development environment,
3. Can't be used for web development,
4. Doesn't have a compiler for creating components for use in other .NET languages.
5. Doesn't have transitionality allowing it to scale up for much more complex projects as the developer's experience grows.

A Correct yet Irrelevant Point

Eric then makes a point about "scripting languages" vs. "dynamic languages" (emphasis mine):

"Third, I want to make a distinction between scripting languages (languages intended to script things) and dynamic languages (languages which admit a type system which cannot be deeply analyzed at compile time.) Scripting languages are often dynamic languages, however it is entirely possible to use dynamic languages for tasks other than scripting. "

Okay... So Eric's points are very technically valid, but they are totally irrelevant! Frankly I wasn't asking for a language that was "intended to script things," I was proposing a language (and IDE) that would be:

1. Productive,
2. Easy to start using, and
3. Scalable as one's skills evolve.

Call it "scripting", call it a "dynamic language", call it whatever; it's irrelevant. What is relevant is for it to be productive, easy, and scalable. Microsoft could choose to get there however they will, bit like arguing the semantics of "Car" vs. "SUV" with someone who just needs transportation, Eric's distinctions were simply irrelevant to the needs.

Totally unrelated, I ran across this joke yesterday. What could be more ironic?

Interest Doesn't Necessarily Change Process

Eric finishes his prior point with:

"The VS team is VERY interested in understanding how to make the platform more amenable to dynamic languages."

Great! But are they going to actually engage people who are not .NET developers in the design of said dynamic languages and their respective development environments and then incorporate their feedback? Or is the VS Team just going to plug another dynamic language into Visual Studio? If the latter they will do so ignoring that Visual Studio users already have the language(s) they need and that there are at least an order of magnitude more people for whom Visual Studio is too overwhelming.

A Solution Offered; Wrong Product, Years from Now

A couple other comments Eric made were:

"C# 3.0 will have the "one line auto-implemented properties" feature you requested for VB. Enough people asked for it, we put it in. I do not know if VB will be doing the same. You're welcome. "

and

"Current C# 3.0 features move in the direction of dynamic languages without actually making the language dynamic (lambdas, improved generic method type inference, extension methods, implicitly typed locals, anonymous tuple types). All of these however are implemented so as to keep the language statically analyzable. We are considering features for C# 4.0 which would make the language more dynamic without losing that important statically analyzable core."

That's well and good, but it doesn't address VB.NET, and it also makes my own point that Microsoft's release cycles are too far apart! There are badly needed enhancements and they need to get them to developers more often than once every three years. C# 3.0 is still a way's out, people need something today, and I personally wonder if I'll even care about programming by the time C# 4.0 is released. Hell, I hope to have made my fortune and be retired by then! :-)

But seriously, C# is a professional developer's language and adding features to a professional developer's language wasn't even close to what I was proposing.

Too Little, Too Late: Acknowledged

In the last paragraph, Eric finally gives tacit acknowledgement of the concerns I raised in yesterdays post:

"Now, maybe these features aren't what you want, or are too little too late, or the release schedule is too long for your liking, or whatever. That's unfortunate."

Exactly. The release cycle needs to be compressed by an order of magnitude as it has been at the competition. More on this in a bit.

Studying Users Isn't Feeling their Pain

Eric then signs off with:

"However I take exception to the claim that we do not study what real users are doing and try to provide tools that do what they want. We do that every day."

With this Eric either misunderstood my point, or more likely I didn't state my point in a manner that was understandable. Whichever the case, let me clarify. I know the VS Team works hard to study real user's needs every day. But what I also know is that the people who make the decisions about what gets released and when have considerations that are far different from the needs of developers. And it is human nature for one to place solving one's own pains ahead of solving the pains of others as people simple can't fully comprehend pains they don't experience.

Trade-offs that Shortchange Developers

Eric let's be concrete; if solving a customer problem today will cause the VS team a problem tomorrow they won't do it. For example if the VS Team plans to rearchitect something next version they won't provide an interface that developers need in this version if doing so will make that rearchitecture difficult. Some would say this is good product engineering to which I would actually agree, but it is nonetheless a trade-off that keeps developers from getting what they need today.

Experiencing Pain Empowers Real Solutions

So, if you'll reread my post from yesterday you'll see that I didn't say "Microsoft doesn't listen to customers"; I know damn well they do. On the contrary, I said that Microsoft's Developer Division "Don't solve real world problems." And the reason you don't is because you don't experience the pain that those real world problems cause. By comparison most developers contributing to open-source projects are doing so to solve pains which they themselves have, and that is why they are addressing developer needs much faster than Microsoft's Developer Division.

Yes it is a Paradox...

An observant person would say that I've present a rather intractible dichotomy for Microsoft's Developer Division; i.e. they need to use the developer tools they build to solve real world problems yet they also need to to develop those tools ten times faster! Now I'm sure these comment will cause the blood of those in Microsoft's Developer Division to boil thinking I believe it's possible they do their work ten times faster and do real world projects. But I was not advocating that; I'm fully aware of the myth of the "man-month" in software development projects.

...But Solve it You Must, Or Else

What I was pointing out, however, is if Microsoft's Developer Division maintains its status quo they will slip farther behind and the loss of developers to other platforms will accelerate. And since developers, developers, developers have always been Microsoft's life blood it is critical they address this issue. Every developer they loose to Linux or the Mac doubly weakens Windows. Microsoft must address this issue if they are to maintain the same level of relevancy during the next twenty years that they've had for the past twenty years.

And most of what I'm suggesting isn't complex, and it isn't new. They probably have most of what they need already written and used internally. They just need to rethink what they are offering.

Change, or Be Changed

So to wrap up this second long-winded essay:

Microsoft's Developer Division needs to implement drastic changes sooner than later. If they do not, outside forces will soon impose drastic changes upon them and it's certain they will find those imposed changes to be far more painful. Or as the mechanic on the old Fram Oil Filter commercial used to say "Pay me now, or pay me later."

What if I'm Not Wrong?

P.S. If you're from Microsoft's Developer Division and choose to dismiss my concerns, just ask yourself this: What's the downside for you if I'm right?

1. Eric Lippert's post was in response to my post entitled A Modest Proposal: VBScript.NET, aka "Helping Mort use .NET".

I've been planning to blog about this for some time but just haven't gotten to it. Well here goes...

---

Contents

• Is Microsoft's Approach Failing?
• After Ten Years; Too Little, Too Late?
• Providing Solutions Frequently Just Not a Priority
• Core "Real World" Problems Not Addressed
• Values "Sugar"-Free Over Productivity
• Focuses on Details, NOT the Big Picture
• Revolutionary Paths Are Often Dead-Ends
• ASP.NET: Wrong Medium, Wrong Model
• ASP.NET: Exceptional Engineering, Answers Wrong Questions
• Open-Source: Answering the Right Questions, Rapidly
• Is there any hope for Microsoft's Developer Division?
• Comments

Note: The day after I posted this I decided to add headings to make the argument easier to follow.

---

Is Microsoft's Approach Failing?

I believe Microsoft legacy processes simply cannot react fast enough to the innovation happening in the open source arena on the language and web framework front. Microsoft's developer division typically offers three-year version cycles where they first architect Visual Studio and related technologies in a vacuum. In recent years they've even thrown out alphas and betas to the Microsoft faithful to get feedback which, and thankfully they've used a lot of that feedback. But that approach just isn't working in the market anymore. When the release cycles of scripting languages frameworks like Ruby On Rails and Django and CMS platforms such as Drupal are sometimes as little as a few months, it's really hard to wait around for the next version of Visual Studio.

After Ten Years; Too Little, Too Late?

It would be different if Microsoft's developer technologies provided at least 95 percentile of what's needed by work-a-day developers on a daily basis, but they don't. Case in point is we still don't have the ability to do complete URL Rewriting for ASP.NET on IIS even though Apache has had mod_rewrite for years. Looking back, how many years of massively duplicated developer effort in the field did it take befor Microsoft finally provided a login module and a method of managing site-wide templates?!? (i.e. "MasterPages") Oh, about a decade from when they first released Active Server Pages.

Providing Solutions Frequently Just Not a Priority

It's not just that Microsoft's developer division takes too long to offer new solutions to recurring needs; it is that they place such low priority on providing those solutions. Three year development cycles testify to that fact, especially when you consider it takes Microsoft many releases to address fundamental needs. The guys on the product management teams at Microsoft are really smart people, but they often can't see how much trouble they cause people in the field by their decisions. They see the world of creating Visual Studio, but they don't see the world of using Visual Studio to develop software.

Core "Real World" Problems Not Addressed

What's more, Microsoft architects its developer products in a vacuum; they don't use them to solve "real world" problems. Sure, they may use them internally for developing productsbut when does the average developer's project look like product development at Microsoft? They often create excellent software but software that either doesn't solve real world problems or does so in a totally over-engineered manner. While running Xtras I watched many a developer launch a 3rd party component business because they had identified a need while working on a real world project. However, once they saw small success as a vendor they started developing, designing, and even envisioning new products in a vacuum. And often those products either didn't address real world needs or did so in a really unnatural manner.

Microsoft is a much worse example of this. Their saving grace thus far has been market share and financial resources to brute force their products into the market, and many of the faithful won't even look at other s offerings to understand why some of Microsoft's offerings so miss the mark. I know, until recently I was one of them.

Values "Sugar"-Free Over Productivity

And Microsoft's product managers often dismiss feature requests that would make development a LOT easier as simply being "syntactic sugar. For example, one such dismissed feature request I made years ago was for simplified property references in VB.NET. I wanted a syntax that would allow a developer to implement a single-line syntax for specifying properties you didn't need anything special, something like:

1. Property Foo Into _Foo

Instead of nine lines of:

1. Private _Foo
2. Property Foo 
3.    Get
4.       Return _Foo
5.    End Get
6.    Set(ByVal value)
7.       _Foo= value
8.    End Set
9. End Property

That would have reduced the number of lines of VB.NET code by probably half an order of magnitude. But they just weren't interested in it because it "bloated the language and otherwise had no value" (I am paraphrasing from memory.)

Focuses on Details, NOT the Big Picture

Even more, I advocated an advanced scripting language that would be a lot like today's "in-vogue" scripting languages. I called my proposal VBScript.NET. But then my suggestions were dismissed for esoteric reasons and I was told that Top Minds Are Working On It! (Well, evidently not, or so many developers wouldn't be moving to PHP, Ruby, and Python.) Microsoft's culture is to argue semantics when reality doesn't match their world view, and they are blissfully willing to ignore the pain that continues to exist.

Revolutionary Paths Are Often Dead-Ends

What's more, probably because of its financial resources and a hubris that comes from being the industry leader, Microsoft has a bad habit of creating huge revolutionary jumps instead of small evolutionary steps. Rather than always creating lots of little independent layers of loosely coupled components, each with it's own independent functionality, documentation, and rationale for existence, Microsoft often builds monolithically complex solutions where the individual components are highly coupled, not documented, hidden beneath the covers, and frankly with functionality that has not been fleshed out well had it had to be developed to stand on its own. This creates bloated and fragile systems that are often extremely hard to debug and for which there is no passionate community of supporters surrounding it.

ASP.NET: Wrong Medium, Wrong Model

ASP.NET is a perfect example of many of these problems. Rather than study the web and realize it was a violently different platform than desktop apps, Microsoft chose to shoehorn an event model onto the web and use a page-oriented implementation. Not only did they get the medium wrong, they also got the model wrong. And this decision resulted in an outrageously complex pipeline processing model with tons of code that is hard to debug or even understand, and that requires lots of high end developers to figure it out and repeatedly explain to newbies what they need to do just be able to do some of the simplest things, things that are brain-dead easy in PHP for example. But hundreds of thousands of Microsoft-centric developers just trudged along and accepted it as the next best thing because Microsoft said so. And for a short time, I was one of those true believers.

ASP.NET: Exceptional Engineering, Answers Wrong Questions

Now, however, even many Microsoft developers are starting to see ASP.NET for what it really is: An exceptionally engineering product that answers the Wrong Questions. Former ASP.NET developers are moving to the platforms I mentioned earlier (Ruby on Rails, Django, and Drupal) simply because those platforms offered developers the syntactic sugar they crave, and because the developers of those platforms focused on solving pain because the pain they were solving was their own.

Open-Source: Answering the Right Questions, Rapidly

Open-Source development by nature results in lots of little independent layers, and there are communities that sprouted or are sprouting to support each of those independent layers. Each of those layers has had an opportunity to be fleshed out, and by comparison it shows. How can something like Open-Source PHP on Apache take on mighty Microsoft's ASP.NET and IIS, and win? Because they answer the right questions, and they did so in far less than a decade.

Is there any hope for Microsoft's Developer Division?

Which brings me back to the original question:

Can Microsoft's Developer Division Compete Moving Forward?

Frankly, though I really like the .NET Framework and hope I'm wrong, I'm completely skeptical.

In my opinion, there two (2) approaches to software development methodologies and resultant architectures[1].

In the beginning: Monolithic Complexity

I call the first approach: "Monolithic Complexity" which I characterize by the following:

1. Grand Visions,
2. Marketing defines Software Architecture,
3. Significant Development Budgets,
4. Attempt to Eliminate Constraints,
5. Requirement to Accommodate Infinite Future Scope,
6. Feature Sets based on Target Customer, Price Points, and Release Schedule,
7. Divergent and Expanding Functionality,
8. Related Teams Worked on Most Components,
9. Minimum Utilization of External Components,
10. Software Comprised of Complex and Highly-Coupled Components,
11. Most Components Built to Specifically Support Application,
12. Data and Configuration Stored in Highly Optimized Binary Format,
13. Brute Force Development Processes,
14. Constantly Extended Release Dates,
15. Installation, Operation, and Extension Requires Exactness, and
16. Planned Upgrade Cycle.

Microsoft is a master of Monolithic Complexity. One only need to see, use, develop for, and study the history of Windows, Visual Studio, SQL Server, and Exchange to understand just how much Microsoft fits this category. However, most modern software companies emulate this same approach regardless if they do or do not execute as well as Microsoft has.

Then came: Lots of Little Layers

Moving on, I call the second approach: "Lots of Little Layers." I characterize this software development methodology and resultant architecture by the following:

1. Modest Visions,
2. Developer defines Software Architecture,
3. Little or No Development Budgets,
4. Nothing but Constraints,
5. Moderate Consideration of Future Scope,
6. Feature Sets planned based on Developer's Needs,
7. Cohesive and Focused Functionality,
8. Unrelated Teams Worked on Many Components,
9. Maximum Utilization of External Components,
10. Software Comprised of Simple and Minimally-Coupled Components,
11. Most Components Useable in Other Contexts,
12. Data and Configuration Stored in Poorly Optimized Text Format,
13. Minimization of Development Effort,
14. Frequently Released on Schedule,
15. Installation, Operation, and Extension Accommodates Sloppiness, and,
16. Upgrade Cycle an Artifact of Reality.

Anyone involved in software development in the past half decade will immediately recognize the latter: open-source development. Yes these include Linux, Apache, MySQL, and PHP as well as Ruby on Rails. But open source also includes software that Microsoft-centric developers probably know well including NUnit, NAnt, CruiseControl.NET, SharpDevelop, and dasBlog.

All in Life is Gray

Of course nothing in life is really black and white, and that applies here. Some open-source development follows the second approach less than others and it is inversely proportional to the extent with which the open-source project is shepherded by a corporate entity versus a passionate group of individuals.

A Uniter not a Divider

Now I'm not arguing against corporate entities in this short essay as I ran one for the previous twelve years and plan to again in the near future. Instead I am merely indicating differences and then drawing attention to the benefits of a specific aspect of the latter.

Paper covers Rock

I am writing this not to discredit commercial software companies but because I want you to see how by its very nature open-source development results in lots of little layers of software. But more importantly, I want you to understand that this approach has significant benefits. Just as scissors cut paper and rock breaks scissors, paper covers rock[2].

And finally, I want to encourage commercial software companies, especially Microsoft, to emulate this approach.

And in the future, as I have time, I plan to drill down to different aspects of the "Lots of Little Layers" approach to identify why the approach is so valuable complete with examples and counter examples. In the mean time I look forward to your comments and questions on this

---

One of the more interesting conversations I had during my tenure while President and CEO at Xtras, Inc. was in October 1997 when Network+Interop came to Atlanta for it's annual visit. One of the Microsoft Windows NT Server Product Managers Luis Bonifaz decided stopped by my office for a visit and gave me an education of how Microsoft positions its competitors; I'll never forget it.

Anyway, for those of you who remember those early formibable days when Windows NT Server first became a serious operating system, around v4.0, it was a fun time. In those days, the major systems players were feeling (rightfully) threatened and so they came out with continuous anti-NT campaigns with the simple message of:

Windows NT Server Can't Scale!

 Many vendors jumped on the "Let's bash NT" bandwagon, but probably the loudest two were Scott McNeely of Sun Microsystems and Larry Ellison of Oracle Corporation. Being a Microsoft kool-aid drinker at the time (Xtras was running a reseller focused on Microsoft systems and developer tools after all) I was of course ready to do rhetorical battle with ol' Scott and Larry. But what Luis told me was truly educational and amazing; talk about an on-the-job MBA in marketing!

Luiz told me that, unlike most companies that focus on attempting to position their company in their prospect's eyes, Microsoft was excellent at positioning their competitors, and further that Microsoft trained all their marketing people to think this way. Luis then went on to say that the anti-NT crowd had been trying to taint NT with the "can't scale" brush for quite some time as he started drawing a triangle on my whiteboard to illustrate. He said that the Microsoft strategy was "We'll accept that. We'll accept that we can't scale up to operate the largest systems on the planet. Okay, but we'll counter with the fact that you can't scale down and we can, and that market is much, much larger!" Using his triangle he showed the marketshare they attempted to guard (in yellow), and the marketshare they didn't even attempt to take from Microsoft (in blue.)

 "Then we'll just continue working it," Luis said. "We'll continue improving the operating system and we'll continue riding Moore's Law. Eventually we'll add the features that are needed to scale, by those who demand the bigger systems, and eventually the hardware we run on will be able to match all but the most demanding applications in the world. And then we will be able to scale; from the bottom all the way to (almost) the top. And the absolute top won't really matter. At that point, what do you think will become of the "NT Can't Scale" crowd? Like Zack Mayo (Richard Gere) in "An Officer and a Gentleman" they will have "nowhere else to go."

Fascinating. Anyway, it was fascinating to me back in 1997.  And here we are almost ten year's later; have Luis' projections proven accurate?  I'd say he was pretty close to correct. 

P.S. What is all the more ironic about this story is how Microsoft doth protest too much these days about open-source software and Web 2.0 companies when they make pronouncements about not being able to scale and/or they are not being good enough for prime time. If history is any indication, Microsoft had better watch their back or people may soon be saying: The King is dead. Long live the King. :-)

I just learned that Microsoft has decided to make the Visual Studio Express tools free forever. This to me shows Microsoft's acknowledgment that people are not willing to invest their time learning a product that they will eventually have to pay more for then they have funds available or earmarked, especially young people. I greatly applaud this move, and I wish more software vendors would do this with their products (and I'm thinking of component and tools vendors for .NET developers.)

But how can companies make money giving away their software? I believe software has a lot more value to someone once they've learned it and can concretely understand it's value after which they would be more then happy to spend their money to upgrade to more advanced features.However, to those software vendors who think they can release a free but essentially crippled product, don't.  No one will waste their time learning to use a crippled product. 

We are in a new era, one where software is not so much viewed because it offers value to a user but instead viewed by whether it is worth someone's time to learn. This because of the plethora of software (and information) available and because most people won't realize there is value is software until after they have learned it.  A software vendor's job today needs to be to convince someone that their product is worth that person's time to learn.

It's nice to be correct. Or at least to suggest something to Microsoft that they end up doing.  :) 

A few months back I suggested Microsoft give away Virtual Server, and today they are announcing just that!

Good deal.  Let the virtualization wars beg