JES – Just Excel Syndrome

This terrible affliction affects a wide range of otherwise healthy, dedicated, diligent developers.

The symptoms are simple to spot – some shoddy Excel/VBA monster tacked on the end of a super highly refined, mega abstrated, meta meta program work of digital art.

Their inheritance hierarchy is 10 levels deep, their UML designs fill 2 walls of the nearest office, Their code is pure joy to behold, a breeze to debug, and eminently extendable. Well most of it.

Because on this coding masterpiece, like an unwelcome carbunkle in an unspeakable place, they have grafted a tatty, pure amateur hour Excel VBA front end. The grid is big, impossible to audit mega formulas scattered randomly, the formatting burns your eyes, the VBA is 10 pages of macro recorder spew. ‘Its Just Excel’ it doesn’t matter.

A few people have contacted me separately about this issue recently. Rob sent me a link to a SQL Server article with tons of highly polished T-SQL feeding into a macro recorder abomination. I’ve also see it on projects I’ve worked on where the devs seem to have given up all quality requirements for the last step. I’ve seen big iron consultants insist on turning Option Explicit off to ‘make things easy’, on big, serious enterprise reporting apps.

Have you seen examples of this Just Excel Syndrome, at work? on line? in books?

I know most people are familar with Excel, is it this familiarity that feeds this complacency?

Other thoughts as to what causes it? Ideas on how to address it?



4 Responses to “JES – Just Excel Syndrome”

  1. JP Says:

    There was a similar discussion like this recently on Debra Dalgleish’s blog:

    Typical management move (“make things easy”? LOL), trying to force Excel to do everything, since everyone already has it. No understanding of any other tools that might be more suitable.

  2. Ross MIE Says:

    Yeah I don’t know why it’s like that? Maybe the guys just don’t like working wit VBA? It’s nearly always to do with reporting stuff at the end, isnt it? There’s no reason why they couldn’t take the time to do it better, but I guess they just can’t be asked, I guess it not exciting enough?

  3. Rob Bruce Says:

    Works the other way too, though. I’ve seen numerous carefully crafted Excel applications with absolutely dreadful database connectivity tagged onto the back end.
    My favourite example was a management dashboard. From the front it was very cool, quite responsive and gave every indication of being professionally built all the way through. Underneath though, on startup, it basically did a SELECT * on every table in the company’s databases and conducted all joins and filtering in code and/or pivot tables. To me it was obvious that the developer was a pretty talented Excel and UI developer who simply couldn’t be bothered to learn any SQL at all.

  4. Giles Says:

    I’m tempted to blame it all on VBA… but perhaps there’s more.

    When I was working at a Big Bank, there were – broadly speaking – two kinds of developers: the techie people, and the business-focussed people. Techies saw their careers being in technology, the business-focussed saw their careers starting in technology, but moving in the direction of the business, and in the long run often onto the trading desk.

    Techies learnt appropriate skills for their future careers – sofware development practices, new languages, OO design, and so on. The business-focussed people learned appropriate skills for theirs – quantitiative finance, option pricing, and the like. They would have learned some Excel, but it was one skill among many for them – and it was probably one where they overestimated their own ability anyway.

    Making this worse, there were plenty of experienced technical people on the development teams – because this was their career, and so they stayed there – but the experienced people with business knowledge all left the technology team and moved into business roles.

    Of course, it’s obvious who of these people wound up doing which part of each project. In the net, this meant that software projects were developed by experienced, keen, techies on the traditional software dev side, and junior developers whose long-term interests lay elsewhere on the Excel side.

    (On a side issue, if I found an inheritance hierarchy ten levels deep in our source code I’d start whimpering. Not good!)

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: