more ribbon fun

Got an ‘anonymous’ tip off about this excellent article here.

The author is a well known and respected quant who has contributed some excellent xll stuff to the community. He comes to a similar view on the ribbon as many of us, but raises some interesting points along the way.

The most interesting one, and one that hadn’t fully occurred to me is the impact of alienating power users. I had wondered if power users had the power to sway purchase decisions, and the general view seemed to be that the people in power in most orgs were probably not spreadsheet gurus (but they might listen to them). So direct influence = no, indirect = maybe.

I had missed the ‘role model’ aspect. He uses the example of Photoshop with pro photographers. Adobe clearly gain some non pro sales from folks wanting to emulate the experts, and the fact that most magazine articles demo Photoshop helps too.

I’m not sure the spreadsheet market is quite so competitive, but it is becoming more so. What I mean here is that Windows machines come with a basic graphic editor (Paint), but no basic spreadsheet. But Open Office and the Google offerings are starting to gain momentum…

As a power user (’role model’?) I’d prefer to invest in learning the products that respect that investment. This has to be balanced with progress/improvements of course. Microsoft seem to be aiming somewhere different to me in this regard but then rapid obsolescence is the basis of their business model I guess. I don’t think that is conducive to a vibrant expert community, or expert consulting business models though.

A boost in on-line resources targeting OOo Calc could quickly undermine the Excel ecosystem I reckon. And the power users/role models, those that the interface shuffle hurts the most, are the providers of much of that ecosystem.

BTW my main ribbon objection is shuffling the commands, (and what that represents in the big picture) all the other stuff I would live with. It is after all just a fat clumsy toolbar.

And those of us who were on the beta program will no doubt recall the impact of the ribbon and the response it got, although I guess thats all covered by NDA?

I remain to be convinced that Office 2007 is booming sales-wise, if it were, there would be proper hard facts to back it up. If anyone has links please leave as comments, ta.

cya

Simon

suboptimal

I was doing a bit of mechanicing the other day. As with any practical job I do, the first x amount of time is spent searching for the tools and materials.

On this particular occasion though it was more like x times 5 time spent ratching around looking for stuff.

The job involved mainly 10mm bolts (approx 3/8″?). I had no bother finding a 10mm spanner, in fact I had a couple. But a socket would have been much better for this job. Pictured is an 11mm socket - I found 2 of them, but I could not find the 10mil. In fact I think I have (had) at least 2 of them too, although it looks like I need another.

I spent a fair bit of time wielding the spanner thinking how much easier it would be with the socket. Both when I took it to bits, and again when I rebuilt it.

I find software dev to be similar, whether to go with the known, known to be poor approach, or spend an unknown amount of time and effort searching for a better way.

How might you describe that?

If (time/effort poor way) > (time/effort best way + time/effort to find it) * (1/chance of finding it)) then best way else poor way.

Or

If (time/effort saved best way - time to find it) * chance of finding it > 0 then try the best way.

In my case I reckoned the time taken to find it (if possible) would be way more than the saving so I just did it with the spanner.

I guess there is also a ‘preference’ factor (prefer researching to working badly), and maybe a ‘pressure’ factor too?

Do you have the same though process? how would you describe yours?

cheers

Simon

Function structure

Its quite common to require opposite pairs of functionality. Things like show/hide, or hide/unhide, or protect/unprotect, register/unregister, load/unload… you get the idea.

There are 2 basic approaches to this:

1. have 1 function that takes a true/false parameter to tell it to do or undo the action
2. have 2 clearly named functions whose names are good opposites, as above.

Which do you prefer?

I personally prefer the 2nd (I think) and I would say thats usually the way we interact with COM object models. I notice a lot of C code and Win API stuff uses the first though, so I thought about it a bit more.

I think the second (2 separate methods) is probably easier to understand, but on reflection the first is maybe more powerful. Or at least allows more concise code.

compare:

if msgb = vbyes then
menu.show
else
menu.hide
end if

to the more concise

menu.show(msgb = vbyes)

I guess the hard bit is getting a method name that makes sense with a true false parameter. Maybe a property gives the best of both worlds?

menu.visible = (msgb = vbyes)

What do you prefer? in your own code? in working with others (eg libraries)?

cheers

Simon

Why VBA is so rubbish

The last VBA post may have given the impression I’m some kind of VBA fanboi. I think it has its place, but it’s far from perfect. I put my definition in that post so I wont repeat it here.

I think its important to keep in context of what is out there live in the real world now, so I’m not going to suggest another language is better. In pure terms python (or your personal favourite language) maybe a better language for users to do basic automation etc. The reality is there is a lot of VBA code around, and more gets written everyday. I think the language would benefit from a few modern features, perhaps to support OO more fully, but not at the cost of backwards compatibility.

I’m also going to skirt around the issue of user competence. You get crappy code in every language, some languages may encourage it more, or may be more attractive, or more accessible, to developers of limited skill and experience.

It has been suggested that giving something as powerful as Excel/VBA to an unskilled user is the equivalent of giving a loaded rifle to a child. The reality, I would suggest, is a little less dramatic, as far as I know, no one has ever been killed by a poor quality spreadsheet, and very few companies have gone bust because of one. Yes SocGen just lost a stack of cash, but a person did that by trading badly, not a spreadsheet.

VBAs biggest fault?

I’d say its too easy to go beyond its design envelope.

For simple automating Excel and standalone complex worksheet functions (eg: the stuff Mike talks about) I think it is great. Its easy to slip from there to 10/12/14 KLOC systems, at which point I think VBA can work against you.

The other side to that argument is perhaps there is no realistic migration path, or no realistic alternative. That may or may not be true, but either way is not a fault of VBA.

Second - The editor. Frankly its so arcane I think Integrated Development Environment is a bit rich. If this just got updated to the VB6 one (which has more visible object model) add-in devs would fix everything else. Ideally though I’d like a VSTA style editor that writes proper VBA, or something completely compatible, in Excel 14.

That would also fix my third biggest fault - Microsofts lack of public love for VBA. Many devs are worried about its future, and hollow verbal assurances don’t cut it. A significant investment in upgrading the IDE, or replacing it with the VSTA one would settle the uncertainties for many.

Speeding up the call interface would be excellent too. As would allowing VBA UDFs to participate in multi-threaded calculation.

VBA’s reputation as a meddlers monster creation system (/toy language) hardly makes it the sort of thing you want to own up to at a party. The political correctness bureau solution to that is the change the name (eg ‘disabled’ went to ‘people with disabilities’ now moving to ‘differently abled people’) in general the ‘name’ gets longer as they use more circuitous language. So perhaps renaming VBA to something like AAS (Application Automation System) would fix any stigma? (of course it would have to be MAAS or MOCAAS (Microsoft Office Client AAS)). You get the idea.

Any other suggestions? the ruder the better.

What would be your top 2 or 3 weaknesses of VBA?

cheers

Simon

Boom!

Thats the sound of me getting blown out on a bid for work I just did.

It was a small project - just a few days work. But it was Office 2007. I have never made it over the UI barrier that everyone including Microsoft accepts is there for experienced users. I’ve had no need, all my fee paying clients till now have been on 97-03.

Most people are suggesting several weeks of reduced productivity in moving to 2007, and I havent seen any non-MS sponsored reports of improved productivity after, but thats by the by. This post isn’t about the ribbon its about the business of the ribbon.

I estimated an additional day because this project was 07 rather than 03. Who should pay that? Me or the client? I costed in half of it. (and didn’t get the job)

You could argue I should pay to learn the new UI as an investment in my future consulting business. Thats totally valid, but the ribbon is not one of my current investment targets, I am investing in other areas.

You could argue the client should pay, they insist on using 07, so its a cost of their platform choice. I think thats valid too, but possibly an easier sell on a larger project.

Personally I think Microsoft should fund the training - they forced the UI on us disregarding the massive opposition. They also ignored the many requests for a compatible UI option. They chose not to default it to something a current user would recognise. They stand to benefit from an updated ecosystem to support their latest products.

So is it Microsofts fault I didn’t get the work? no of course not. I have prioritised my learning investments and the 2007 UI has not made it to the top of the list yet.

I’d prefer my free course somewhere warm and sunny please MS, the weather is dreadful here.

Ribbon - who should pay?

cheers

Simon

In Pursuit of Spreadsheet Excellence

The 2008 Eusprig conference is coming up in July. There is a current call for papers, the deadline for which is the end of March. Full info here.

If you are wondering about submitting a paper, but aren’t sure, feel free to email me for an informal chat. I’m nothing to do with paper selection, but I’ll happily discuss my experiences as a speaker.

Personally I think a few more papers from people who earn their living working with spreadsheets, talking about real world quality would be very welcome.

wtf is ‘Spreadsheet excellence’ anyway?

I reckon its the skilled application of suitable quality spreadsheet based components to appropriate issues, and the effective management of their lifecycle.

What does it mean to you?

Busy MS devs

Great post here comparing .net devs to American tourists.

The point that .net devs are so busy trying to keep up with the release rate of MS technologies is well made I think. Joel calls it ‘Fire and Motion’.

I think we in Excel development have been spared this to an extent. Of course the surrounding technologies have been changing rapidly, but the core Excel stuff hasn’t ‘changed’. Some parts have expanded, some new stuff has been added, but nothing really ‘changed’. Until the ribbon of course.

Many of us are still trading off our Excel 97 knowledge, how many new worksheet functions since then? dunno, none? a few? How many new features? a few, error checking, a few other bits and bobs. How many broken features? none, I’m pretty sure Excel 2003 copes with pretty much anything from 97, and maybe 95.

That core consistency has enabled me to really improve my design skills, and skill up on complementary technologies that offer a massive bang per buck for clients.

With Excel 2007 the .net hamster wheel rode roughshod over our calm consistent world.

Was it a one off or the start of a new trend? Neither I would say, its Office moving into line with many other MS technologies.

Whats going to be in Office 2010 (I reckon the OOXML stuff will put it back from the rumoured 2009)?

Will it be the same UI as 2007? a face saving return to something a bit like menus, but different enough to have a new name? A new interface paradigm?

I really don’t know (but I have my suspicions), what do you think?

cheers

Simon

Ouch!

I see the EU have fined Microsoft a chunk of cash for not complying with their recent rulings.

It sounds a lot in Euros and Dollars, but not so bad in sterling (700M), its 1/40 of what they offered to buy Yahoo (44B USD). And1/20 of its current cash hillock (19B USD) (downgraded from a cash mountain). It represents about a months worth of revenue from Office I think.

(Figures from Yahoo finance)(note the irony)

I hope they can still afford a couple of devs and testers to add some modern code editing/management features to the VBA editor in O14 (tabs, project explorer etc - useful stuff, no pointless new interface please). Or if they can’t afford that then maybe just open up a bit more of the VBAIDE object model and we’ll do it ourselves.

Cheers

Simon

Turkeys and Christmas

Imagine in full Doolittle style you can speak to the animals.

Imagine further that you speak fluent turkey.

You visit some of the large turkey farms around the beginning of December and ask them to vote on what should be top of the Christmas menu.

Will they vote for turkey? or will they vote for anything but turkey?

(If you don’t eat turkey, and/or celebrate Christmas than substitute event and food of choice (vegetables are fine - our royal family are well known plant talkers)

-

Imagine you speak fluent IS department XAML jargon.

You visit you IS department at the start of next years budgeting round and ask them to vote on whether they should empower their business users by providing access to the tools and frameworks that the IS department currently only use themselves.

Will they vote themselves out of a job?

The best will understand that empowering the users helps everybody and will not lead to job losses in IS, it may even lead to more rewarding work for people throughout the organisation. There won’t be many of these though.

Most will vote to keep as much control as possible, so that would be no dev tools to users. They will continue quoting crazy money for internal projects. Thats not real money by the way, its cross charges, not real customers giving the company real money in return for providing them with something of value. More on that later.

Every organisation will have significant use of spreadsheet based systems, those that have an excessive dependency on them have an IS department rooted firmly in the second camp above. Those that use spreadsheets in conjunction with other best for the job tools (eg Access, ADO, COM, .net, etc etc) have a more enlightened IS department - these are great places to work.

I’ve worked in few of these great places anyone else?

cheers

Simon

Whats so good about VBA?

A (very valid) question from Johan.

Here is why I think VBA is so great, but first lets try and define VBA.

A tightly integrated application automation system that allows professionals from non software development disciplines to enhance their organisations use of the host application. With justifiable levels of training costs and tooling costs.

And secondly, lets add some context - we don’t develop in a vacuum so we should not review our tools in one.

Its 2008, VBA was integrated into Excel in v5 in 1995, last notable update was 97 really when we got the current IDE. Prior to VBA many orgs has dipped a toe in the macro waters with XLM and Lotus macros. Many organisations have over 10 years worth of live VBA code. And coders with 10 or more years experience solving that orgs problems with that toolset.

Software vendors desperate to sell us their latest version have almost convinced us that ‘legacy’ means ‘old useless shite that should be thrown out’. But legacy also means ’something of value handed down from ancestors’. What better legacy than tested, proven, working code, no matter how out of fashion the language might be? or how ‘not to your style’ the code might be?

I’ll be frank, I don’t much care for BASIC derived languages, I prefer C based ones. VBA has a few language features missing, and a few backwards compatibility ones I’d happily see removed. It also has the odd inconsistency, and a few awkward twists (If not (x is nothing) then... springs to mind). VBA is more, much more than a language though, its a complete system in partnership with the host app, with history.

‘Do you like the whole VBA story or not?’ boils down to do you savour proven, working code? or do you like new stuff? Do you like safe and certain? or do you like unnecessary risk and waste?

VBA has a major entry barrier for someone from a user background (I mean business here, but also science, engineering etc - anything except sw dev I guess). But once over that barrier is a gentle learning curve through to extremely high levels of productivity. Object Oriented approaches represent an even bigger barrier to that target group in my opinion, with limited payback in that problem domain.

Excel is a functional tool, its users understand functions - they write them in almost every cell. Very few use classes, objects make no sense to Excel users. Classes are considered an advanced technique in Excel VBA, not because they are difficult, because they are an unusual way for a spreadsheeter to go about solving the sorts of problems they solve with spreadsheets.

Spreadsheeters email their spreadsheets around, this approach is absolutely proven to work in (and out of) organisations of all sizes all over the world in all industries. VBA supports this zero deployment in almost all cases. Most spreadsheet users have never heard the expression ‘deployment’ that is how ‘zero touch’ VBA is. (many have never heard of testing either but that is a separate discussion)

The Excel COM object model is an ideal target for VBA, optional parameters, parameterised properties etc are all fine. Unlike C# for example, which is from a whole other era, designed from the ground up to solve a whole other type of problem. Should Excel get a C#/manged code friendly object model then that would even things up a little. But by then there might be 15 or 20 years (or more??) of VBA legacy code to compete with.

Whats so good about VBA?, is like saying whats so good about driving on the left? honestly? it would be better for a whole host of reasons if we swapped and got in line with all the new world countries. But who, when, how and where could this be done? and who will pay, and when would they get payback (hint: never ever ever).

Whats so good about VBA? its here, now, in widespread use. Perhaps the correct question is what should an organisation that is already heavily invested in VBA (most are) do now in 2008?

Of course theres lots to not like about it too, but thats a topic for another post. The point of this post is that I don’t see anything currently better than VBA for most of the stuff that VBA is used for, and for the folks that use it.

Maybe the VBA argument comes down to: SW devs will always hate it because its an impure bastardisation of a beginners language. Business users will prefer it to the other available options because they can leverage existing investments, so it represents the best value for money.

Try this test: ribbon v commandbars? .net v VBA? either you like new stuff or you like existing proven stuff.

What have I missed? anything to add? anything you disagree with?

cheers

Simon