7 ms·
That is just scary.
by trapper 18y ago
That is just scary.
- adsyoung 18y agoWell the thing to remember is that everything is checked twice and there's a 1.5 safety factor on top to protect against mistakes but the state of the industry is poor. Engineers often get away with creating monstrous spreadsheets that are difficult to follow: - scattered logic - methodology obsficated with complex excel formulas - magic numbers that you have a hell of a time tracking down the source of - links all over the place. Are they still valid or have they gone bad due to all the copy/pasting? etc etc As a programmer who has to write something that has logic and no ambiguity for a computer to understand it, it makes you want to beat your head against a wall trying to understand and check someones work. Until recently (victim of the downturn) I was in a small dev team looking to automate and improve things. We had some good wins but it's a struggle. If someone like toyota starts making aircraft seriously and develops more standardized methods rather than simply employing piles of engineers to punch numbers wildly into excel they may be able to crush everyone else in time to market.
- gruseom 18y agomagic numbers that you have a hell of a time tracking down the source of - links all over the place. Are they still valid or have they gone bad due to all the copy/pasting? etc etc Would it help to have a sheet of centralized assumptions (constants, magic numbers, etc.) that people could link to from any spreadsheet? Would it help to be able to reuse formulas from another sheet without copy/pasting them? i.e. link in such a way that you can fill in your own numbers, but keep the original logic? Would it help to be able to "lock down" certain models that people could use to do their analysis, but not make arbitrary changes to? Would it help to be able to build some computations in a spreadsheet and wrap them up as a function that other spreadsheets could call (passing in their own arguments)? I'm interested in what can be done to raise the level of abstraction (and consistency) without giving up the spreadsheet UI which is so productive for many users.
- adsyoung 18y agoYes to all of those and that's part of what we try and do. There are also many models/ideas from programming that are applicable to the way engineering should be done I feel, such as don't repeat yourself, reducing dependencies etc There are software tools for analysis developed to standardise what can be standardised and to force people to use templates for their analysis, but they are generally not great and getting them developed is always politically and financially challenging. IMHO engineers find it difficult to identify and extract the common processes because every part is slightly different and complex and usually requires its own judgement calls to be made about how to deal with it. This leads naturally to everyone doing things their own way and therefore using the most flexible and cheap tool there is...Excel. That's not to say there aren't common processes and higher abstractions to be made, it just requires people to look hard for them and think about things in a way that does not come naturally to the industry. They also need to have the clout to get people using them. I think things are changing some what with modern aircraft though. My opinion is that judgement is playing less of a role in many cases and we are moving to brute force analysis i.e. Just throw it at the computer and analyse it all in great detail. This leads to more common processes and standard ways of sharing and moving data around. It's a big problem and I enjoy working on it but the support isn't always there to invest in it. The cost of designing an aircraft is tiny compared to the overall lifecycle of the aircraft and the costs involved in manufacturing. So the industry would generally prefer to keep operating in the same old ways rather than take risks on new things. Especially new things that involve upfront investment. Just my opinion anyway.
- gruseom 18y agoIMHO engineers find it difficult to identify and extract the common processes because every part is slightly different and complex and usually requires its own judgement calls to be made about how to deal with it. This leads naturally to everyone doing things their own way and therefore using the most flexible and cheap tool there is...Excel. This touches on one of my pet theories. Spreadsheets were remarkably successful because they never require you to express a model abstractly (i.e. they never require you to write the formulas up front and plug in data later - which is the way that programming languages work). You're always dealing with concrete numbers. It's example-driven. I believe that this is one of the reasons why the spreadsheet is the computing tool of choice for non-programmers. Good programmers "get" abstraction; most non-programmers don't. The trouble is that when you need to make many variations on the same theme ("every part is slightly different"), the only facility provided by the spreadsheet is copy/paste. Now you can modify Examples 1 thru N to your heart's content, but you've lost any link between the stuff that's common to them all. There's lots of research showing that this kind of spreadsheet development leads to billions of dollars in errors every year. Basically, imagine programming where you have no subroutines and nothing but copy/paste. We know what a mess that would be, the minute you tried to do anything complex. I believe an improvement would be to allow a spreadsheet to clone ranges from another spreadsheet, thus inheriting their data and formulas, but preserving the linkage back to the original. You can override things in the clone to make the parts different that need to be different. But anything that you haven't overridden (or added yourself) is a live copy of the thing you cloned. That means if you change the master, the copies get updated. In fact, you haven't actually copied anything - you're just referring back. The system would be better able to trace the true dependencies of a sheet, and users would still be able to base new work on old examples. Since you've struggled with these issues, I'd like to hear your thoughts.