Express "Orcas" Principles


Building on my Principles for First-Use Tools, I’m thinking about Principles for Express. Express is a tougher job because its customer base spans so many people — from professionals coding after hours to students to people who aren’t developers using it to learn or to accomplish some task at work to people who just want to have fun.


In thinking about this customer base and what makes Express attractive to them, I’m narrowing down on some principles that I’d like to apply to the decisions about which of the VS Standard-and-above features we consider for putting into Express. Here are two:



  • Keep concept count as low as possible. I’ve written before about concept count, but keeping the number of things a person has to contend with in order to accomplish a task low is a major differentiator between Express and the higher-level products.

  • Focus on attracting new developers. This means that we’d focus on things that would make the product, for example, attractive to first-time developers or to other people who don’t currently program.

There are others I’ve looked at: limiting download size, price, etc. But in the end those seemd to be more like tactics to achieving these two items.


The challenge, however, is making these concrete. LINQ designers: in or out? Would LINQ lower concept count? Yes, if we were able to simplify our overall data access strategy. Would it attract new developers? Yes, if it weren’t positioned as a data access system for brainiacs. So LINQ becomes less interesting as a specific, and having a coherent data access strategy becomes more interesting. And harder.

Comments (15)

  1. You have an interesting dilemma with Express and it’ll be real interesting to see how you solve it.

    On the one hand, if you want to appeal to hobbyists, there’s a really strong case to be made for working well with the tools that hobbyists are using today – particularly open source stuff. Particularly NUnit and the various open source version control systems – because even if you’re a hobbyist, programming without version control is practically suicidal.

    On the other hand if you want to keep the market for your very expensive "professional" and "enterprise" versions of VS, you have a strong motivation to keep Express nicely crippled in those areas because they’re precisely the most important features provided by Team System (and I know that my company, for one, would skip Team System entirely if good, well integrated unit testing and version control tools were part of the standard product. Sourcesafe fails on the "good" part 😉 )

    In other words, to appeal to the hobbyists it’s critical to make sure Express is extensible and easy for open source developers and other ISVs to integrate tools into it. But to avoid undermining your own market it’s just as critical to make sure it’s not extensible at all.

    Good luck reconciling that one!

  2. johnmont says:

    A harder thing is that the bulk of hobbyists don’t know what Nunit is and don’t want any part of anything more complicated than a function. The features you’re talking about might all benefit the "after-hours professional developer," but the bulk of hobbyists aren’t at that technical level yet.

  3. AlfredTh says:

    The thing with Linq is that it has the potential to make data access much easier than other more recent models. Data access has gone from being very easy back in the day of simple direct access files and single key ISAM files to very complex with the latest SQL server files. Hobby programmers do not need all the power of SQL but they do want simple ways to read, write and manipulate data.

  4. I guess we’re using different definitions of hobbyist. Not that that’s a problem of course 🙂

    Since I’m coming from the perspective of an open source developer, I see a lot of contributions by people that I’d class as "hobbyists" – a lot of students and, yes, after-hours professional developers like myself – and some of their knowledge and insights put me to shame. But I guess this is a different class of people than the ones you’re talking about right now.

    At the very least, I’d say that learning about version control right up front would be doing even the most beginningest of beginners a huge service. If you want to permit that without adding too much conceptual overhead, how about just making every save operation do a checkin? Nothing extra to learn, but when they accidentally blow away all their work, the option to go back to a previous version can be there for them.

    How to allow them to gradually grow from a simplified model like that to the more explicit checkout/commit approach they’ll need for more serious development might be a little trickier though.

  5. mheller says:

    Hobbyists don’t know about NUnit? Do you have survey numbers for that, John?

    Maybe it’s time to change that, assuming it’s true.

  6. orcmid says:

    I like the way you’re looking at this, John.  

    I think there are lots of clashes around Visual C++ Express Edition (which lacks a beginner book), and I think this conversation might be a little easier for the C# crowd.

    For Visual C++ EE, the problem seems to be the fact that it can be used for standard C and C++ using conventional textbooks (with some hints), making the ordinary use in computers science courses useful.  

    Then there is the question of making native Win32 Windows applications and using the Platform SDK, and the problems of being prepared for that.  

    For beginners, the C++/CLI is really confusing as one more hosting case that has more pitfalls than benefits in the current setup.  (I far prefer the clean-ness of VC# EE if the goal is to get going in WinForms quickly, especially since there is more handy beginner material.)

    Despite this confusing situation, and the level of competence and experience one needs to navigate it, there is apparently a strong interest in the VC++ EE and I would expect to see it used in class rooms as well as by hobbyists.

    I think it is appropriate to provide avenues toward development of engineered code, kept as lightweight as possible.  I’m not sure how that folds in, but there need to be ways to branch into those areas, and also to do a good deployment and support job.  

    I see no reason to rule out cottage industry (open-source, shareware, freeware, and commercial ware), especially in countries and regions where software development is new and where future computer scientists may arise.

  7. johnmont says:

    I was just talking with a coworker about how VS has a very complicated paradigm for what every other application thinks of as "Ctrl-S" and we both agreed that we needed to fix that. I think you’ll see one of the two of us do something.

  8. johnmont says:

    Well, the percentage of professional developers who use nUnit at all is slim (we have data on that) — low single digits percentages of all pro devs, I believe. In the hobbyist space (remember: think "non-professional" not "after-hours professional" for the purpose of this thread) most developers are using Access or Foxpro or something like that, so things like Nunit don’t make sense.

  9. johnmont says:

    This person is a really interesting customer — all the skills and knowledge of a pro, all the passion of someone doing this for fun. To date, a lot of our work in the hobbyist space has focused on thinking about this customer. There’s a lot more we can do for him/her, of course. One thing is to make it so they can make money off their creations — maybe through ads or sales on the Tuscany marketplace. Another is to start to introduce more of the VS STandard/Pro features into Express — except that increasing concept count in order to make these customers happier will increase confusion with the "non-pro" hobbyist.

    We need a way to crisply explain "hobbyist" in its different forms — taking into account skill level, I suppose, which seems to be a serious differentiator between the two extremes I’m talking about in this thread.

  10. Xepol says:

    Leave Linq out?  Are you insane?  Linq reduces concept counts by dramatically simplifying data access from multiple sources into a single unified structure.  

    Personally, once Linq hits the ground, it is going to be one of my number one support requirements.

    True, it may not be able to be perfectly optimized every time, but as a general solution, it should be pretty zippy.  If I need every cycle, I am gonna go write something non standard, impossible to maintain and incomprehensible even to myself five minutes after I am done.

    The ability to type something ‘select filename, creation date from C: where filename like "*.zip"  ‘ dramatically simplifies things.  Suddenly looking for files is like looking for rows, or matches in a string.

    Why would you EVER want to not include a feature that can unify data access, filtering, sorting, updating???  Seriously count all the different ways you sift through data.  Lists?  Different from databases, different from directories, different from strings, different from folders on an FTP site.  Reduce concept counts?  

    Seriously, Linq is one of the more awesome new features I have seen proposed since I first learned object oriented coding.  

    Sql is a common skill even amoung the hobbiests.  Expecting someone to learn some SQL syntax is more reasonable than expecting them to learn lists, queues, linked lists, btrees, filtering, a dozen different sorting methods PLUS sql if they ever want to access a database.

    You would not have to do much research to see that SQL has become a common skill even for hobbiests.

    So, uh, in conclusion, [eh-hem] no, don’t leave linq out.  Sliced bread doesn’t compet[whoooa… before I get started again]

  11. I’m going to come back to my claim that the most important thing for the "pro" hobbyist is extensibility. We’re more than capable of finding third party tools to provide the additional capabilities we need, but if you lock those tools out from integrating nicely with the IDE, then our user experience will be miserable. Which I guess was kind of the point I was trying to make in my first post 🙂

  12. johnmont says:

    LINQ is very cool. There are some things that may get in the way (<cough>tripping over our own feet<cough>), but I think we’re basically in agreement that LINQ should be in Express.

  13. johnmont says:

    I hear you about extensibility in Express and for the pro hobbyist. There are a bunch of interesting challenges with it, not the least of which is a business issue: how would Microsoft keep Express from suddenly becoming just a free version of Pro if you could put anything into it? On the flip side of that, we’ve always said that tools drive the platform and that’s why we build them, not because we make money. On the other flip side, we do happen to make money on tools and decreasing that revenue stream means we could invest fewer resources in building tools.

    There are also some product issues, like how we’d handle potential issues around creating unintentionally complex or fragile Express products (with lots of plugins). Other teams with plugin models have found that the plugins, while great for the advanced user, have caused issues with people less comfortable with technology, particularly when the plugins are not well-behaved (e.g. memory leaks).

  14. mheller says:

    >the percentage of professional developers who use nUnit at all is slim (we have data on that)

    I think I feel a column coming on…