Fix or rebuild spreadsheets?

I think the general view throughout development is that it is often easier to rebuild something from scratch than it is to fix/understand someone else’s tortured logic.

Personally I find that even more true for spreadsheets, I routinely re-copy and paste formulas across blocks rather than check they are consistent, for example.

But I wonder if spreadsheets are a special case?

I think its generally quicker to build most systems in a spreadsheet than in a more mainstream technology (database or code). And I think its harder to test/check/understand someone else’s spreadsheet than it is someones code or database. I don’t think this is just down to the skill of previous developers. I really think that spreadsheet technology itself is challenging to un-pick.

This seems like a double whammy, easier to build + harder to adapt surely means very few spreadsheets will get maintained?

what do you think?

My experience is that as business requirements change it is very common the throw away a spreadsheet and commission a replacement. But maybe when I think about it I am given the choice, and I usually choose to use only very limited parts of the legacy app.

I also wonder if this ‘disposable’ mentality is self fulfilling? No one expects the model to last long so no-one is prepared to invest a decent amount of effort to get a solid, adaptable version?

Or is it desirable, as per Fred Brooks suggestion to plan to build 2 systems, because you will anyway?

Cheers

Simon

Advertisements

5 Responses to “Fix or rebuild spreadsheets?”

  1. Lord Says:

    This is actually common with most software, just to different degrees. The reason is software has to be adapted to uses it was not originally designed for. As the changes accumulate, the original design degrades, performance worsens, complexity rises, errors are introduced faster than they are eliminated, until it becomes time to refactor.

  2. Harlan Grove Says:

    Spreadsheets, in terms of the worksheet formulas, layout, formatting, etc., are very different from Brooksian development. It’s very much more difficult to coordinate multiple developers working on single workbook applications.

    Then there’s the question of ‘coding standards’, meaning formulas. What’s the best way to write formulas? What’s the ideal naming convention? If there were several developers involved, or perhaps different developer and maintainer, standards become necessary. Unfortunately, while it’s possible to prove which formula idioms work best (which could vary depending on the space-speed trade-off), it’s possible to poison a working relationship by having to prove your own work best.

    The sad fact is that this also tends to apply to my own stuff written a few years ago.

  3. Dennis Wallentin Says:

    Fix o rebuild spreadsheets is a question what the customer is prepare to pay for. If there is a documentation then it may be possible to only fix spreadsheets. For more complex spreadsheets I only quote for new solutions.

    I still maintain a solution, developed by me, from 1989. Each time I see it (again) it strikes me
    a) how poor it actually is and
    b) that I’m still impressed that it work and still do.

    Progress is all about learning and understand more. It would scare me more if my code look identical now and for 5-6 years back.

    Kind regards,
    Dennis

  4. Marcus Says:

    Happy to maintain my own work and agree heartily with Dennis’ sentimental reflections on prior work. Sometimes my response is: ‘what was I thinking’ and for others: ‘that’s pretty nifty – I should add that to my library’.

    What you tend to lack maintaining some one else’s work is their modis operandi and the method-behind-the-madness. Usually developers implement a solution or workaround for a (good) reason. As the first thing lacking with most of these solutions is documentation (remember that word?) you have to make a lot of assumptions about how (and more importantly why) things hang together in the way they do.

    While I have done some projects maintaining someone else’s work, I’ve also politely declined work which looked like a minefield. Better if someone else walks through it. These projects usually have political connotations just as much as they have technical ones.

    Regards – Marcus

  5. Jon Peltier Says:

    Whenever I ‘fix’ rather than ‘reconstruct’ a workbook, I regret it later. At least when that workbook is from a client or a very old one of mine. The actual ‘fixing’ is shorter than ‘rebuilding’, but understanding what you’re fixing takes a long time, and ‘fixing’ usually doesn’t provide time to make the original more robust.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s


%d bloggers like this: