Knowledge and risk

I think many of us are aware of the risks of uncontrolled spreadsheets use in organisations. Possible errors, massive duplication, versionitis, uncontrolled access, possible data (and logic) diddling etc etc.

Some people might point the finger of blame at Spreadsheets or Excel or Microsoft, or the user, or the IS department, among others. A very common target though is the user.

‘They don’t know anything about software development, thats why they created a monster’ is something I’ve heard a few times. I’m sure that is the case sometimes.

One that I have come across a few times, that is mentioned less often is the ‘professional’ software developer who doesn’t know anything about spreadsheets. For example I’ve seen hand coded Find functions because the dev, capable though they were, was so unfamiliar with the Excel object model they did not know of Range.Find. Looping to 100’s inserting 1 row at a time because they don’t know how to insert 100’s at once. Spawning zombie Excel instances because they aren’t careful with their referencing. Not managing screenupdating, calculation and events, etc etc.

None of these are life and death situations for sure (well recursive event triggering will kill Excel), but Excel is a massive component, it contains 200 objects and 4,500 methods and properties. Many mainstream devs might usually work with components a tenth or twentieth of the size. They are probably so ignorant they don’t know how ignorant they are (unconscious incompetence). see here: especially the links in the comments.

So in one camp we have the Excel experts who know the product but might be missing some systems design skill, and in the other camp we have systems development experts who are lacking knowledge of the target application.

Lets call the first lot Excel/VBA devs, and the last lot Visual Studio devs. Which group are most likely to take up VSTO? (I’ll give you a clue – one set will get it for free, out of the box with the next release of their usual development tools.) (Although in fairness this group have stayed away in droves so far).

It looks to me a bit like we are jumping out of the frying pan into the fire. We are about to swap

  • strong business knowledge,
  • strong product knowledge (Excel)
  • and maybe weak systems knowledge


  • probably weak business knowledge
  • almost certainly weak product knowledge (Excel)
  • good systems knowledge

That really doesn’t sound that much better to me.

The answer, it seems to me, must be VSTA – get all that .net goodness to the people who understand the business and are familiar with the product. Or make VSTO part of a developer edition of Office? I don’t know about the details but I’m convinced that its the current Excel/VBA devs that offer the best chance of helping an organisation maximise its return on its MS Office investment.

What do you think?

Do you agree on the 2 main groups? are there other relevant ones?

Do you think Excel/VBA devs are chomping at the bit to get their hands on VSTO, and will be able to access dev tools? (I remember one place where we all had VBA, but definitely no VB6 – ‘its too powerful for non-professional devs!’. I never found out what they thought VBA was missing that made it so safe.)




10 Responses to “Knowledge and risk”

  1. Dennis Wallentin Says:


    I share Your thoughts and opinion to 101 %.

    The average Excel/VBA developers will find the deployment process to be very complicated for VSTO/.NET. Another aspect is the security aspect that becomes more and more important which also may look complicated and complex. This group tend to have a strong knowledge and focus on the business needs.

    The corporate developers find the Excel objects model to be strange as they cannot apply the OOP approach. Except for that they are rarely familiar with the object model. This group works usually far away from the end users and tend to develop on written requirements (not necessarily created by the end users).

    For me the gap between these two groups is natural. The question is what the price is for each of these groups when moving in the direction to the other group of developers.

    BTW, if You lurk around XVBT and MSDN’s VSTO forum You will notice the above very clear.

    Kind regards,

  2. Biggus Dickus Says:

    I have been around VSTO since it was called Office.Net at its earliest conceptual design before any bytes even existed. Despite consistently saying “Deployment, Deloyment Deployment” they kept inviting me back to Redmond for another try at getting my blessing.

    At the last meeting (after at least 5 total council meetings going back to 2001) I finally asked them if they could give me a copy of VSTO because I didn’t have one —– Oops !! I had failed to see any reason to consider VSTO for my solutions and I still don’t – strictly because of Deployment.

    If VSTA can come up with a “baked-in” code story where the code follows the file that would maybe get my interest. But I am still concerned that the user would likely only have a “run-time” version on their desktop (although that is strictly speculation on my part as I have never heard one way or the other on this from MS – and wouldn’t tell you even if I had anyway – but i haven’t ;-) ).

    In the end once again I believe that the future of automation of Excel models (which is all we’re really talking about) will come from the Excel/VBA side of the river. Frankly I think most if not all VS developers simply wish Excel would “F.O.&D.” (you figure it out). Trying to sell VSTO to them is a collosal waste of time.

    On the other hand I think VSTO has little or no appeal for old-line Excel/VBA types. So it is doomed – sorry..

    I believe that if MS INSISTS on a Managed Code story for Excel it will have to be using a product that evolves naturally from VBA and that will be championed by Excel/VBA developers. Maybe VSTA will be that product ??

    And they better do it SOON or there will not be enough of us left to use as a base (if it isn’t already too late).

    sorry for the pessimism …..

  3. Simon Says:

    I hung around on one VSTO forum for a while. here is why I don’t go often now:
    1. most non Excel stuff is just noise, I personally only really care about Excel. if there was an excel.programming.vsto NG I would subscribe. The fact there isn’t demonstrates how far off target the VSTO push is currently.
    2. Current versions seem undeployable
    3. never seen any commercial demand
    4. the challenges look painful and low fun (admin/security rather than solving business issues)
    5. Currently other technologies look more interesting to me.

    Dick- Excel FO+D – yep that about sums it up! SOON – yep, although I suspect it may be too little too late. VSTO 2008 back in 2003 might have swung it. Or VSTA in Excel 2007.
    I have another VSTO strategy type post coming up

  4. Marcus Says:

    Hi Simon,

    “…We are about to swap…”

    I don’t know about that. Everyone has different experiences and my has been more and more the business trying to retain control of their tactical development. I’m also finding business managers more technically savvy. I’d suspect the business will be extremely resistant to any technology which will push control over to the IT dept’s side of the fence. I’m not passing a value judgement as to whether this is or isn’t a good thing – it’s just an observation.

    I’d also agree with the sentiment that MSO Devs with strong domain knowledge “offer the best chance of helping an organisation maximise its return on its MS Office investment”.

    I’ve also seen orgs which prohibited VB6 as it wasn’t a supported environment, but then failed to provide a suitable alternative. The same goes for Access. Many places I’ve worked Access is ‘officially’ banned. The only offered alternative was SQL Server which the IT dept would develop, deploy and maintain. Hence the business now has (sometimes) hundreds of clandestine Access databases squirreled away. One Access project I completed we called Vespa – when the business manager went to the IT dept they tried to sell her a Mack truck when all she wanted was a small, productivity tool for two staff.

    Cheers – Marcus

  5. Dennis Wallentin Says:


    Have faith ;)

    When VS 2008 is released then an independed forum – “VSTO for Excel only” – will see the daylight for the very first time.

    More info will come later on.

    Kind regards,

  6. Simon Says:

    Dennis – nice one!

    I would really like the VSTO team to register that devs tend to target only 1 office app though. That fact seems to have passed them, and the COM add-in folks by. Unless I’m the one out of touch?

    btw why does the shared add-in project default to every possible office client (and dev env) selected?

  7. Dennis Wallentin Says:

    For all developments where we target Excel from the .NET we can only target one version at the time. In orther words, MSFT can/wants only to provide us with version specific PIA.

    In addition, we can only use one version specific PIA when developing. I believe You fully understand situations where .NET based solution should target 2000 – 2007…

    That’s why I’m a strong supporter of Add-in Express since they can provide us with version neutral PIAs to the price $349 for their toolkit.

    If a third-party can provide us why cannot MSFT do it as well? Is it impossible for a great number of reasons or do they want us all to move to Excel 2007?

    Kind regards,

  8. Simon Says:

    “or do they want us all to move to Excel 2007?”
    hmm, can I have time to think about that one?

    Dennis if I end up doing any serious .net add-in stuff, I will definitely get hold of Add-in Express, based mainly on your recommendation.

  9. Richard Says:

    Totally agree. I have always thought a was the best way for microsoft to build confidence in .Net and gain acceptance. I would experiment if it was a free part of Excel.

  10. Harlan Grove Says:

    From what you write about professional software developers (PSDs), looks like they’d have been better off with a simpler grid component since they’d use Excel no differently than a grid component anyway.

    There are two aspects of Excel (spreadsheets generally, really) that make it worthwhile – more flexibility in terms of handling user input and the calculation engine. If these PSDs don’t know how to use Excel’s OM’s grid manipulation methods, what chance is there they have a clue how to use Excel’s calc engine?

    In basic terms, spreadsheet formulas represent a functional programming language (with lots of referential integrity issues). Functional programming is much different than procedural or OO programming. PSDs with no experience with functional programming aren’t going to understand how to use Excel well/efficiently.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: