Will Microsoft Meet Occupational Programmer’s Needs?

Contents


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:

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

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. :)

 

Microsoft’s Obsolete Process and Release Cycle

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.

Clarifying my Microsoft Developer Division Rant

Contents


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".

 

Can Microsoft’s Developer Division Compete Moving Forward?

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


Contents

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.

 

Kudos to Microsoft: Visual Studio Express Tools Free Forever!

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.

Delphi for Sale! Wonder who will Buy?

I just read the news today that Borland is going to sell it’s IDE Tools Business that includes Delphi, C++ Builder, C# Builder, JBuilder, Kylix and InterBase. Not more than 100 days on the job Tod Nielsen I shaking this up at Borland, just like I expected!  As I’m a big advocate for "burning bridges" so-to-speak (see the eWeek article for the reference) I think this is exactly what Borland needs.  Further, this is a possibility it will really be good for Delphi and other Borland tools faithful.

But the news leaves an interesting question: Who will buy, and what will be the fallout?  The question interesteds me enough I decided to document me thoughts on the matter below:

  • Oracle: Uncle Larry’s been on a buying spree lately; maybe he’ll pick up these Borland cast-offs too?  Though Oracle has development tools they don’t have quite the devoted following that Borland’s tools have.  Buying them would give Oracle some world class IDE tools and languages for programming Oracle. Of course InterBase users (are there any?) would certainly take it on the chin.
  • Microsoft: Adding the Pascal language to Visual Studio by including Delphi would seem a natural to me, but everything else overlaps. Microsoft could of course provide an upgrade path for C++ Builder, C# Builder, JBuilder, and maybe even InterBase users, but Kylix users would be left out in the cold. Heck, they might even make a bid to keep anyone else from getting Kylix!
  • Red Hat:  Red Hat might be interested in tying up this product line, especially if they open source it, but since a lot of Borland’s line runs on Windows, its seems a longshot.
  • SAP: This lumbering giant is seeing threats all around, from Oracle to SalesForce.com and they might use this toolset to give them some real programmability as compared to ABAP. Who knows which of the tools they’d use and which they’d kill. But then again, this one’s a longshot and it wouldn’t be great for the faithful.
  • Sybase: Sybase could pick up the Borland IDEs for the same reason as Oracle, and they might not even kill InterBase, they’d probably just rename it "Sybase <something>."  Of course, Sybase really is a second tier player and I don’t think purchasing these Borland assets would be great the faithful nor really do that much for Sybase’s databases.
  • IBM: Given the broad reach, IBM might just buy the userbase and roll them into WebSphere somehow.  IBM has always been able to consume practically anything. Maybe they will do this too?
  • Sun: There’s a chance Scott will buy to pick up JBuilder and Kylix, and keep the rest out of other’s hands, but I doubt that’s likely.
  • Novell: This one is interesting.  With Borland’s IDEs Novell could go toe to toe with Microsoft Visual Studio but instead optimize for Mono.  (I’ve always thought Novell should have purchased Borland years ago; maybe it will happen now.)  This is one of the best scenarios I can see for all involved, but the fact that most of the tools heavily support Windows make me think it is not as likely I it would be interesting.
  • SalesForce.com: Who’s got the most to gain? Me thinks is would be SalesForce.com.  With his AppExchange strategy, Marc Benioff could grab the Borland toolset and optimize for programming SalesForce’s APIs. Marc could also use Interbase as an engine for local caching of SalesForce.com data. If Marc buys, it could be really good for the Borland IDE tools faithful. But Marc will only maximize benefit from such as purchase if he opens access to the API to ALL SalesForce.com customers, not just Enterprise Edition and up.
  • Google: This one’s a wildcard; they certainly could afford it!  With all their web services and APIs Google is offering, it would make great sense for them to offer a great set of developer tools to the mix; they’ve already shown a willingness to provide downloadable software with Google Pack.  I can see it now; all of Borland’s products would be freely available for download from http://devtools.google.com; talk about marketshare!  Microsoft, be afraid, be very afraid. This is probably the best option I can think of for the Borland IDE tools faithful and will further upset the balance of power between the Big M and the Big G.
  • Amazon: Similar to Google, Amazon has lots of APIs it wants to offer; why not provide developer tools optimized for calling their APIs?
  • eBay: Same rationale as Amazon.

Whew!  That’s all I can think of right now, but it’s alot, no?  I’d say the best three potentials would be Novell, SalesForce.com, and Google. I didn’t mean this to be an exhaustive list so if you have ideas for potential suitors I did not mention or if you think differently about one of the potential suitors then please by all means post your thoughts as a comment below.

An Excellent Strategy: VMware Server

As many of you know, VMware has released VMware Server for FREE!  I think it is an excellent strategy for VMware. VMware Workstation is already a favorite of most leading edge developers, and this move has a good chance of cementing VMware Server into developer’s psyche as well!  Many of my loyal blog readers know that, even though I founded and run1 a .NET component and tools reseller at Xtras.Net, I am a huge proponent of infrastructure and middleware software needing to be open source or at least free. 

I commend VMware for embracing the competitive challenge of Microsoft and open-source moving into their backyard and offering the GSX Server for free. This will almost certainly help VMware establish their virtual images as the defacto standard for VMs as Adobe did their PDFs for digitized documents.  With VMware Server becoming free, software vendors will now be able to deliver complete server-based solutions as virtual images that will require almost not configuration to bring online. Hosting companies can start offering Virtual Machine hosting where you upload your VMs (but this will ideally need some excellent differencing software to cut down on huge upload times.)  Installation vendors can start adding VM deployment to their feature list.  And I’m sure there are hundreds of other things this will enable that I haven’t even concieved of!

Of course this will put huge competitve pressure on Microsoft with it’s Virtual Server, and has a chance of rendering the open source Xen project still-borne.  I’m not sure how I would suggest Xen counter this move, but if I were Microsoft I would be releasing so fast as to make the industry pundits head’s spin a Windows 2003 Server Option Pack for free that included Microsoft Virtual Server.  I’d even go so far as to release a free Windows XP Option Pack that included Virtual PC too.  Minimally they need to roll it into the next major version of Windows Server. Given VMware’s stronger market position in this type of software, the fact they VMware offered theirs for free first, and the fact EMC is no startup and can hold it’s own with Microsoft, I doubt Microsoft would run afoul of anti-trust regulations for offering their Virtual Server/Virtual PC duo for free.  If Microsoft does do this it will create a three-way competition for freely deployable VM server software and the likely competition should benefit everyone.

Now if VMware would just create some rational pricing options for VMware ESX Server instead of charging a minimum suggested retail price of $3750 for a 2CPU system!!!  I’m thinking they will do much better if they allow their pricing to scale down as low as $199 for a version that supports 1CPU and 2Gb RAM. As is, a company will have to be able to gain some serious benefit from VM before they can even consider upgrading to ESX Server.  But with the former GSX Server going free, maybe it’s in the cards.

P.S. It would also be great to see them create a lesser expensive VMware Workstation to encourage more people to try it out too.

1 UPDATE: As of May 18th, 2006, I am no longer run Xtras.Net nor did I retain any association with Xtras.Net.
 

Object-Relational Mapping Tool Guide for .NET Published

Just wanted to make a note here that we’ve published our How-To-Select Guide on Object-Relational Mapping Tools for .NET. Check it out!

How-To-Select a PDF Component for .NET

Yesterday I introduced the How-To-Select Guides on my blog.  Today I want to present our first published Guide entitled How-To-Select a PDF Component for .NET. You can download it by clicking on the cover below:

How-To-Select a PDF Component for .NET Cover Art

We’ve actually had our Guide covering PDF Components for .NET online for several months, but since I only just blogged about the Guides yesterday, I thought I’d announce our PDF Guide here today.  And if you are so inclined, please post any feedback you might have.

 

Introducing How-To-Select Guides

How-To-Select Guides Logo

Though I’ve been working on the How-To-Select Guides for many months now, I’ve never gotten around to blogging about them.  Well, it’s about time.

For years my company1 Xtras, Inc. via Xtras.Net (and previously VBxtras), the leading reseller of components and tools for C#, VB.NET and VB6, has helped .NET and VB6 developers find and buy components and tools. Unfortunately we’ve never done a great job of helping developers select the one best for their needs; the products were just too complicated and we couldn’t afford to staff the telephones with developers (besides, what developer wants to spend all day taking phone calls?) 

What I’ve envisioned since almost the day I founded Xtras in 1994 (then VBxtras) was providing indepth and unbiased information about products that developers could use to quickly learn which products best met their needs. The problem was, how to make it happen.  Well, earlier this year Mike Gunderloy and I discussed the concept, and he agreed to help me get them off the ground by writing the first one and managing the process of writing and/or editiing twelve more.

So now I am spending >90% or more of my time on growing a new company that publishes the How-To-Select Guides named Guides, Inc. My vision is to publish Guides for practically every category of component and/or tool available to .NET developers, and to have these Guides be:

  • Clear & Concise - Quick to read and easy to comprehend.
  • Accurate & Unbiased - Completely Defensible among leading experts with as little bias as humanly possible.
  • Exhaustive, Thorough, & Complete - Covering all options include commercial, shareware, freeware, open source, and even coding techniques; all decision points and aspects of potential concern; and including all currently available products in the category.

If we can achieve those goals, we will benefit everyone with the exception of those whose marketing is far better than their products. And our Guides should greatly cut the time required to learn about and research products. I’m very passionate about the Guides because I think they can do a tremendous amount of good, and because of that I decided that the Guide’s content should be freely available for download to all .NET developers who want to read them.

Take a look at our Guides for .NET Components and Tools, and let me know what you think.

1UPDATE: As of May 18th 2006 I am no longer involved with Xtras.Net.