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?
Cheers
Simon