Spreadsheets Vs Software 1

[NickF3]

I'm interested to know - if a spreadsheet could perform the same analysis as a software product would you use the spreadsheet or software?

 

[dauwerda]

It would depend on the formatting and how the results are presented.

 

[dik]

I have a personal preference for programs I write... I know what goes into them...

Rather than think climate change and the corona virus as science, think of it as the wrath of God. Feel any better?

-Dik

 

[KootK]

Same answer as dik's, more or less. Assuming both a quality spreadsheet and a quality program:

1) I like the spreadsheet if it was written by me or someone I really trust.

2) I like the program if it's functioning is reasonably transparent and the spreadsheet was written by a rando.

This can, an may, get into some very interesting philosophical arguments regarding reliability and systemic errors. IDS and Denial are great at those aspects of the conversation so you might want to search about for some of their contributions.

 

[BridgeSmith]

Other things being equal (which they rarely are), I would favor the spreadsheet for the greater transparency it would offer, for me, at least. Other people more familiar with programming might find the software more transparent, but it's all a 'black box' to some extent to me.

Rod Smith, P.E., The artist formerly known as HotRod10

 

[dflva]

I would prefer the software product. However for transparency I prefer Mathcad worksheets that I write myself. I've also done a handful of decent C (not C++) programs for more complex problems.
I've never understood why someone who is capable of writing wiz-bang Visual Basic code (btw I'm not) chooses to bury it in a spreadsheet shell. Why not just write a VB program with a nice interface? Put another way, spreadsheets of a complexity requiring coding should just be a program. A complex finance or accounting application that requires VB is justified in a spreadsheet, less so for a structural engineering app.

 

[KootK]

At my VB skill level, it is GUI creation that often steers me towards a VB backed spreadsheet. Excel isn't perfect as a GUI but, if you adapt your problem to what it does natively, that's a pretty fast way to get there. MS Access is a nice, in between solution but, then, usually nobody can use my stuff but me.

As far as software goes, I really do think that there's room in the market somebody who's able to knock transparency out of the park. Heck that's really what my dreamy Kootware project is all about. When it gets right down to the nuts and bolts of that, though, I think that it's quite difficult to make full transparency happen in a way that would satisfy a lot of people. Pretty, easy to work with results are condensed and often graphical in nature. On the other hand, "full transparency" can get pretty close to a text dump of absolutely everything.

 

[dik]

That's why I preferred Delphi for the interface...

Rather than think climate change and the corona virus as science, think of it as the wrath of God. Feel any better?

-Dik

 

[sticksandtriangles]

As Koot alludes too, GUI creation is quite the animal at my amateur coding ability. It's one of the reasons I think that Excel is here to stay.

I enjoy writing code in python, but making GUI's for my code has been the bane of my existence.

I just recently made this GUI in python and it took the better part of 2 months to code (probably working 4-8 hours a week on it).

If I had done this in excel, I think it would have been a lot easier.

S&T

 

[Celt83]

if a spreadsheet could perform the same analysis as a software product would you use the spreadsheet or software?

I want to say spreadsheet but there are so many other factors that would weigh in on that choice.
1. Is the spreadsheet completely locked down such that I can't view the cell formulas or VBA? At this point there isn't much difference than another program beyond the GUI.
2. Is the spreadsheet just a means to collect user input and everything is done in VBA and then returned to answer cells? This would be similar to above
3. Is the spreadsheet devoid of any documentation or references?
4. Is any information hidden, I've worked with countless sheets that had random stuff done off to the side and had "white" font coloring applied to the text to hide it?
5. Is the spreadsheet made without any reliance on macros or custom functions such that it can be used via the web interface?
6. Is the spreadsheet formatted for printing to standard sheet size?
( most if not all of the above apply to the software as well )

"full transparency" can get pretty close to a text dump of absolutely everything

The more I create the more I've come to find most folks who say they want full transparency mean show me Vu=phi*2*sqrt(F'c)*b*d=0.75*2*sqrt(4500)*12*21.375=25.8 kips [EQ. 11-3 - ACI 318-08], but I could care less about the underlying calculus you needed to do to compute Vu or the partitioned form of the global structure stiffness matrix.

My Personal Open Source Structural Applications:

https://github.com/buddyd16/Structural-Engineering

Open Source Structural GitHub Group:

https://github.com/open-struct-engineer

 

[Trenno]

I saw the group you made on LinkedIn. I don't think this thread is similar to the recent trolls on here. Keen to see where this discussion goes, as I'm involved in the development and testing of in-house digital tools.

 

[bones206]

sorry that was a bit of an inside joke.. meant to be lighthearted

 

[skeletron]

Spreadsheets that have enough exposed cells that you can cut&paste the results into your analysis report. I'd rather read someone's analysis thought process, then go through generic print-outs from a program. My situation may be a little different (smaller structures, parts and portions, bounded solutions).

 

[IDS]

I've never understood why someone who is capable of writing wiz-bang Visual Basic code (btw I'm not) chooses to bury it in a spreadsheet shell. Why not just write a VB program with a nice interface?

Because using a spreadsheet as the interface has many advantages over any interface generated directly with a programming language, and also allows you to concentrate on the problem to be solved, rather than coding the interface.

Also it's not an either/or thing. VBA code, or compiled code if you need better performance for maths intensive things, can be combined with on-sheet formulas to give you the best of both worlds.

Doug Jenkins
Interactive Design Services

http://newtonexcelbach.wordpress.com/

 

[Denial]

Obviously developers and users will have different perspectives here.[ ] Furthermore, developers' perspectives will be influenced by whether they are hoping to earn some income from their products or are writing the software only as an intellectual exercise:[ ] a classic, literal, case of the professional versus the amateur.[ ] I speak as an amateur developer, although I was more a user when I was in full-time employment.[ ]

I develop using Excel.[ ] Several reasons:[ ] I have access to it and am familiar with it.[ ] Pretty much all my target audience of engineers have access to it and are familiar with it (or think they are).[ ] I don't have to overly worry about the user interface.[ ] VBA extends Excel's capabilities enormously, albeit clunkily and less transparently.[ ] VBA as a programming language is similar to the language I used most of my professional life, Fortran (what's that cliché about old dogs and new tricks).[ ]

Celt83 in his 10Mar21@21:05 post lists some good considerations that warrant comment.[ ] My comments/views follow, based on my personal philosophy and motivations.[ ] Most will, as Celt83 pointed out, also apply to non-spreadsheet software.[ ]

1.[ ] Spreadsheet completely locked down?[ ] Spreadsheets should be locked down, except for cells that the user needs to be able to change.[ ] Faint colouring should be applied to changeable cells, as a guide to both the user and any checker.[ ] The locking down is done purely to prevent corruption by user error or excessive enthusiasm.[ ] All cells should be fully visible.[ ] The locking down should not be enforced by a password, so the user can unlock at any time.[ ] I like to reimpose the locking (by VBA) when the spreadsheet is reopened after being saved.[ ] The VBA code should be password protected, but with that password publicised in the spreadsheet.[ ] The VBA locking is done so that any errors thrown up by the VBA's execution (which can happen despite the author's best endeavours) do not expose the VBA code to the user.[ ]

2.[ ] Spreadsheet just a means to collect user input and everything is done in VBA?[ ] A developer should avoid using VBA except where there is no alternative.[ ] Usually better speed.[ ] Always better transparency.[ ] But there are lots of things that can only be achieved with VBA assistance.[ ]

3.[ ] Spreadsheet devoid of any documentation or references?[ ] One hopes not.[ ] Better to err on the side of excess.[ ]

4.[ ] Information hidden?[ ] See above.[ ]

5.[ ] Reliance on macros or custom functions?[ ] See above.[ ] See point 11 below for an aspect vaguely relevant to Celt83's comment on spreadsheet use "via the web interface".[ ]

6.[ ] Spreadsheet formatted for printing to standard sheet size?[ ] Ideally.[ ] But sometimes surprisingly difficult to achieve without losing "logical structure".[ ] (I used to overlook this aspect, and am now gradually trying to retrofit good pagination.[ ] To achieve it for both the metric and the imperial universes, page sizes should be limited to A4 width and AQ length.[ ])

Some further comments on spreadsheet design.[ ]

7.[ ] Checks upon the inputs your user enters.[ ] As many as possible, please.[ ] And then some.[ ]

8.[ ] Excessive use of multiple colours.[ ] Try to avoid.[ ] Firstly, the pages might need to withstand being reproduced in monochrome (photocopying or faxing).[ ] Secondly, some colours that look good on a screen or a printed page can become very hard to read on an overhead projector.[ ] Thirdly the visual dog-vomit effect can be a bit overwhelming.[ ]

9.[ ] Version control / revision history.[ ] Essential for a spreadsheet that is likely to have widespread usage, or usage by people totally remote from the author.[ ] Should be built into the spreadsheet, and the version number should form part of the printed output.[ ]

10.[ ] Run date.[ ] This should also form part of the printed output.[ ]

11.[ ] Backwards compatibility.[ ] If your target audience is broad enough you will have no idea what version of Excel they might be using.[ ] Avoid taking advantage of features that appeared only in recent versions.[ ] (I know, I know.[ ] Apply this philosophy too viciously and you end up programming for an abacus.)

12.[ ] Forwards compatibility.[ ] It never hurts to confirm that a spreadsheet you developed on an older version of Excel still runs correctly on the later versions.[ ] (Having said this, I have only once encountered an Excel feature that worked correctly on an old version and incorrectly on a newer one.[ ])

That'll do.[ ] To mangle a pair of clichés, my neck is now nailed to the mast.[ ]

 

[NickF3]

Can you tell us a bit more about what you're up to at:

https://buildupreport.substack.com/p/coming-soon?

Hey Koot

It's new so I haven't focused the direction of the BuildUp but it will be about structural engineering and technology.

My background in both, mostly building in house structural software. Something I found when developing structural software was that I'd spend very long periods heads down trying to build something useful only to find that I had missed something basic right from the start.

After my last project I decided I wasn’t going to make the same mistake again. Having asked around it appears I’m not the only one. So I’m starting the Buildup to try to answer the basic questions around structural engineers and tech so we can waste less time, build better tools and ultimately add more value.



The BuildUp

https://buildupreport.substack.com/p/coming-soon

 

[NickF3]

I saw the group you made on LinkedIn. I don't think this thread is similar to the recent trolls on here. Keen to see where this discussion goes, as I'm involved in the development and testing of in-house digital tools.

Hey Trenno - I wanted to post on eng-tips to get some longer form, more detailed responses. LinkedIn is great, but responses are generally only a few sentences long.

The BuildUp

https://buildupreport.substack.com/p/coming-soon

 

[electricpete]

One factor that would often deter people from program installation is corporate computer security requirements. I can't install anything on my computer but I can load up a spreadsheet including vba unless I jump through hoops with my IT department.

Beyond that, as a user I'm familiar with the excel interface for input and output, and as long as there are good crisp instructions to go with the spreadsheet, then I'd rather have that then some other interface.

There's a lot that can be said on the transparency / readability side and undoubtedly it depends heavily on the style and comments used by the programmer. But I'd say excel and to a lesser extent vba are among the most familiar numerical computing environments for most engineers. In contrast if you give source code for matlab, C++ or python or whatever there's only going to be a smaller fraction that can make sense of it.


=====================================
(2B)+(2B)' ?