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
Smurf on Spreadsheets 
Friday, 18th April, 2008 at 9:59 am |
“too neat = gold plating/time wasting”
I have serious issue with the form over function argument. Any solution for serious end user implementation requires form and function. While there are always examples where form takes over function (that is: looks pretty but does bugger all), if the form confuses or repels users, then the function becomes irrelevant.
Users are becoming more sophisticated – they expect that the solution is going to work. Whether the solution will work elegantly and intuitively is another matter – this is where form comes in. iPod would be the success it is if it simply played music – Apple invests heavily in getting the interface (form) as elegant and intuitively (some use the word cool – or kewel).
In term of other people’s code which ‘selects’ anything usually says that the macro recorder is doing most of the hard work.
Also code that isn’t modular – especially where the same functionality is repeated within a given routine or across several. And crappy error handling. A MsgBox stating “An Error has occurred” is hardly useful.
The “Dim x, y, z as Integer” situation usually says that the coder has a C++ background and has jumped into VB/A without reading up on the semantics.
Poor naming conventions is another bug bear for me.
Dim rst1 as RecordSet
Dim rst2 as RecordSet
…
Dim rst7 as RecordSet
Doesn’t cut is for me. When you’re in the thick of the code you have to keep jumping back to remember what rst4 referred to again.
It’s not an absolute measure – everyone expectations, standards and experiences are different. Have a look at JoS and you’ll regularly see religious wars flare up such as the superiority of stored procs over in code SQL.
Cheers – Marcus
Friday, 18th April, 2008 at 10:25 am |
It has to look decent.
Overzealous formatting (too many colours, use of sans comic!!!) no formatting, lazy, or don’t know better – not a sure sign it a bad bit of work though.
Code,
not explicitly defining which sheet should be used:
cells(1,2)….
rather than wksHomePage.cells(1,2)..
use of hard coded values,
OE.
there’s load really isn’t there, I think if i see a more than a few then I would start to question if the code was robust.
Friday, 18th April, 2008 at 11:44 am |
Ross – good call
I had a bad experience with comic sans once, now I automatically assume anyone who uses it is dangerously stupid.
Friday, 18th April, 2008 at 3:52 pm |
I have to disagree on the “too neat = gold plating/time wasting” assumption. Logical formatting can help the user tremendously. I like to continually update the formatting on spreadsheets to give the user useful information.
If you are talking about formatting that serves no purpose, like the rampant use of meaningless colors, then I agree. But I don’t think spending a lot of time on intricate formatting is a waste of time.
Friday, 18th April, 2008 at 5:31 pm |
The first thing I do when reviewing a sheet is to set the zoom to 10% and see how it’s laid out. When reviewing code, I click on MZTools ‘Sort Procedures’ view to get a list of procedure names and their order in the module. In both cases, I’m looking for order, structure and some evidence of a logical thought process going into the development. If I don’t see that at first sight, I know I’m in for a long day…
Friday, 18th April, 2008 at 6:02 pm |
My first indication of a problem:
UI = three sheets, two of which are unused.
VBA = lack of indenting and use of the Selection object
Friday, 18th April, 2008 at 9:03 pm |
I see a range from
not neat enough
neat
very neat
too neat
perhaps too flash or too polished might be a better expression? or is there no such thing as too much effort fine tuning the visuals?
Saturday, 19th April, 2008 at 4:32 am |
Simon –
I guess it depends on whether one is polishing up an application or just polishing a turd.
Monday, 21st April, 2008 at 12:28 pm |
[…] is especially the case in the “reporting/presentation” layer. Recently Simon posted about the first thing we look for in a spreadsheet we inherit. He was interested in know the key indicators that the […]
Monday, 21st April, 2008 at 9:12 pm |
Too late to join this?
For worksheets, I start off by seeing what’s hidden – columns, rows, sheets, names, cells with number format ;;; or text color same as background color. I have macros to do this. Next, check whether each worksheet’s used range spans either all columns or all rows. Then I produce a text file listing of all global defined names and by worksheet local defined names and all cells’ contents in R1C1 addressing. I pass that through some awk scripts to get the frequency of function calls and a matrix of the number of references from formulas in each worksheet to ranges in every worksheet. This gives me an idea of what I’m in for in terms of complexity.
For VBA, variable declarations and use of Goto and On Error are the main things I try to determine whether are needed or not. Since VBA lacks an equivalent for C’s continue statement, limited use of Goto within loop constructs is OK with me. Frequent use of Goto is a bad sign. Use of : as statement separator is also a bad sign. Overuse of parentheses in arithmetic expressions can also be a bad sign.
Tuesday, 22nd April, 2008 at 8:07 pm |
Slightly cynical comment but does anybody else find you can charge more if it looks pretty? Once did a highly performance optimised model for the fixed income group of one of the banks (they specified that it had to be pure VBA but that it also had to be fast) and you know what impressed them the most? The pretty title page with their logo on it.
Tuesday, 22nd April, 2008 at 10:04 pm |
Al, that’s not cyncical; that’s real world. Hence my comment regarding form over function. The client will simply expect that the solution does what they’ve paid for. But in the end pretty pixels sells. I find that it’s important that a solution is aesthetically appealing because the (usually) have no idea what’s going on under the bonnet.
Tuesday, 22nd April, 2008 at 10:34 pm |
With regard to form/function, if a decision support system is only usable when reading printout, it’s a failure. From my perspective, it’s essential to economize on screen space (hence my feelings about the ribbon).
Thursday, 19th June, 2008 at 11:35 pm |
Leaving code aside, good use of defined ranges (with meaningful names) gives me some idea of the sophistication of the original author’s use of features, and their commitment to making everything easy to follow, troubleshoot and maintain.
Dynamic ranges as sources for Lookup formulas, Pivots, charts and so on score extra points (although they are probably bread and butter to most readers here, but not to the people / client users we all inherit stuff from)