skip to Main Content

The wonders of WordArt

REDMOND, WA – New programming language will revolutionize business application development     

OK, yeah, that’s not a real story.  I just made it up, sorry 🙂

But imagine how perceptions would change if it were true, and instead of being an Office app, Excel were to morph into a professional development tool.  Maybe we’d call it Business.NET or something like that instead of XL#.  A flexible programming environment for codifying business rules, crunching raw data, and visualizing results.  With a rich Windows client runtime library as well as a webserver runtime for processing and rendering on beefy, rack-mounted server farms.

That would be pretty cool wouldn’t it?  Excel gurus could transition from their Excel environments over to Visual Studio without missing a beat, and suddenly they’d be given new job titles like “Lead Business Logic Developer,” “Senior Analytics Programmer,” or “Rapid Modeling Engineer.”

In their new roles, they might be re-org’d into IT.  But they’d retain a very close affinity with the business units themselves – no matter who they reported to, they’d sit on the boundary between IT and the business unit, serving as both diplomat and translator between those two worlds.

And the apps those folks produced would be regarded as very different animals than they are today.  No longer would they labor to produce mere documents.  They would be producing business applications.  And given that increased gravity, everyone, including this new class of developers, would treat these applications in a more disciplined manner.  They wouldn’t just be anonymous files living in shared folders or inboxes somewhere, ready to cause trouble when an external change breaks their assumptions and disrupts the business operations.

Of course, the punchline is, most everything above is already true, except for the human perceptions.

Excel files are NOT documents!  They are applications!

et_hiding_thumb[1]

                  Pop Quiz for IT:  Can you spot the critical business app?

Yeah, I know.  Excel is part of the MS Office suite, just like Word, PowerPoint, Outlook, and OneNote.  So clearly, Excel files are just document content, just like those other applications, right?

Nope.  Excel is a development tool.  And no, I don’t mean “if you use VBA.”  The sheets are data structures.  Cell addresses are variable names.  Formulas are the core programming language.  Things like relative reference and formula filldown are the iterative constructs.  Charts and Pivots are data-bound controls.  Excel.exe is both the programming environment as well as the runtime.  (And now Excel Services serves those roles on the web).

(In fact, when I worked on Excel, one of the exercises we used to run through was to compare Excel to other programming platforms, and use those other platforms’ features as inspiration for new spreadsheet features.)

Excel has certainly benefited from being an Office application, so don’t get me wrong.  It would not be remotely as widely-adopted as it is today had it been marketed as a dev tool rather than as an Office app.  But I do want to point out that there as a side effect of being an Office app, the world’s most popular programming tool is perceived incorrectly.  It does not produce documents, it produces applications…  and then those applications get treated with the same informality that documents do.  Like an alien hiding amongst the stuffed animals in Drew Barrymore’s closet.

“OK Rob, I get it.  What’s your point though?”

I’m still thinking my way through this, but I’m pretty sure it is leading me somewhere worth going.

So far, I’m basically thinking that the most successful PowerPivot deployments will involve a new cultural view of the Excel professional.  A view that is at least very similar to the “what if” exercise I played out at the top of this post.

This line of thinking is also in some ways a “sequel” post to the “I” in “BI”, Part Three post.

What does everyone else think?  Are perceptions malleable enough for us to get there?

And credit where credit is due:  Dick Moffat was the inspiration for this post.  If you want to hear someone rail (quite convincingly) about the improper respect given to Excel applications and programmers, look him up on Skype or drop him a line on his blog.

Or even better, drop in at Tony Packo’s next time we get together, like we did this week with Mr. Excel.  Good times, good food, and even better conversation 🙂

Rob Collie

Rob Collie

One of the original engineering leaders behind Power BI and Power Pivot during his 14-year career at Microsoft, Rob Collie founded a consulting company in 2013 that is 100% devoted to “the new way forward” made possible by Power BI and its related technologies. Since 2013, PowerPivotPro has rapidly grown to become the leading firm in the industry, pioneering an agile, results-first methodology never before seen in the Business Intelligence space. A sought-after public speaker and author of the #1-selling Power BI book, Rob and his team would like to help you revolutionize your business and your career.

This Post Has 19 Comments
  1. XL#. LOL! And all I dream of is VSTA/LINQ support in Excel.

    “So far, I’m basically thinking that the most successful PowerPivot deployments will involve a new cultural view of the Excel professional.”

    A new cultural view of the Analysis Services professional might be closer to the truth. As you’ve no doubt noticed, those folks have highjacked the product:) What’s good about this situation is that we will see many Analysis Services style solutions in PowerPivot from a perspective that Excel professionals don’t have, but can steal…er, learn from.

    1. Colin – I’m not sure what you mean by AS Pro’s having hijacked the product. I know that the AS Pro’s are the first to have heard of it and so are doing the most talking at the moment.

      But six months from now I expect a much different mix of authors playing with it – heavier on Excel pros. It would be very hard for a thousand people to hold sway over an audience of millions 🙂

  2. “but can steal…er, learn from.” Can extend (?)

    I see PP as a potential “wedge” for Excel and for Office 2010. In fact the combination of PowerPivot in both the client and in SharePoint and also of Access 2010’s new SharePoint story. What I want t find out next time I’m connected up to SP 2010 is whether PowerPivot can connect to the new Access tables (or to SharePoint lists) …. I don;t think so – but that has to happen IMHO.

    Thanx for the nice comments about my “railing”. I tend to call it “ranting” actually :-). I think we all need to stand up more for what we do and what we bekieve are the real strenghts of these technologies. After 25 years promoting spreadsheets I am really glad to have Rob on my side – and we’ll accept anybody who also wants to help.

    Dick

  3. “What I want t find out next time I’m connected up to SP 2010 is whether PowerPivot can connect to the new Access tables (or to SharePoint lists) …. I don;t think so – but that has to happen IMHO”

    Not sure what you mean by new Access tables (new in Access 2010?), but in SharePoint, Access tables can be published as SharePoint lists. In SharePoint 2010, lists can be exported as an Atom feed. Therefore, using From Data Feeds–>From Other Feeds in the PowerPivot window, you can import SharePoint 2010 lists.

  4. […] the original post: Microsoft Unveils New Programming Language: XL# « PowerPivotPro By pivot | category: pivot, pivot data | tags: core, core-programming, formula-filldown, […]

  5. I haven’t seen that part of PowerPivot but it sound slike it should work. In Access 2010 the tables created by Access Services are actually SharePoint Lists so this may be the way. I am not sure about Access 2010’s Web-Based queries though. I expect there will have to be some work done on that. I’ll check it out in the next week.

    Dick

  6. BTW, I don’t understand why PowerPivot doesn’t explicitly list SharePoint lists as a data feed as it does for Reporting Services. It’s not as if a SharePoint list is a generic data source.

  7. Interesting post.

    I’d like to think that now Microsoft is positioning Excel as the front end of their BI solution (with SharePoint, PowerPivot etc.) it, and Excel professionals, will be taken more seriously.

    Hopefully the job you describe will become reality in the near future, I’m definitely up for it 🙂

    1. I think that is very much happening. But it’s at least partly up to Excel professionals to help change perceptions. We have to earn our spot at the “grown-ups table.” If we get the proper engagement from IT, excellent. But we also have to live up to that and build spreadsheets that are more robust – at times we will still be tempted to do something “quick and dirty” that will break down the line. We need to be part of the solution and instead work proactively to make a more robust solution possible (by engaging IT on the problem).

      If either side – the Excel pros or the IT folks – doesn’t bring the proper amount of proactivity and good faith to the table, then likely we’ll be right back where we started.

  8. I think that it’s silly to build applications or ANYTHING based on Excel. Excel doesn’t support simple data entry / validation controls. It will be an unacceptable platform FOREVER until it starts to get some of the same functionality that MS Access has has for the past 15 years.

    I still don’t understand why MS Access isn’t the center of the BI World.
    It technically is- you guys are just in denial.

    1. Pretty rude comment Aaron, but I think it’s rooted in misunderstanding.

      1) I’ve never claimed, nor will I ever claim, that PowerPivot (or traditional Excel) is the place to collect, store, and shape data. In fact I say just the opposite everywhere I go. See these articles for a flavor:

      https://powerpivotpro.com/2011/11/why-powerpivot-is-better-fed-from-a-database-pt-1/
      https://powerpivotpro.com/2011/11/why-powerpivot-is-better-fed-from-a-database-pt2/

      2) There’s no reason why Access cannot be the db in those situations. We use SQL at Pivotstream but Access would be fine in many circumstances. PowerPivot and Access are a frighteningly powerful combination and are not meant to be either/or. I used Access as my data source while writing my book for example – not Excel, not SQL.

      3) PowerPivot is even less of a good place to collect, store, and shape data than regular Excel. Sounds impossible but it is true. The PowerPivot tables are completely non-editable! Maybe you didn’t know that.

      4) In terms of analysis and advanced reporting though, the only place where Access is better is banded reports. If we’re talking about aggregated/summarized/intelligent calcs type of reports, PowerPivot is light years better (and different). I say this as a former engineer from MS who used to work on Excel but work very closely with the Access and Jet teams. If you disagree I think you should look more closely at PowerPivot. Your Access solutions could become a lot more valuable to your customers if you front-ended the analysis with PowerPivot.

      5) We should realize that in many ways we are on the same side here. IT has been waging war on Excel and Access alike for many years. While they hated them both equivalently, they have been more successful (in large orgs) at eliminating Access than Excel, because the db function was easier for them to centralize than analysis – that’s not a sign that Excel is better technology than Access, but rather a reflection of human factors. In smaller orgs, the war against Excel and Access was equally unsuccessful (or never fought).

      6) In short I think your “fight” is with things like SQL Server and Oracle, not Excel and PowerPivot. Excel and PowerPivot does nothing to invalidate Access, in fact it only magnifies the value your Access solutions provide – on the reporting and analysis side. It’s free, you might as well harvest it.

Leave a Reply

Your email address will not be published. Required fields are marked *