Should we care about the Clients Environment?

Dennis made an interesting comment on a previous thread about how as developers we should be making use of multiple virtual machine technology to mimic our clients’ environments so we can better support them.

Its a good point… but I completely disagree.

Some developers should do that for sure, what Microsoft calls ‘professional’ developers perhaps. I prefer to think of Excel/VBA developers as business developers, we are a bit closer to the business and a bit further away from the bits and bytes of hardcore coding.

We express our business knowledge in Excel and VBA for a variety of reasons. One vital one for me though is ease of deployment and hence support.

If I write a decent spreadsheet in Excel 2000, I can reasonably expect it to work perfectly in Excel 2000, 2002, and 2003. I can expect it to work at least partially in 2007. That is irrespective of the wider target environment, user rights, security credentials, previous installed components, corporate build oddities etc etc. There is no dll hell in Excel*.

If the client has Excel they can run my application. full stop, end of.

(Of course there is a little excitement about macro security, the way they messed up expired signatures, the fact no one uses them because they are such a blatant scam etc)

*(ok so we sometimes get cannot find project or library, but if we keep things close to Excel/VBA and develop with care, and with some consideration for the clients environment that doesn’t happen much, and can usually be easily fixed.)

This trivial deployment leaves us business developers free to invest our time in understanding the business better and improving our software development skills. Deployment skills? system admin/security skills? heard of them, don’t want them or need them.

This is one of the biggest reasons I have not focused on .net – its a deployment nightmare. Of course that’s solvable, just invest a bunch of time and effort learning sys admin stuff and security stuff, and a bit of virtual machine trickery and jobs a good’un. But I don’t want to do that, I want to improve my business knowledge and my coding skillz. Luckily Microsoft cater for folks like me with Excel VBA.

Don’t get me wrong .net works well for corporate developers (once they have the required sys admin knowledge) but for independent devs like me, there is way too much pain to trawl through to distribute and support custom built .net components.

So I care a little bit about my clients environment, but not much. And frankly I think the fact that developers have to spend time and effort creating such close replicas of a clients environment is a hugh fail for Windows software development and for Microsoft. ‘Write once deploy everywhere’ – in yer dreams!

Major service packs? fair enough.  When you need to remotely replicate their level of hotfixes across a broad swathe of operating system components and applications the process is seriously broken IMO.

When I did asp development I had to get intimate with IIS to be able to work out when things went wrong whether it was our code or the server environment. If my Excel apps goes wrong, it’s my code, no investigation required (roughly).

I don’t have anything against .net, there is much about it I like, I just don’t think its aimed at pragmatic delivery focused independent desktop developers (like me). (Hence for the observant, the pic is from .net 1.1 from 2003). I jump at any chances I get to develop in C#, the joy of a modern language and a modern IDE, but this tends to be when I am contracted on-site in the role of corporate dev, rather than independent software developer.

What about you? do you find distributing your .net apps a true joy, the real highlight of your dev cycle?

Are you juggling more than 10 virtual machines, and keeping the patching in step with clients?

Which do you prefer development or deployment?

Do you agree with the separate roles of corp dev and business dev?



9 Responses to “Should we care about the Clients Environment?”

  1. Mathias Says:

    I have to side with Dennis on this one. I use virtual machines all the times, regardless of whether this is an Excel, VBA, VSTO, or pure .NET project. Being a bit obsessive/compulsive, I have a hard time living with simply “reasonably expect it to work” – I have been burnt in the past with VBA code which behaved weirdly on different machines (of course, you could argue that I wasn’t coding it right), and VMs just remove all that uncertainty from the equation, and make support much easier. And… they are just so easy to use!
    On the other hand, I would agree with you that deployment is never the fun part of a project – and when things go wrong, they are really unpleasant to figure out. The ease of deployment of Office docs with VBA is nice from that perspective!
    But even then, I still prefer to work with .NET, unless the project’s scope is really tailor-made for straight Excel+VBA – the development experience is much more pleasant, as you noted, and .NET gives me also more freedom in what I can deliver to the client.

  2. Dennis Wallentin Says:


    Deployment is part of the process and deployment of .NET solutions for Excel gets simpler and simpler. Unlike many other vendors MSFT needs some trial versions of their tools before they get things right so to speak.

    Many solutions have short life cycles and therefore the forward compatibility is of less interest for many clients.

    Business developers? Excel developers utilitze VBA and all of the built-in tools which makes this group different to others. Other developers are also close to the business.

    Too many Excel developers have side-by-side installation of several Excel versions. This kind of configuration will make .NET development impossible.

    As long as the size of hard disk increase the number of configurations is irrelevant. Yes, with automation tools we can easily maintain many configurations by running services after the office hour.

    Kind regards,

  3. Michael Foord Says:

    I’ve found deployment of .NET apps pretty straightforward. Maybe I’m doing it wrong?

  4. Brian Small Says:

    Mr. Foord: I certainly hope so. I have bought your book and Resolver One with the hope of adding it to the product mix in my little computing shop on the prairies.

    Alberta, Canada

  5. Brian Small Says:

    That didn’t make much sense did it!

    Clarification: Mr. Foord: I certainly hope .NET apps are straightforward to deploy.

  6. Bob Phillips Says:

    Whilst I agree with Simon’s overall view, that of Excel/VBA being more business oriented that the typical house .Net developers, I do think that even we have to worry about deployment.

    It is no good just saying that if my app fails it is my code. What if it doesn’t fail for you. For instance, just this week I had a situation where one of my clients ran my app, and if he tried this one function with a workbook saved previously, no problem, if he tried it with a new workbook, it crashed. I tried it and it worked fine for me in both cases. I finally tracked it down to the fact that I had customised my basic workbook template, so a new workbook was based upon my modified Book.xlt. My guy had not, so he used the basic template, which for some reason that I still don’t get yet was not being trapped by my application events. How did I find it, I ran the app in a VM where I hadn’t dabbled, and it failed there.

    VMs (and the remoting facilities) are a lifeboat in these times of so much choice.

  7. Simon Says:


    .net COM add-ins are a lot harder than VBA, and that is my point.

    Of course once you are familiar with packaging and deployment wizard (or whatever its called these days – innosetup?), caspol, PIA’s etc etc, as I am sure you are Michael, then sure its not hard. For your average Excel VBA dev that’s a real hurdle. Especially for an external dev

  8. Simon Says:

    Ha ha, Brian, glad you fixed that up :-)
    Bob any of us with a custom set up risk that, I’ve been burnt too with my non standard settings.
    I generally try my stuff in a neutral VM before release, but that still doesn’t cover the clients customised settings.
    Rather than loads of VM shenanigans I’d rather have richer status/progress and error reporting.

    My point really is about needing to reference a very specific set of .net/com components meaning VMs are really the only way

  9. ross Says:

    Off Topic…
    Michael, .Net apps or managed com addins – there is a difference!
    VSTO is now much better to deploy, however – go into a business running XP, with less than 1000 people, over 3 sites and get a user from each to install your .Net addin – Bloody Murder :-)

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: