In a previous post, I threw out a little quip about VBA going away. Based on some of the comments, I should clarify that remark.
First, I have no special or inside knowledge. Microsoft has said publicly that VBA will stay in Office for the foreseeable future and I believe that is true.
A few nits to pick: I doubt they really look past the next version, however, so the foreseeable future is really just a few years. Also, “staying in Office”, to quote myself, can mean a lot of things. XLM macros are still in Excel, but would you consider that macro language alive or dead?
Let me be more specific about my prediction. Remember this is pure speculation. I predict by version 15 (two versions from 2007) that changes to the UI will not be updated in the object model that Excel exposes to VBA. When they add embedded YouTube videos in Excel cells, you won’t be able to modify them programmatically. Further, I predict that VSTO, or whatever that evolves into, will be the “official” method for automating Office applications. The code will be separate from the Office document and will be “managed” (in quotes because I’m not 100% sure what that means). All of your VBA code will still run. It will still live in your documents and you will still be able to add, modify, and delete VBA code just as you do now. The adding of code will be limited to legacy features (remember no updates to the OM), but that will cover about 99% of what’s in Excel and 99.9% of what you want to use (with one notable exception). The last pain in your ass will be that spreadsheets will be, by default, unable to run “unmanaged” code. Your users will have to go into the Virtual Security Kiosk to enable running VBA code. Did I mention that this was speculation.
So that doesn’t mean that VBA is dead-dead, just dying. I will still write VBA code for myself and others. I will still encourage anyone to learn VBA if their goal is to automate Office applications. There’s really nothing wrong with learning VBA. Learning any language will be useful. I learned BASIC then Pascal in my formative years. I remember exactly nothing about Pascal but it probably helped me in some way and it certainly didn’t hinder any future learning. However, if a 13-year-old kid says he wants to be a coder, there’s probably a better path than one that goes through VBA.
Don’t stop writing macros or reading Excel blogs because I said VBA is dead.
What evidence do I have for these predictions? None, it’s all speculation. Haven’t you been paying attention? Well, there are a few things, I guess. First, there’s no VBA in the Mac version of Office. I’m not sure if that happened in the last version or will happen in the next version, but it’s official. Maybe MS is simply getting out of the Apple business and it’s no real reflection on VBA. Or maybe VBA isn’t an asset with a future so the cost of porting it to Apple’s new OS isn’t worth the cost.
Microsoft is a tool of governments. Governments threaten to use open source products and Microsoft comes out with XML. Why on earth would anyone store a spreadsheet as a text file? The only reason is that because some influential customer says that they need an open format. The people who make those decisions aren’t the people who use VBA.
Microsoft is a tool of big business. IT managers hate Excel and Access. They want all of the programming needs of the company to flow through the IT department. They don’t want accountants writing VBA code that could delete a bunch of files. On the other hand, accountants don’t want to wait three months to get a bug fixed in their invoicing program. Is MS pandering to the IT manager or the accountant?
There’s this minor little change to the UI in Excel 2007 called the Ribbon. Maybe you’ve heard of it. There’s no Ribbon object in the Excel or Office object models. Oh sure, there’s plenty of great reasons why the Ribbon isn’t there. But it’s not. And next time it will be something else. Then something else. Then the OM is static.
I called MS a tool twice and a panderer once. Those are meant to be a little derogatory because I’m neither a government or a big business. But, honestly, who can blame them for trying to meet the needs of their largest customers? I don’t. It’s exactly what I would be doing if I were in their shoes. And I’m not overly concerned about the VSTO future of Office automation. I separate my code and data now, so it’s not that big of a change for me. If they put VBA syntax in the CLR (DLR?), it would be a non-issue for me.
Finally, I should address those that say “Microsoft isn’t stupid. They won’t alienate such a large customer base by relegating VBA to the attic.” Won’t they?
VBA is part of Office 2004, the currently shipping version of Office for Macintosh computers. It has been omitted from Office 2008, which is supposed to ship in January 2008. The official reason for omitting VBA was lack of resources coupled with a need to support the new features (user interface and file format) introduced in Office 2007.
VBA in Macintosh versions of Excel has been a second class citizen since Office 98. Features that we take for granted on the Windows side (hovering over a variable to see its value during code execution and nicely integrated access to help screens) were never added to Macintosh versions.
I’m a heavy user of user defined functions in my day job. I like using it because all my colleagues already have a working copy, so they can dive into the code any time they feel the need. There is no need to beg IT for a new application or bug fix (and engineering never got very much support anywhere I have worked). If you want something done, just roll up your sleeves and make it happen. And I loved being able to develop code at home (on a Mac) and use it at work (on a PC).
If I worked for a firm that had standardized on Macintosh computers, I would recommend either sticking with Office 2004 or else running Office 2007 on a virtual machine, something the latest Macs do with virtually no loss in performance. You’ll notice that neither recommendation brings any revenue in to Microsoft’s Macintosh Business Unit.
Long term, the only thing that will save Office on the Macintosh (for the corporate market) would be an equivalent blunder on the Windows side, such as dropping VBA. Given the subject of this thread, there are grounds to hope that Microsoft will shoot both its left and right feet.
In the 80’s I moved from Lotus 1-2-3 to Excel and in the early 90’s from XML to VBA. For the two last years or so I have slowly moved to .NET and VSTO.
As long as I can support business needs by providing Excel solutions I’m not concerned of which tool or tools I need to use to achieve it.
The aspect that worries me is the tradeoff between learning new (and more complex) tools and to continue to understand the business needs (with or without any written requirement).
Kind regards,
Dennis
I’m with Dennis. I can learn what I need to support the business needs. The secret to our field of employment is to know what technologies are available and what each one does. As long as I can get the think-time necessary for a project, I can move to .Net without too much pain.
But I think VBA will be around very long time. Ask the FoxPro developers how much pain they’re feeling (none, because Microsoft is still supportng Fox Pro).
Oh and Microsoft’s move to XML has less to do with making the Open Source loonies happy, and more to do with making a full fidelity Office suite for the web. That is, open XML is a step toward a web-based Office suite of tools.
Dick
I think you give a good overview and I agree with pretty much all of it. I think they will need to target VSTO like tools at Office devs somehow rather than Visual Studio devs to get decent take up.
To all those who say ‘MS won’t alienate a large customer base…’: what do you think they are doing now WITH VBA? As Dick says, IS hates Excel and Access and VBA, MS is already alienating most CIO’s by providing powerful programming tools in a fairly uncontrolled way. Control and lock down is coming, probably slowly. Each release sees more powerful office admin policies to allow IS departments to better manage access to Office features.
Like you all say, a sensible design and openness to new tools and approaches and really the future of VBA shouldn’t have that big an impact.
cheers
Simon
The King is dead long live the king.
I enjoyed your rant Dick. And in return I have fashioned this mini-rant, First of all we will be using Google Spreadsheets by then (2015). Seccondly the change over will be gradual, so you and I will not really notice how it is that we no longer need to use it. Thirdly VBA is too easy to use, and therefore either Excel will be dead or we will still use it. So “When will Excel Die?” that is the important question here.
People will not trust Google Spreadsheets (the contender) until it can securely run files that are stored on your local machine / network ONLY, until then we have nothing to worry about. When it does happen the spreadsheet world will change very quickly and we will all seemlessly drop this tool that we have dedicated to and pick up some easy to use Web based interface which will read old files and do most of what VBA does but easier and more probably slightly restricted to the important parts of work, instead of the complex and inconsistent MS Excel 12 Object structure, and it will be free. The King is dead long live the king.
Have a nice w/e
Follow up question: Guys like Dennis and Mike can easily migrate with whatever tools are available. But what about Dick Kusleika from 10 years ago? That guy who just learned what VBA was and wrote his first macro? If getting started in Office automation means VSTO and managed code, are we reducing the number of new office developers? Is that good or bad?
Good question,
My guess. There will be less to need to customise, as accountancy moves to more robust platforms after another couple of Enron’s. The forms and data stuff will find a new product to be written in which is more “managed”.
Spreadsheeting will retrench into the place it came from (your big calculator stuff) and the Business Performance Management style tools will be all the rage by 2015. Developers will be 2 a penny and you will outsource your coding to Shanghi or Dehli, assuming we are not out there working with them to compete for a job. Who knows, maybe the next big VBA style tool will not use English as its main language could you imagine? Theres something to really keep you and I awake at night. Maybe its time to buy that phrase book.
Ni Hao “Kusriaka”.
“If getting started in Office automation means VSTO and managed code, are we reducing the number of new office developers? Is that good or bad?”
Ahhh. That’s a good question. I think the paradigm of what an “Office Developer” is will slowly shift. Those small interdepartmental groups that have their own Excel or Access expert building skunk-works will have to train and find programmers with a broader set of skills. But like others have said this shift will be very slow. That guy who represents Dick Kusleika 10 years ago will be 65 years old by then.
I’ve got a friend who says that amateur programmers are like amateur gynecologists. They’re everywhere, they’re always ready to offer their services, and they’re rarely ever gentle.
I agree with Dick. The power of VBA was what it put in ordinary users (and especially power users) hands.
Like VB, VBA is being marginalised because MS no longer believes in providing tools for actual users, but is listening to IS instead, which wants everything centralised.
As a power user myself, I know that business actually needs VBA as much as ever, but IS has never acknowledged that because it is remote from users.
Actually, the timing is perfect. When Microsoft retires VBA, I will follow. Maybe VBA and I can take up golf in our old age.
Mike
Nice quote, I know a guy who said the best cabinets will always be made by the amateurs because they do it for the love of the craft, not to turn a profit.
Dick, will there be less devs targeting office? yes I think so. Good or bad? Bad for MS, bad for Office, bad for business folks, bad for business productivity and competitiveness, good for other spreadsheets/grid controls, good for ‘professional’ devs, good for IS depts. Bad for security too, in the long run.
All guesses and specultation of course.
>>But what about Dick Kusleika from 10 years ago?
The same question was raised when MSFT officially replaced XML with VBA. Some guys disappeared, some managed to ‘survive’ for some years and other ported them to the VBA platform. The same scenario will exist when MSFT will make the next switch.
The major huge difference between then and now is Internet/Web which provides some great support when (or if) individuals will make the transition from VBA to VSTO.
The main difference between the group of inhouse unofficially developers and external developers is that the later get only paid by providing Excel solutions while the former for manage the business in one or another way. So per se the focus will be on different aspects between these two groups.
If I remember it right You’re using Excel 2000 in Your daily work. That means a time lag of about 8 years between the present version in use and the latest available. So I guess that You’ll be using 2007 or 2009 10 years ahead :)
Keep in mind that Visual Studio 6.0 are still in use as a development platform and third-party vendors still maintain/develop their ActiveX controls. We still target Excel by automating it with tools like classic VB / C++ etc. So why would we stop developing solutions with VBA? Because MSFT says so or?
In the next version of VSTO, that is version 3.0 which is part of Visual Studio.NET 2008, we get a closer integration between VBA and VSTO. MSFT has probably mistaken the average speed to adopt VSTO among Office developers (except for the group of Outlook developers) so this may be one approach to improve the attraction of VSTO (+ VSTO integrated with VS.NET 2008 Professional and higher version.)
In my opinion, VSTO will not in the short run be the ‘VBA-killer app’ as some may fear it is.
From what I can see and understand we will develop solutions for Excel/Spreadsheets on the following platforms:
-VBA / classic VB/C++
-Visual Studio.NET (C#, VB.NET and VSTO)
-SharePoint Server (Excel Services)
-Web
Goggle has recently launched Google Gears (http://gears.google.com/) which indicates how we may develop solutions for Spreadsheets on the Web platform in the future.
(Another interesting development tool is D (www.digitalmars.com/d/).)
I believe it’s important that it exist different tools to create Excel solutions with and that spreadsheeting will exist on several platforms and not only on the desktop platform.
Kind regards,
Dennis
I reviewed the petition list; which I signed long ago and was surprised to see some 12,900 ± signed. Is that a lot? Of the millions of users [sh/w]ouldn’t there be more?
My 2 cents (and overpriced at that)… XL is great for 2 things.
1 – Covering off that 5% of the business that the system you are using was never designed to do. I don’t care what software you have it does not do everything. If it did you would still be waiting for it and it would be so badly overpriced that you could never afford it.
2 – Ad Hoc Analysis. Digging into a specific issue and determining what is going on.
Why IT/IS hates XL. They don’t care about #2. These are one time things that they have not the time nor patience for. Additionally they rerely if ever require VBA to do.
What they care about is #1. Where XL is woven into the day to day running of the business. Here is where VBA generally comes into play. Designing mini applications. I personally am in favour of these mini apps where they are done well (rarely the case). So we have a very powerful tool (VBA) in the hands of untrained/undisciplined accountants who are now filling the voids themselves. Is the solution to remove the tool. Necessity being what it is, removing VBA will not remove the need. Better training is the key along with IT/IS support. XL is a very cost effective way to fill these gaps and if done correctly it does not compromise system integrity. In short. Add more tools. Add more functionallity. Work on getting IT/IS types to recognize what the tool is all about and lets get on with the work…
I don’t agree or disagree with any of the above, as contradictory as it may be. I want to say something that is probably more inflammatory than all, which is that I think VBA has been a resounding failure. Hear me out.
VBA is easy to use. Not all of us, but a lot of us, would never have gotten involved in this “programming” if it were not for the simplicity of it all. I learned all I needed to know from the macro recorder. The 200 page MS Press book helped a little, and the JWalk books helped a lot, but were not necessary. I think the bulk of the time savings and cost savings that are to be realized from using VBA on a day-to-day basis come not from the dictator apps or the developed programs and add-ins, but from the quick-and-dirty programs that are whipped together to fit one purpose for one person to use day in and day out or week in and week out or month in and month out. At that, I think VBA has failed. I just don’t see it being used by the casual Excel user, and that is a damn shame. Most users are scared of the word macro what with the warning dialogs and all that comes with them. I have seen so many users doing so many rote tasks over and over again that could be done in 1% of the time if they invested the time to learn VBA. But who has? Not even power users, just developers. VBA was made for the power user, but the power user has basically overlooked it. It is just depressing. I feel for the users who think they know Excel, yet spend so much time doing the same things over and over again without any idea that it is just so easy to let a simple macro do it for them. Even as the macro recorder has matured and become more robust, it has not seemed to make a difference. If VBA dies, it is only because it has failed at what it was meant to do, which is to automate the routine for the average user.
I cringe at the thought of VBA going away. I am far from ready to replace it in my everyday work even though I am pretty well experienced enough in the .net languages that I could transition. I cringe not for myself but for the users who can’t make that transition. MS needs a replacement that is easier, not harder to use than VBA. Anyone who cares enough to be a real Excel developer won’t be affected as much as they think. It’s those who are just dabbling and those who have yet to dabble but just need a little push who are going to get lost. If anything, it would be a boon to professional developers if VBA dies because it would make them all the more useful as the hobbyist guys fall away. The business side guy of me thinks it is great, more work and more money. But the software side guy of me cannot live with that. Progress in software development should mean the bringing of more powerful tools to the average user. VSTO is ass-backwards in that regard, and I see no signs of anything better from Redmond. To be fair, I see nothing from the OO.org guys either, just a weak VBA clone. Spreadsheet development today, IMHO, is far less promising than it was 10 years ago.
So why is no-one considering VSTA as a possible next-generation VBA?
It -might- have benefits of both worlds:
As with .NET: managed code and a modern programming environment (with lots more functionality built-in)
Like VBA: fully integrated into Office and the code goes with the file.
As to the OO guys: OO does have Basic and IS programmable. But the IDE looks like a relic from the dark ages without intellisense and without object help. Starting programming in OO is like doing magic tricks: throwing knifes while being blindfolded. Note that this is my experience with OO from 2 years ago. It mat have improved over time…
>>…code goes with the file.
From a design point of view, most developer seems to agree to keep data separated from the code. This is also strongly supported on the .NET platform which VSTA is also a part of.
From a security point of view, data should also be separated from code. This is also strongly supported on the .NET platform (strong names, CAS and digital signing of code) and Windows Vista is shipped with new fancy stuff like UAC.
InfoPath 2007 is shipped with VSTA but I have no experience of it.
But from what I can understand VSTA gives other software vendors an option to implement an integrated .NET development platform (C# & VB.NET) in their softwares.
Perhaps you’re right that MSFT will ship any future Office with VSTA but then probably without the ‘all in’-file option.
Kind regards,
Dennis
Good point. Dick maybe we should have an infopath & Excel article. I looked at this a while ago and there looks like a whole load of potential in this office package.
JK –
As far as I’ve seen, VSTA is vaproware, at least in terms of Office.
The benefit of VBA being incorporated in workbooks is that it’s easy to deploy a solution. It’s not too hard to deploy a multiple workbook solution, where you have one or more workbooks filling each of the tiers of a “conventional” software architecture.
JK/Jon,(et al)
From what i have seen and been told by MS, VSTA solutions will not be deployed as code behind (which from a .Net POV make sense) but as a separate assembly, this in itself is not a problem, and i dont think that if MS pulled there figuers out deploment would be much more of a pain than it is to day – it might even be better (SCS). What is a issue is this:
VSTA is “sold” with excel – VSTO needs VS “pro”, big issue for many VBA users,
Secrity models/level – VSTA has inbulit level of access, which could lead to big issues
Com v’s .net – mainly perfomace issues esp for UDFs.
and from a higher perspective, the whole issue of running Excels n thousand lines of “unmanaged” code agianest “managed” .Net – which just feel odd to me.
On the upside VSTA will have a macro recored, and i think a move to true OOP should be quite nice in an Excel based interface (still highly supporting standard modules etc.), not to mention a lovely new IDE!!!!!
Ross,
Good point about VSTO & VS Pro. So what You’re saying is that VSTA uses a ‘library’ of assemblies (which seems to be the case with InfoPath). Interesting as it open up for some possible scenarios where we can use some general assemblies in different solutions.
Given that we can apply some CAS-models á la VSTO the built-in access feature in VSTA may not be a security issue.
Kind regards,
Dennis
For the idiots in the audience – me – would any of you care to summarize this VSTA/VSTO/InfoPath/.Net discussion, or point to such an explanation on the web? Feel free to dumb it down for somebody who understands VBA/VB programming fairly well, but not much else. My head is starting to spin!
One other note. I see a lot of discussion here or IT departments v. Accounting, for example. Not much mention of the small business, maybe one to five people that doesn’t have any departments. I don’t know how many of them use VBA – but I’m sure less of them will use something more complicated!
From my perspective I would like to see a more robust set of tools that I can use, with can and not have to being the operative word. If they remove VBA or severly limit what it can do I will be very disappointed. It is great in that with very little effort or knowledge you can dip your toe into the world of programming. It does not require a fundamental understanding of OOP or a tiered architecture to get going, just the desire to find a better way.
By adding other languages and such it opens XL up to the professional developer. When developers recognize that XL can be a robust platfrom on which to build very powerful and cost effective apps we will all be better off. The more XL can be used in conjunction with managed code the better off we will be.
But if the objective is to move away from the simplicity of recorded VBA then I think we are heading down the wrong path. It removes the small business users and amateurs from the picture which in my opinion would be a real shame. There are lots of tools for the professional developer. Adding one more to their arsenal will not hurt so long as it is not at the expense of the casual user.
Funny thing, that mind set of “it’s going away”. Case in point… my son is doing a science fair project where he wanted to (read wanted me to) control Christmas lights synchronized to music. No problem, I said, as I blew the dust off my old DOS based 386 laptop. Here, let’s hook up an LED (with current limiting resistor!) to the parallel port… see son how we can use DEBUG to send a word to the port to get whatever bit we want to turn on? His objection (and a good point) was that he wanted to synchronize to music, and my old junker didn’t have modern applications. When I asked him what modern application he had in mind, he said that he wanted to use Excel, because he could use eight columns of cells to represent each bit in the word sent to the port. This way he had a running visual representation of the patterns over time (each row would be the next change in the pattern, and an additional column contained the number of milliseconds to wait until execution. Okay I’m sold, I said… you can use my Pentium 4 laptop… but I’ll kill you if you damage my printer port. Here, let’s hook it up just like on the junker. Wait a minute! How come DEBUG looks like it’s outputting to the port, but the voltage isn’t changing? Hmm… after a little time on the search engine I find that Microsoft decided that after Win98 they would have none of that, and programs in User Mode can’t access routines now reserved for Kernel Mode. Dejected, my son thanked me for trying. Funny thing, that mind set of “it’s going away”. Seems that after some more research, some other programmer had already done what I was getting set to do…. Write a device driver to take my User Mode request, wrap it in a Kernel Mode request and execute. Let’s see now… take their DLL and drop it in my system directory, have an Excel VBA function call to the DLL, and presto! Instant access to the “non-supported” function. VBA going away? Bah! So long as programmers want to use something, it will get used.
Interesting discussion going on here.
I like a few others here have fallen into VBA as the first language I have played with and like others I am fairly well self taught and I know that despite playing with VBA I still have a hell of a lot to learn. So the talk about these other options is interesting to me from a question of portability. As like others I have no idea about the other programs.
The reason I like VBA is that it’s embedded in Excel and it provides me the ability to perform complex analysis in the background with user friendly forms up front to provide a communication device to explain complex natural resource economic issues to the unconverted. As just about every computer has Excel on it (occasionally yes I have a problems between Mac and PC which highlights my lack of knowledge), so the ability to put your file on a memory stick and run it in front of a new audience on their machine gives you a huge advantage over someone with a file that needs to either be loaded onto the machine with an installation program or that they have to use their own laptop to display the file.
Until I find a programming language where its just simple a case of plug and play your file I’m fairly sure that like most people there is no incentive to make the transition. I’m sure that whatever the future coding language is within the Excel framework that we will adapt.
Doug
Here was my attempt to clarify/explain:
http://smurfonspreadsheets.wordpress.com/2007/01/10/vsto-vsta-vista-vs2005/
Infopath 2007 has a VSTA code editor rather than (as well as??) the VBA IDE.
In terms of VBA replacements (and I quote):
‘Deployment deployment deployment’
Any VBA replacement must have at least as good a deployment story. Whether good = secure or good = easy I think is a big debate point at the mo.
Where do people think the best value (for users) would be:
A simplified VBA type thing with macro recording or
A developer focused thing (packaged with Office), no recorder, but better OO, better .net integration etc?
Jim Thomlinson has it right. IT/IS dislikes Excel and Access because they allow undisciplined users to create semiautomated systems on which non-IT/IS departments come to rely. Reliance isn’t the problem, it’s the implementation idiosyncrasies that are rife in such systems. IOW, when the person who wrote and had maintained XYZ leaves the company, who maintains XYZ? IT/IS is often asked to do so, which puts them in a lose-lose position: say yes, get a huge workload to bring XYZ up to IT/IS specs or risk SOX compliance headaches; say no, and piss off outside department heads who begin to believe IT/IS does nothing for them.
But that’s the problem. If ANY & EVERY automated system needs to meet IT/IS department standards, then EVERYONE creating or maintaining such systems SHOULD be using something like VSTO *AND* have their code, forms, and code-to-spreadsheet interfaces reviewed by IT/IS before deployment. That WILL prevent users who lack either the time or the inclination to learn and/or apply professional development practices from developing systems going forward.
OTOH, if you want to continue to allow confirmed amateurs to do some decidedly nonprofessional development, then you have to accept that it won’t be easy to hand it off to others to maintain.
So, will VSTO be able programmatically and dynamically to change all aspects of Excel’s UI as well as run all OM methods and read and set all OM properties?
[…] Maybe. Listen to the grapevine. […]
This article is suggesting that VBA will always be a part of office
http://blogs.msdn.com/excel/archive/2008/01/16/clarification-on-vba-support.aspx
Sounds pretty good to me :-)
Where does it say “always”? Always is a very long time.