Pricing

Many people moan about Microsoft pricing (excluding me, I don’t mind the prices, its that product activation I detest). I often read phrases like ‘predatory pricing’, ‘gouging’, ‘monopoly’ etc. when talking about Microsoft pricing policies.

But I was leafing through a Dabs catalogue the other day and I saw this

MS Word 2007 - 137.09 GBP

Adobe Acrobat 8 - 211.99 GBP

Whats all that about?

Are people complaining about Adobe pricing as much (or 55% more) than MS?

Are these products so vastly different its an invalid comparison?

I’d like to know who are the ‘better value for money’ competitors? Lets exclude open source from this, and just consider other software writer/vendors. I’m mainly thinking in the desktop productivity space, but if you want to suggest server stuff that makes MS look expensive (Oracle??) please do.

Cheers

Simon

VBA gone in Office 2009 rumour

Its gone in Mac Office 2008 and due to be gone from Windows Office 2009 (Office 14) according to El Reg. Being replaced by VSTA or VSTO apparently.

Personally I think The Register reporters have got that wrong. I fully expect VBA in Office 14, and I wouldn’t be surprised if it’s still the primary automation technology. Equally I can imagine VSTO/A being more thoroughly integrated, and perhaps being the primary automation tech.

I’m also pretty sure the Office folks aren’t talking publicly yet about Office 14, so I’m not sure where the Reg got their (mis) information. Or perhaps this is them trying to get MS to say one way or the other?

What do you reckon?? (what level of VBA support do you expect in Office 14? (full?, run existing but no write?, none? etc )

And also what do you reckon the consequences of a VBA-ectomy would be:

1. business v consumer
2. 12months after release v 3 years after release.
3. other

cheers

Simon

Who uses Excel autosave?

The first thing I do as soon as I start at a new client is turn this off the first time it locks up my pc. It might be bearable when saving to a local drive but is completely unusable for normal business spreadsheets over a network (in my opinion).

Does anyone actually find it useful?

I prefer to control when where and how my work gets saved what about you?

cheers

simon

Bad data bad decisions 2

Ages ago I moaned about how the wildly unrepresentative User Experience clicks program had been used to justify the abysmal ribbon. And have continued to ridicule it even though I said I wouldn’t - sorry about that.

Recently I had a pop about the wildly skewed on-line help usage data that MS are now using to try and slow (or maybe even reverse?) the decline in usefulness of Office Help. Assuming they continue to infer the behavior of the population based on their skewed on-line sample, then Help in Office 14 will likely be all but unusable for experienced users.

Imagine though for a minute you had accurate information about which file types people were working with. And further that many of the supported ones are almost never used. And also imagine some of those file parsers had some flaky pre-trustworthy zero day exploit fodder in them. Looks like a quick cheap security win right? make access to those files (and their flaky parsers) hard by default, and everyone’s a winner.

Meanwhile back in the real world, sadly the data is woefully skewed towards individual users with limited computing experience. Expert users and corporate users are barely represented - oops.

The User Experience piss poor data blight strikes again!

Does anyone have an example of where that ‘data’ ;-) was used and we got something useful?

Please Microsoft if there are any features in (or removed from - or just shuffled around in) Excel 14 driven primarily by those clicks, please get some feedback from the Excel community before baking them into the final build.

What do you think? Am I missing something?

cheers

Simon

David LeBlanc covers it very well here.

2 key takeaways from his blog post:

1. The choice was leave everyone unpatched (/insecure) for months or do this quick and dirty now. I suspect if they had had more representative usage data things may have turned out differently. I don’t blame the security team, I blame the invalid inference from the massively skewed User Exp. ‘data’.
2. The excellent way he deals with a rude commenter

Office 2003 SP3 feature-un-ectomy

Looks like MS have heard the howls and are going to provide a simple to use fix to re-enable older file formats on 2003. (ie automating the previously released registry hacks). I wonder if that might make it into 2007 too?

Here is the skinny from everyones fave news site.

I guess the point about OpenOffice and Gnumeric having better backward compatibility with Excel files than Excel 2003 SP3 and Excel 2007 smarted a little.

Fair play to MS for listening, and fixing it (in due course).

So that leaves us with a naming competition and a release date competition.

SP3a? SP3b? SP4? SP3-? SP3.1? SP3.2? KB0937840938?

I’m going to guess SP3a Feb 19th.

What do you reckon?

cheers

Simon

2003 SP3 security functionality-ecotmy (featurectomy)

I’ve seen it a few places now, but I’m still not totally clear on the actual impact.

Basically SP3 disables a load of file formats that 2003 used to support ‘for security reasons’(tm).

It adds a bunch of stuff to the registry to enable you to re-enable them if you need to. (and you want to edit your registry freehand (and your admins didn’t set it by policy)).

Here are a few links to keep you busy:

http://www.betanews.com/article/Microsofts_planned_obsolescence_smacks_Office_2003/1199306131

http://support.microsoft.com/kb/938810/en-us

[psst don't tell the bad guys - I'm still on 2003 SP1, everything since then has been security by removal (featurectomy is the technical term)].

Has anyone actually had a problem with this? I know they did a ton of fuzzing as part of the 2007 development, I assume this is the security issues they found in prior versions being closed (the easy way).

I don’t blame them for cutting stuff out rather than fixing it, but I do find it amusingly ironic. The standard MS response to any accusation of bloatware is always that all those features are there because someone is using them - not any more though, hey? I guess the new ‘more hostile environment’ justification come into play though.

Incidentally I have read a few problems with COM add-ins too after SP3, one to avoid installing if possible I reckon. If security is that much more important than functionality in your organisation you may want to consider pen and paper, or maybe an abacus.

Anyone got any real world experience of actual problems to share?

Cheers

Simon

Office updates

Office SP1 is not being added to Automatic Update yet. MS are giving orgs chance to test it and manage the deployment. Good, that makes sense.

However…

They have made a ‘update blocker’ available that companies can install to prevent the automatic update getting triggered.

This seems a bit backwards to me. Shouldn’t the update mechanism just be more managable?

just sayin…

Consistency or quality?

I’m working on a remote spreadsheet patch that will be applied to a few thousand workbooks worldwide for one client. I didn’t write the base spreadsheet originally but have maintained it for years. Its a standard big gnarly finance model with a few hundred thousand formulas and 6 thousand lines of VBA.

The remote patch tool I use can pretty much make any changes, including swaping worksheets, replacing formulas and array formulas etc. It can also add/remove/edit the VBA, and it cleans the VBA on each application.

This particular patch is a pretty deep surgery one, normally its just salary rate, currency rate and some other financial reference data changes. This time though the business needs have changed and some reports need re-working.

One of the frustrations is the hardcoded range addresses in the VBA.

public const countycol = 64
Public const currency = “J33:L66″
etc

I have to change these each patch - if only they had used range names…

So now I need to add some more.

1. Should I stay consistent and use the same crappy hardcoded approach or
2. Should I add my new ones as defined names so they at least work right and won’t need further maintenance?
3. Should I rip out the working code because its ugly and redo it in what I currently think is a better way?
4. Other options?

I’m currently planning on going with 1 unless someone comes up with something pretty convincing in favour of one of the other approaches. Heres why:

• Any further maintenance will have to update the current ones anyway, a couple more will add seconds to the next patch.
• Starting changing the mechanics now could backfire in future patches
• I think I prefer a consistent (ly poor) approach to hit and miss quality

2. will probably not get updated right as the assumption until now has been there is no need to insert rows in the worksheet, as the ranges are defined in code.

3. might be nice, but the client won’t pay because they won’t see any benefit.

4.?

What do you think? Any other reasons to go with option 1? Or reasons to avoid it?

Does anyone else do this remote patching? what approach do you follow?

(we tried to export the data to a new model, with the new logic, rather than apply new logic to existing data, but the users data proved to be too unstructured for that to work reliably.)

cheers

Simon

Some gory VBA details

I found a great link the other day describing the decision to drop VBA in the next version of Mac Office.

Here it is

Well worth a read (its long mind), although I’m not sure if it gives those of us in the Windoze world any guidance for the fate of our beloved VBA.

In the ‘Future of VBA’ session at the conf I estimated 2020 something. Anyone else prepared to stick their neck out?

If you have time to read that whole post and all the comments (and you probably shouldn’t!)(I still did it though - thats another hour of my life I’ll never get back). But if you do there are some really juicy gossipy tidbits. All pure blog sphere gossip, could be completely untrue, in fact almost certainly is untrue actually.

Jonathan said: ‘Steven Sinofsky (at the time the Group VP in charge of Office) has made several public statements that VBA would remain in for “at least the next two full product cycles” of Office. The first of those is Office 2007′

Richard said: ‘nd that office for x86-64 is dropping VBA support.’ [Anyone else heard this? I'm not convinved]

Nick Hodge? Nick Hodge? Oh, its the other one, not the ‘real’ one.

Various: a version of .net for MacOS might solve all the issues (and re-align the Mac and Win programmabilty story)

Various: Dropping VBA is the start of the end for MacBU.

One interesting factor from a business POV is that the single shining USP (unique selling point) of Mac Office is Win Office compatibility I’d have thought? surely?

I don’t recall ever reading advice that dumping your USP was going to improve business.

Also interesting was the mention of difficulty filling vacant roles in the MacBU. I’ve seen this mentioned elsewhere about MS in general, and the fashion to want to work at Google instead.

There is a good technical explanation of some of the guts of VBA that are almost universally derided by the commentors. Personally I suspect that code is hard to maintain because it was coded to eek out the maximum performance on a platform less powerful than a modern mobile phone. Not because the coders were ‘brain dead’. (That and the fact there are few C coders still coding now)

I had my win 3.11 lapper with Office 5.0 at the conf, circa 1993 vintage.

80486 proc, 640k RAM, 163 Mb Hard drive. [Edit - caught red-handed by Harlan, there is 3 Mb Extended Ram too]:

VBA was conceived, designed, coded, built and tested before that time, and worked acceptably. And I bet some of the guts of the Excel calc engine hail from that era too.

I really don’t agree with the often stated modern view that performance is not an issue anymore. Maybe not if you are waiting for a web or database connection or user input action , but for the number crunching I see and do, performance is extremely important. What about you?

Cheers

Simon

Security - pah!

Most ’security’ arguments are little more than thinly disguised attempts by IT departments to get back the power and control they had in the golden era of the mainframe.

That pretty much sums up the view of most of us at the dev conf last Saturday. And I think a fair bit of the web app and server based systems focus was put down to similar motivations.

I’m not saying security isn’t important and neither was anyone else, just that as business developers working in and around Excel it probably doesn’t need to be top of our agenda.

What do you think?

In most organisations it really is someone else’s job, or possibly something else’s job (Firewall, Anti virus etc etc). That’s not to say we abdicate all responsibility, just assign a level appropriate to our exposure.

I think for developers in other areas, especially web apps that are connected to the wild wild web, security does need serious focus. For most Excel/VBA stuff I’m not so sure.

Many of the delegates set macro security to low preferring instead to rely on other controls, like trust of where a workbook comes from and AV scanning etc. Personally I prefer medium, but having discussed it I can understand why others feel comfortable with low. (of course I can’t see how to set Excel 2007 to my preferred setting.)

Incidentally Charles also pointed out the most recent VBA malware report he could find was from 2002. I’m more concerned with crapware VBA (ostensibly innocent, but so badly written maliciousness may be closer).

Should our little part of the business/developer world worry more about security? what benefits would it bring? what real world losses could have been avoided? And what macro security setting do you use?

Cheers

Simon