Where is the next Access?

Ted Neward recently posted a response to a talk by Biily Hollis, and asked “Where is this decade’s Access”. I think it is a great question, if only because I asked Scott Guthrie practically the same thing the other week.

Like many of the people Ted refers to, I started my professional career in FoxPro (I always find it amusing that productivity aspects of that tool, such as manipulating data as part of your 3GL, has only made it into the mainstream with LINQ To SQL, many years later). FoxPro had a passionate following, indeed I have heard it suggested that much of what we consider developer community today, was started by the FoxPro user base. For a whole class of scenarios, particularly a small workgroup of about a dozen users, FoxPro made it very quick to rapidly code and deploy applications. Even Visual Basic and Access, those other poster children of the ‘long tail’ (as Ted puts it) developer market, did not have the capabilities that came with FoxPro for many years. FoxPro was ideal for applications that were essentially CRUD based. FoxPro was one of the XBase family of programming languages, a basic derived dynamic language but with a heavy slant to data retrieval and manipulation. When I used it, there was no RDMS attached, but the flat file DBF data format.  In many cases that was ideal our customers could not support the RDBMS solutions available at the time, and utlizing a file server was the easiest way to a networked database. Fox was an ideal tool for the time, when PC applications targetted less than a dozen users working on a LAN. 

I have to agree with Ted’s assertion that today, professional development tools, targetted at RAD application of solutions for small businesses do not seem to engender the same passion and commitment that FoxPro once did. Nor do they seem to offer the same productivity. And that may be a gap, because there is probably still a market for applications that target a dozen people in a workgroup.

Now before anyone worries I’m not about to have some damscence conversion to point-and-click development. When I used it FoxPro was certainly not a point-and click too anyway. But there is still a place for a toolset that makes it easy to knock up CRUD based sites. In a previous post I talked about DDD’s idea of strategic design, dividing up into generic domain, supporting sub-domain, and core domain. RAD tools are often ideal in the supporting sub-domain development (by duct tape programmers).

A lot of the Ruby enthusiasts I meet seem to love Rails for exactly the same reason I loved FoxPro. The ability to knock out usable applications quickly and with little fuss, yet still produce something professional. Rails works ‘out-of-the-box’ to deliver CMS like systems to a wide range of customers. No one is suggesting the Rails crowd is dumbed-down, but their tools do embrace simplicity. 37 Signals embraced the principle of keep it stupid, simple, for Rails to enable folks to build just this kind of applicaiton easily with configuration and outright reject attempts to add complexity.

So when Ted talks about simplicity he is chanelling the spirit of the Rails crew with their focus on keeping it stupid and simple.

The closest thing we have today would seem to be ASP.NET MVC with jQuery and LINQ-To-SQL. That MVC should that level of simplicity may be no suprise because both it and Monorail take influence from Rails. Both pick up on the cleaner abstraction of MVC over the page controller approach that WebForms uses with its byzantine server side control model. I would agree with Jeffrey Palermo that the triumph of MVC is of simplicity over features. Still MVC lacks some of the convention-over-configuration that gives Rails its edge. LINQ-To-SQL wins by a simple ORM. In this field its shortcomings when compared to NHibernate are its strengths, it is simpler and therefore more approachable to a mass audience. Finally jQuery makes JavaScript programming approachable, without the kind of effort that made dynamic behaviour on web sites so expensive in the past.

The question is whether there is the commitment to take this combination forward or not from MS.







About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group. http://www.dnug.org.uk
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://jchrisa.net J Chris A

    CouchDB and CouchApp aims to be this product. We are taking a patient approach, to nailing the core technologies first, but in the long run, expect to see GUI application builder tools that allow you to snap together web-apps that can run locally on the desktop or mobile, as well as be hosted / synchronized with the cloud.

    More info on CouchApp here: http://couchapp.org/page/what-is-couchapp

  • http://runtingsproper.blogspot.com/ rtpHarry

    Hey, I just noticed that you switched “simple” and “stupid” around in the link: “37 Signals embraced the principle of keep it stupid, simple,”


  • http://opletayev.blogspot.com/ Mikhail Opletayev

    It is quite interesting that asking the ‘Where is the next Access?’ question you see a lot of mentions of Ruby, Rails, LINQ, DD, EF, etc.

    I think what people miss here is the fact that Access popularity came from it being an application first and a development tool second. I’ve seen plenty of Access applications built by people who had no to very little idea how to program.

    On the other hand, when people mention ‘replacements’ those are usually development tools, languages, frameworks. This is why none of these technologies are Access replacements. While they can accomplish what Access could accomplish and more, they require the user to be a programmer, sometimes a highly skilled one.

  • http://fizzbuzz.net John Farrell

    EF4’s designer tools and Dynamic Data get you 90% of the way there to the next Access. The problem is out of the box the website layout and navigation falls a little short and all these really easy to use tools are packed within huge IDE package.

  • http://petermorlion.blogspot.com Peter

    If you just want a CRUD website, what about Dynamic Data from Microsoft? I haven’t checked it out however, so I’m not sure if it is what you need/want.

  • http://hitesh.in Hitesh

    Brings back fond memories. It was dBase/FoxPro that really got me interested in programming. Although it has been a long time ago, it still has a soft corner in my heart.

    Although web is the next dev platform, I disagree anything targeted on web based deployment can ever approach the simplicity of FoxPro. Maybe something on Silverlight/ JavaFX, that can be deployed locally and then scale out to web will be more ideal.

  • http://ralfw.blogspot.com Ralf Westphal

    This is a very good question I´ve been asking myself for quite some years.

    However, the answer to is none of the current programming platforms whatsoever. It´s clearly not ASPMVCVBSQLyounameit.

    I guess, there are a couple of ingrediences that need to come together:

    1. language: The language to write programs in needs to be simple, but not too simple. And there must be a migration path from it to more powerful languages.

    Quick results need to be obtainable without any imperative language use. Just drag and drop graphical design.

    Then some declarative programming to go further.

    And then a simple imperative language. But maybe a graphical one like Scratch (http://scratch.mit.edu/). But this needs to be translatable to a major language like Java/C#/Python.

    2. data model: All current approaches suffer from a too complicated data model. What made dBase, FoxPro, Access so powerful was the table data model. The same goes for Excel. Single tables with maybe some lookup tables are easy to grasp for most people.

    This easiness needs to be retained for the Next Access – but it needs to be extended. Information networks are more complex today then they were 10-20 years ago. So people need to be able to start modelling them right from the start in a very easy way.

    The relational model won´t do for that. Neither would object orientation. That´s all too complicated with it´s schemas and explicitly to plan relationships. So RDBMS and ODBMS are out of the question as a foundation for the Next Access.

    What about schemaless databases like CouchDB or SimpleDB? Maybe. At least they are easy to grasp. But still… I guess they either make it hard to build relationships between data or the need to explicitly plan relationships is still to large. I´m not sure.

    So currently I´d opt for associative databases or something I call the “intuitive data model” (which is free of duplication and automatically builds all possible relationships between data).

    3. frontend: The frontend must not be limited to web or desktop. So I guess RIA is the way to go. Maybe Silverlight as presentation technology? But the code would need to be generated (see above 1. language).

    So I guess the Next Access is a combination of mostly declarative and/or graphical programming based on a schemaless data model running in the browser or on the desktop. And hopefully cross-platform 😉

    Who´s to tackle this challenge?


  • http://hackingon.net Liam McLennan

    The Asp.Net MVC active record stuff seems to be aimed at addressing the gap that you discuss.

  • Andrew

    I was thinking RoR too for a bit, but then realized that it’s still not nearly as accessable as Access was.

    Since it was visual, anyone could grab an Access for Dumbies book and within 20 minutes be knee deep in their own “Contacts Management” application. RoR just isn’t like that.

    I don’t know if we’ll ever see the an “Access” again.