State of the profession

Dick M asks if we (Office developers) are a dying breed. At least I think he’s asking - he could be telling us our profession is wilting away. Whatever, I agree. Completely.

Office developer, Excel developer, business developer, these mean pretty much the same thing to me, its a person nearer the business than a traditional IS department dev. They probably use a range of tools/platforms, they mainly target desktop rather than server, Excel usually features as at least part of the interface (or calc engine), source data may be from a server database, but working data is likely to be in jet. Glue code may be VB6 or .net but most likely VBA. The best differentiators (from mainstream devs) are around business acumen rather than technical tool choice.

Anyway Dick mentions a few items, here are my thoughts:

Value for work - Bad and getting worse, its getting so only City institutions understand the value of Excel, which is bizarre considering their normal sheep like tendencies. ( I suppose they are flocking round each other).

Respect - Bad and getting worse, for years I was embarrassed to admit I did a lot of work in Excel, as ‘real devs don’t touch Excel - hobbyists only’. Then as Eusprig gathered momentum I got a bit more confident, but I think that quality/error movement has stalled a little now. So back to claiming to be a mainstream dev for me I reckon.

Continuity - Bad and getting worse, I used to coach client staff in what I was doing in Excel/Access/VBA etc. These days they turn their noses up, happy to pick up some SQL or C# but no Excel/VBA thank you. I just don’t see many people rushing into our technologies.

Conclusion - yeah we’re proper fooked. Unless MS are going to wake up to their most valuable asset - MS Office on an MS Windows desktop. By wake up I mean the hand in pocket wake up, not the cheap soundbite one thats been (pointlessly) running (well walking) for as long as I can remember.

I don’t think us devs will be the losers we’ll just move to techs where the opportunities are better. The real losers will be MS as customers move to other platforms that have an apparently better cost/benefit story, but only because they are unaware of much of the benefit of the MS Office platform. [Ignoring for the time being the cost/no benefit fubar known as the 2007 UI shuffle]

The other losers of course will be businesses far and wide that have to wait for their IS departments to implement their grossly over engineered, over priced, over due, big iron monsters, just in time to realise the business requirement has moved on.

The winners are of course the IS departments who gain control, power and loads of low pressure work. If you know you will release straight into retirement (rather than production) there are lots of unpleasant things you can forgo, like testing, and documentation for example.

Is this how you see things?

or are you seeing different trends?

How do you think things will pan out in 3-5 years?

Do you have an escape plan?

Please comment here or on Dicks post

cheers

Simon

Access queries

Marcus recently reminded me of one of my Access maintenance headaches.

Do you write all your queries as queries and store them visible in the query window?

Or do you keep them in your VBA so they are easy to manipulate?

Or do you mix it up to give the maintainer a hard time?

Just wondering as I’ve been caught out a few times tracing the logic of the visible components in other peoples dbs, only to find they are quietly modified in code (from multiple places).

I often use Excel as the UI and build queries in cells, but I do try and consider the maintainer (just in case its me ;-)).

The last jet project I did I added all the SQL as querydefs, that made debugging much easier as I could open the .mdb and tinker with the queries via the Access UI.

What do you tend to do?

cheers

Simon

Excel consulting firms

Where are they?
Where are the multi person Excel, or other spreadsheet, consulting/development firms?
If this technology is as important and useful as we think it is, and its hardly new (mature I think is the correct terminology (one step before legacy)), then why aren’t there more/any 10/20/100/200 person specialist firms?
Sharepoint has them, why not us?
(Is it because that is a ‘professional’ tech and Excel isn’t?;-))
Its like Excel dev is locked in the artisan phase and never going to move towards a more ‘engineered’ approach.
I’m not overly worried from a quality POV as I think if you get the right artisan you will get quality far beyond some tick list based ‘way’.
Its credibility that worries me, I think a few formalised big consulting firm standards would give the whole market a bit more clout. Even if they did conflict massively.
So where are they, and why aren’t there more?
cheers
Simon

First thing

Whats the very first thing you look at/for when you open a workbook from someone else? (that you trust not to be malicious)

And whats the first thing you look at/for when looking at someone elses code?

For spreadsheets its neatness/layout of whatever opens
too neat = gold plating/time wasting
too scruffy = slack/ little care

(Of course the ‘correct’ level of neatness is the sort of stuff I produce ;-)). I’m thinking use of formatting, use of number formatting, use of space etc.

I’d like to pretend thats its some kind of rational measure (file properties maybe?), but really its just a judgement on the initial visual appeal.

For (VB/VBA) code it is Option Explicit - missing = cowboy everytime. If its a snippet/function then I look to see if parameters variables and return are typed (as in Dim … as …., rather than dim x, y, z)

What about you?
one only for each category.
And is it relative to your own work? or do you think its an absolute measure?
cheers
Simon

Incompatibility strategy

It occurred to me the other day that one of the major benefits of releasing a new version of a product that is not very compatible with previous version is the speed of uptake within migrating orgs.

What I’m thinking of is how rapid the implementation is likely to be. If a company decides to adopt Office 2007 say, its likely to be a fairly sharp switch over. More so than say the move from 2002 to 2003, those co-exist much more easily.

Also for independent consultants like some of us here, switching back and forth from 2007 to prior versions is more pain than previously. That might encourage us to encourage clients to migrate to 2007, Or it may mean we drop non 2007 clients so we can stick with one version. Or we may avoid 2007 of course and offer 2003, 2002, 2000 and maybe 97 and OOo instead.

It seems that if you release an incompatible version you force people to make a choice about which version (or vendor) they will work with, but those that do migrate are unlikely to go back, and likely to drag others with them.

I know there are plenty of resources to help the move to 2007, thats not my point. I’m thinking that as soon as an org gets some 2007, they will want to move completely, rather than support 2 vastly different versions. If your IT team was going to support 2007 and 2003, then I wonder how much extra work it would be to support OpenOffice as well?

Many of the folks who have got past the initial hurdles of 2007 have suggested they do not want to go back and use previous versions as its is too hard to work with such different designs. Thats an interesting observation as I don’t mind at all using anything from 97-2003 and OOo as the differences are quite easy to work around.

I think the strength of the (generally strong) views around 2007 (either for or against) are part of the same thing (over the hurdle in ribbon user experience nirvana or resenting its pointlessness).

I’m not sure how the VB6-.net thing ties in, or if it does?

I’m not softening to the jumbled up UI, but I am starting to see a hint of a possible strategic justification. (I’m not suggesting it will work)

Do you think this is just standard planned obsolescence?
Would you do it with your product?
cheers
Simon

Access User Group - May MS Reading

Just got a note about the upcoming UK Access User group meet May 15th.

Its at MS TVP and they have great line up of speakers, if you don’t recognise the names, give yourself a slap and google them. If you are not a database person then fair enough I guess.

All the info is here.

might see you there?

cheers

Simon

Get some street cred

Those nice people at BonaVista are offering the chance to win an iphone (also known as the Jesus phone (El reg only?)).

Obviously its aimed at getting us to try their Excel add-in based micro charting tool to design your whiz bang dashboard.

I was wondering about aiming for second place so I can drag Stephen Few to Carlisle which is completely nowhere ;-)

Most people I know have a blackberry, not sure we could step down to an iphone, but some folks get quite forceful in their defence (so I heard…).

If you enter let us know how you get on (I’m guessing if you come last you may not rush to tell us?)

cheers

Simon

I think they mean us

Guerilla IT

How to love your superusers!

The article is a bit more related to sys admin type stuff, and thinly veiled sales pitches, rather than deep and dirty Office dev. But I like the principle - instead of IS battling against the power users, support them and encourage them - same effort, much better outcome for everyone.

Of course, back in the real world there is the small matter of something called FEAR…

I have worked at the odd place that worked this way and supported and encouraged those users pushing the limits. But most places are some way off I reckon.

Anyone else worked somewhere where IS encouraged them, or are we all brow beaten into submission daily?

cheers

Simon

Excel accuracy

The Excel team have a great post explaining Excels accuracy here.

Do you think its adequate for normal spreadsheet use?

Do you think it should be improved in todays 64 bit computing world?

Would you be willing to take a performance hit for greater accuracy?

My answers - yes, no, no.

In fairness I have tripped over accuracy issues in spreadsheets I’ve worked with, so if it didn’t impact performance (I’m not bothered about file size), and didn’t break a bunch of old stuff, then a few more significant digits would be welcome. What about you?

cheers

Simon

Consistency

important or overrated?

I think I am gradually getting more consistent in more things as time goes on and I find ways of doing stuff that I think are the best in the circumstances.

But every project is different and in many I will do a similar operation in different ways. Sometimes because I am searching for a ‘best’ way. Often because I forgot I already solved this in a previous project (even with the nagging deja vu). Sometimes I know I solved it before but can’t find the right project.

I do have tons of library code that finds its way into nearly all my projects, for managing Excel, managing Essbase, menus, common constants, ADO, logging etc.

I am thinking things like working with certain types of list, managing application state etc. Stuff that is not totally general but is in 1 in 3 projects or something. And I mean consistent across projects, not within one.

When I work with other peoples work if I find the same thing solved is many different ways in the same project I would probably start to worry. But if I got 2 projects and one used the app.rows approach and the other used the used range intersection approach it wouldn’t bother me as being inconsistent, would it bother you?

I think some consistency is handy enough, but overall I think it could be a little overrated, especially if we are constantly learning.

What do you think?

how consistent do you think you are (beyond library code stuff)?

cheers

Simon