Riding 2 horses

I think I have finally worked out my current frustration. Trying to do serious Excel development and serious .net development is not really possible and getting harder. Like trying to ride 2 horses that are going in different directions.

I think this is a classic case of what Joel calls the MSDN camp v Raymond Chen camp. (VS being the MSDN, Excel being RC)

Excel is still COM based and native code based for xlls. And even if the next version were totally .netted up (or if 2k7 SP2 added proper .net stuff) it would still be 5+ years before that would make a viable business. And those are big ifs.

Visual Studio 2008 looks pretty good, and adoption seems to be going incredibly well. As to market penetration of .net framework 3.5 (NOT part of Vista (Vista has framework 3.0)) that could be some time coming.

VSTO (Visual Studio Tools for Office) is clearly the bridge between VS and Office. And the 2008 version looks good, however I have serious doubts about the market for this technology. And if it doesn’t gain the traction, what is going to happen to those few projects that do get deployed? I think its too early to call yet, but by the end of 2008 things should be clearer.

A big part of the VSTO problem is that all versions before 2008 (still in beta mind you), were challenging to deploy. Although the scene has just been quiet, not rife with deployment hassles. This make me think few people have even assessed it, never mind deployed to production. VS2008 looks to solve the deployment pain, so it could set the market alight.

So which horse should I stick with?

For the next 12 months I’m going to stick with Excel/xlls and the Chen camp. I’ll just keep half an eye out for big VSTO adoption trends, and do a full review at the end of 2008 (might be an Excel 14 alpha/beta floating around by then??).

What about you?

cheers

simon

Advertisements

13 Responses to “Riding 2 horses”

  1. Marcus Says:

    Hi Simon,

    As you know, I’ve just started at an investment bank in London. It’s an initial 6 month contract, but the manager expects there to be almost two years worth of work.

    And the work? It’s all Excel / Access VBA. Potentially even some VB6 to wrap up common functionality in to a DLL library. The idea is to stream line and automate a number of discrete processes against the underlying data in Oracle, SQL Server and Access. There has been no mention of .Net integration. The business wants to be able to control and manage everything themselves – a very common theme.

    So if that’s two years worth and the solutions have a life span of half that (being conservative) that’s a minimum of three years. Your VBA dev skills are still not lost, as any migration projects will benefit from the skill in reverse engineering existing VBA solutions to be migrated (just finished one project like that).

    I’ve yet to see any (literally any – you know: none) demand for VSTO although there is plenty for .Net and (mostly) C# – but this is typically as a complement to VBA development, not a replacement. So from my perspective I’ll continue working on the .Net/C# skills (sans VSTO) and the rest of it is enhancing my domain knowledge.

    Cheers – Marcus

  2. Dennis Wallentin Says:

    Solving business needs with Excel (and previously with Lotus 1-2-3) has been doable for the last 20 years. It will still be doable so there is no losses in the short run to continue to develop solutions with it. C++/VB 6.0 are also still competitive and will be it for the coming years.

    VS 2008 looks very attractive (especially LINQ) and I will port myself to it when the RTM is out.

    I strongly believe that VSTO is the future but not for the coming 12 months. By then there will exist more skill and knowledge within the online community which will speed up things if You still is interested in VSTO.

    One issue which we face is the lack of having access to MOSS and other served based platforms.

    Excel services is interesting and will be implemented when more and more corporates move to MOSS. How can we learn and adapt Excel services?

    But I have to disagree with “Riding two horses” because I view it as just new tools to add to the growing toolbox for software development.

    Kind regards,
    Dennis

  3. MacroMan Says:

    You’re already amazing at VBA! For most VBA jobs and/or consulting projects, you don’t need to be an MVP to do a good job. I would concentrate on .Net for Office AND for building stand alones.

    Also concentrate on domain knowledge like finance. Financial services people have EVERYTHING on spreadsheets. I live in NY, hot bed for financial orgs, and I am very green at VBA, and yet I command a very good salary because my background is finance. You’ll do great over here if you have a math background and combine it with VBA/C#/C++. You’d be a “Quant”, someone who builds pricing models for financial products. Thier salaires are around 150k – 300k (plus a bonus). They sometimes move on to become traders and make even more.

  4. Biggus Dickus Says:

    Simon:

    Remember my theory – spreadsheets are forever. The key skill we have is in the use (and abuse ;-) ) of spreadsheets. How we automate them is secondary.

    But at the same time I always realize (like some of your recent threads have discussed) that clients do not think that “real men” do spreadsheet development. So we must be cost effective in ways that developers in other more “legit” languages and platforms find that the more they spend the happier the client seems (slight exaggeration there but some truth).

    So since I expect VBA to be on desktops for at least another ten years I am going to stick with that for now – it allows me to deliver cost-effective, reliable SPREADSHEETS ….. nothing more.

    Remember – you can’t do everything and you can only work for so many customers – so as long as Excel VBA has a footprint in a significant percentage of companies then there will be work for you – and that’s all we should care about frankly….. billable hours ;-)….

    Dick

  5. Nick Hebb Says:

    This is such a tough call because sticking with Excel as a means of income puts you at the mercy of Microsoft more so than other development careers.

    Will the desktop remain strong?
    Will the shift be toward Excel Web Services?
    Should you stick with C++ and XLL’s?

    In ten years, will you have the stamina to keep up with Microsoft’s juggernaut of new technologies? How long until spreadsheets bore you to death?

  6. gobansaor Says:

    Like Dick, I see spreadsheets themselves as the key technology; Excel’s key attribute is its position as the only end-user programming environment (other than CAD technology) in widespread use. As things stand the most cost effective way to automate Excel or to integrate it into other technologies is via VBA/VB6 and I don’t see that changing for at least another 7-10 years. In the meantime, C++ XLLs and C#/VB.NET DLLs via ExcelDNA should cover any gaps not covered by VBA/VB6.

    Tom

  7. Biggus Dickus Says:

    “How long until spreadsheets bore you to death?”

    That’s an interesting question to be sure.

    Actually to me spreadsheets keep my interest strictly because of their ability to reach out to data sources and then analyze that data – more and more data all the time.

    My interest in spreadsheets gets sustained because of my interest in business process and financial analysis. I am NOT a Computer Nerd, I am more of a Business Process Nerd – and I believe it is possible to consider that a career as much as any one single career one might choose. I love working with all kinds of different industries on all kinds af relatively small projects…. it’s the perfect job in many ways…(but not all of course).

    Getting bored with your career is a reality for everyone – that’s why after spending ten years as a commodities trader I decided to become a spreadsheet/database developer instead. I’d love to try something else after 20+ years but it’s too late now (and I guess I’m too old and too good at what I do ;-) ) to change careers and go back to being a neophyte (unless forced to to by circumstance of course).

    Dick

  8. Simon Says:

    Marcus – Business control – check, streamline processes – check, VBA migration – check, no VSTO (yet) – check.

    Dennis – I think we agree on the direction and the time scales, if not the horse bit.

    MacroMan – For sure some of the VBA I have delivered over the years has been amazing (amazingly embarrassing!)(amazed that it worked (or seemed to – thats the same thing right ;-)) . I agree on the domain knowledge – but I’m still not going to finish my accounting finals.

    Dick – real men – thats exactly the attitude I see (and sometimes that drives the rate the wrong way).

    Nick – yep, the single product/company dependency concerns me, yep too soon to call the direction (OpenOffice maybe?), yep keeping up is a killer. I wonder if that is why there are so few .net mIsvs – they are too busy keeping up with .net frameworks, and never have time to release a product??
    “How long until spreadsheets bore you to death?” – about -5 years ;-)

    Tom, yeah 7-10 years sounds realistic, unless there is a big change (security springs to mind).

    Dick yeah I love the variety, I think I’m more of a computer nerd than a business one. I love applying good IS to help business processes, but I don’t care if they are crap processes. I’ll point it out, but not lose sleep.

    cheers
    Simon

  9. Dennis Wallentin Says:

    Simon – I don’t mind to agree that we disagree ;)

    Kind regards,
    Dennis

  10. SPG Says:

    ok, here goes.
    I guess I should say something now.
    I think everyone is missing the point.
    XML.
    Hit it from the client, use VBA.
    Hit it from the server, use .Net
    Think about it.
    The important thing is this:
    In Office 2003 you can save most apps as .xml
    In Office 2007 the file format is actually .xml
    The actual application can be abstracted away.
    The important thing is the underlying data format.
    Is this not obvious to anyone at all?
    p.s System.XML, System.XML.Schema, System.XML.etc in VS2005 is no walk in the park, :), lol.

  11. Simon Says:

    Steve – see VSTO strategy for a response to your xml comment
    cheers
    Simon

  12. Marcus Says:

    Hi SPG,

    Umm, I’ve got to disagree (respectfully so of course).

    Rather than XML, my experience (even today) has been flat file, typically CSV.

    To my surprise, I offered to supply an IT dept XML files for a data feed from an Access system. I thought I was helping to encourage a standard. Nope – too much effort for them to work with: could we have a flat file please. (Side Note: ADO 2.1 and greater has a nifty feature to persist a recordset in XML. Niiice).

    Most (almost all) of the data feeds I deal with in a corporate environment is flat file. Even the ones which have an XML interface translate this to and from a flat file during import/export into that system.

    Kind regards – Marcus

  13. SPG Says:

    Marcus
    See the VSTO startegy blog topic for the continuation of this discussion.
    Stephen

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: