20 million cells?!
Christ alive, have these people not heard of databases?
Breaking free from Microsoft is harder than it looks. Airbus began migrating its 100,000-plus workforce from Office to Google Workspace more than seven years ago and it still hasn't completed the switch. As we exclusively revealed in March 2018, the aerospace giant told 130,000 employees it was ditching Microsoft's …
I have to import 2000 rows every year into an SQL database. It is a major pain -even as I load the definitions (200 or so) and create a Formula to check. After the formula check, I have to run a program to report the errors - and fix the remaining issues (many!) manually in the original.
Excel, owing to the buggy 1981 version, still considers an "excact match" with spaces between words ("Sri Lanka" vs "SrLanka") and captialization is ignored as well. Even an "s" at the end is considered an exact match "Sea Bream" vs "Sea Breams". As a Mac user, I have to report that Apple's Numbers software replicates the Excel formula bugs faithfully - because otherwise it would not be "compatible" with the "industry standard".
And yet, there are many users who use Microsoft Office on Mac because it is "better".
I can assure you MS Office on a Mac is not better, if you’re used to the Windows edition. Things are in different places and some features are missing. The iPad version is even worse.
You’d have thought that Word should just have the same features and look and feel across all platforms. But then it is a whole GB on a Mac so guess something has to go for a tablet.
I'm not sure if it is still true but I was once told by someone at Microsoft that the way it works is they have a giant Office codebase and they fork off it to create a branch for release on platform x. They might fork for release several years before Office for something unimportant (i.e. not Windows) like iPadOS ships. That's why Office on various platforms never has matching feature sets, and they may also disable various features either to slim it down (or perhaps just to insure that the one running on Windows is the most featureful version)
So while we might want "Office 2025" to be the same on various platforms because it would be the easiest for us, that's not the easiest for Microsoft and they don't care about what we want.
"If they'll ever try to export that data into a database, without typing it by hand of course, they will realize how much of that data it's actually 'gone'"
What will also be gone is your sanity, should you ever attempt to import that crud into a database. I speak from terrible experience.
The biggest problem with using a spreadsheet as a means of data storage is that it lacks any form of verification as to format, sanity or validity of the data, and that the people entering said data are usually underpaid and undertrained office staff with no grasp of the need for standards and consistency in data entry. One person enters it this way, another enters it that way.. There's little or no verification, let alone consistency, at all. Then someone makes a typo that the spreadsheet happily accepts, and a week later someone else misclicks and accidentally drags a few cells from one place overto another without even noticing. Proceed to chaos.
I've been involved in projects that aimed to import that sort of nightmare into a proper database. I seem to remember the spreadsheets in question only ran in the tens of thousands of cells. Most of the data sets needed intensive vetting by eye/hand (which we did, this being a case of either we got it done on time, or the customer's C-suits would be for the chop because of legal issues surrounding data that had to be accessible but wasn't) but it was a [CENSORED] nightmare!! Trust me, it leaves scars on the soul that will never heal.
(But don't worry; I've been in therapy, and as long as I don't forget tot take my meds I'll be fine.)
I have an environment monitor which records temperature, humidity and light level every 5 minutes along with its battery and wi-fi status. I download the csv data weekly into my tracking spreadsheet.
So, 288 data points per day times 2200 days (just over 6 years) = 633,600 times 6 (Date/time, temp, hum, light, battery, wi-fi) = 3,801,600 cells filled.
There are two macros, one to import from the csv file and another to populate various charts with the latest numbers (last 24 hrs, last week, last month and last year).
At 33,268KB it's my largest spreadsheet and will continue for a while yet as there are over 400,000 rows left to fill.
Still nowhere near 20 million cells though. I must try harder!
Skyler: When I input everything into the Quicken, nothing flashed red, so that's gotta mean it's OK, right?
CID Special Agent: Quicken. You used Quicken to manage books for a business this size.
Skyler: I did. Oh, do you guys use that here? Cuz it is THE best. It's like having a calculator on your computer.
No, they probably haven't. But it wouldn't help because they would never be able to do the stuff they're used to doing.
This is where things like Jupyter Notebooks and Pandas are a really helpful way to wean Excel-junkies of their drug. Whilst many functions for data frames are 1:1 versions of SQL aggregate functions, they are easier to work with for the casual user. But the killing argument will be speed: data frames are much, much faster than Excel.
Finance, for example, still relies on Excel because Google Sheets can't handle the necessary file sizes, as some spreadsheets involve 20 million cells
I feel sick
Not surprised though , finance departments steadfastly refuse to keep up with technology and change processes , like the Aerospace industry itself ( but they have good reason) , so a finance dept IN the Aerospace industry .....
I'm surprised theyre off paper
out of the frying pan and into the fire.
MS had all your data. Google has it now... China will have it next week. Their C919 project needs it urgently.
As for those spreadsheets... Sorry but that is a disaster waiting to happen. That is critical data to the company and... shudder... I hope that there are multiple backups of it taken every time a cell is changed.
I don't understand why Airbus would do such a thing. Take Google, add in the U.S. Cloud Act, stir in data outages due to anything from data center power outages to ISP connectivity issues, add in a pinch of questionable cloud security including factors of industrial espionage to criminal blackmail, and finally top with a thick & healthy glaze of always-increasing annual service costs as data volumes increases...
and you get a ticking time clock on a data disaster. It's only a matter of time before one of those events, maybe even several of them or one I didn't even name, happens to them.
Hard to see why they thought that swapping one US behemoth provider for another would be a good idea - though I guess the issue back then was Office licensing costs, rather than more modern concerns like privacy and sovereignty.
Cost reduction is a valid concern with Office apps - but why switch to something cloudy when you can deploy something local which can handle big datasets? Libreoffice ain't perfect, but switching from M$Office to Libreoffice is much less of a culture change than switching from local to cloudy.
I suspect someone showed a beancounter the same Google Sheet on two different screens, added something on one and saw it appear automagically on the other, and decided that this was the one true way. I've done it myself in demos to clients, and the reaction from long-term Excel users scarred by decades of version control nightmares was remarkable.
But it can be depressingly slow…
For better results you need a true clue/multi-user spreadsheet like Grist (it was one among many returned by a \Google search) which can be self-hosted, which might be an important consideration here.
However, a big lock-in to Microsoft is going to be the VBA and macros. For spreadsheets, really need more than just an open document standard, you also need an open macro language and function library standard.
"I wonder if there is any open source collaborative "Word" equivalent, as it is a useful feature."
You are making my back crawl. I'm fine with collaboration, but I'm not keen on working on a document that others can change around at will, in real time. There's application in CAD where one is working on a large project and things need to fit together, but only to a point. If I'm working on a complex pump assembly, I don't want somebody else coming along and changing it to make fitting their bit on easier without talking to me. The reason I bring this example up........
It's only useful until two people change something in totally different places and Wordt tries to reload - it is likely one of the users will lose their edits and can start again.
Microsoft has heard of collaboration, but it's about as good as implementing that as it is in truly opening its file formats.
There was that bit about Airbus being a poster child for Google. Presumably, lending the Airbus name gives Google Workspace credibility, so I assume that Airbus is getting a significant discount on retail. This means that they undercut the Microsoft price by a significant margin.
Factoring in the cost of the migration, cost of training, double work during transition, etc, etc, I wonder if the numbers REALLY stack up?
The fact that it has taken 7 years and still not finished, only proves one thing : Don’t buy into vendor lock-in. On prem or Cloud. And it doesn’t even have to be a hard lock, just an ecosystem and laziness. Once you’ve made your choice, you’re stuck with it.
I've literally never seen this work.
I've only ever seen it half-work for a trivial case, only to quietly break half an hour later.
In my experience the one thing OneDrive is excellent at is bringing the office network down as it tries to sync everything for everyone all at once.
> real-time collaboration with locally installed excel but have to rely on onedrive. I did and worked like a charm
Did the same when the edict came down from on high that NAS storage shares were so yesterday and everything has to go into cloud storage.....which meant SharePoint. I'm retired now but still need my meds for that....
So we used onedrive and shared it between our small group which is what we always wanted.
And that NAS share? it was still them when I left for the last time...
> Google Sheets is a toy compared to Excel. They will never fully switch.
It's not. Yes, it's limited to 10 million cells vs the 20 million of Excel, but it's fully script-able in Google Apps Script (a variant of JavaScript) and other programming languages (and so are all G apps), and of course can connect with external databases such as Postgresql.
It's actually pretty easy to write custom apps this way.
Until google can implement the macro system it's offering is a no-go.
I have lots of spreadsheets that contain complex macros. translating that to a different language is a pile of effort i don't need/want.
Same reason i still use the desktop version of office
This is very interesting to one who worked there on the civil and military sides back in the day around the time the various national companies became one big happy family. At that time regulatory requirements then were that all design information, including CAD files, Word, Excel documents etc. had to be kept for life aircraft series to final flight plus 21 years. So for the A380 project, from 2000 until the last one flies plus 21 years. That could be another 50 years. In the cloud of a company that hasn't existed that long yet?
For Concorde there were paper diagrams dating back to 1954 would only have been disposable back last year as the final flight was in 2003. For A380, even the physical storage format for data was under discussion with CD/DVD and even Vellum print outs being discussed in at least one meeting as physical formats degrade over time. The Vellum thing was a complete no hoper as given the rate of diagram changes in the early days, there just weren’t enough sheep or goats in Europe.
There was a further complication due to the rules at the time. The files had to be displayable as they would at time of creation, so in any investigation no-one would be misled by changes made to either display software or format changes. There is no absolute guarantee that the latest version of excel can faithfully represent data in the same way as it was back in 2000. I can only assume with the change from MS to Google, this has been thought of and thoroughly tested.
I doubt cloud storage will be the only place Airbus is storing their design and certification data, which would be a pretty reckless thing to do. Still, GCP (like Azure) offers government approved cloud services which can handle classified data up to the approved level.
You're also right with Excel and that there is no guarantee that a spreadsheet reads correctly across all incarnations (same as Word files, which often break if opened on different versions of Word form the one the file was saved under).
It's not an issue with G apps. G app documents which show as files on GDrive aren't really files, they are blobs of data in a database (the file representation is only to make it easier for users). Only when the document is exported it becomes a true file.
And because G app documents aren't files, there's no compatibility issue reading older data in newer G apps versions.
There's other fields where long term availability of literally everything related to a product must be kept. Medical devices is one. Cars, probably. Financial records demand long term retention / access too.
It's a problem that the the technology world doesn't care to solve. The "average" user doesn't need this, and so the "average product" doesn't even begin to satisfy such long-lived requirements.
Extending the thought, "displayable as they would at the time of creation": that in itself doesn't make much sense anymore. Sure, there's a strong likelihood that a component's design was looked at (even on a computer screen) by engineers and manufacturing technicians at the time the plane was built. But, for quite a long time now, that is partly irrelevant. It's what the CNC (or 3D printer) actually did with the design that matters, and also what the automated manufacturing QA/QC tools did with it too. Keeping all that automated machinery alive, examinable, usable, testable for decades is even harder.
If regulations aren't asking for that, then they at least need a re-think.
One can go further; what about raw materials; 50 years down the line, can one really get material just as it was?
The Informationeer? A Re-Design Engineer?
There's probably a job for what I'd call an informationeer or a re-design engineer; someone who is specifically trained and qualified in updating the representation of information and can sign off on a conversion from old to new as being "equivalent".
For example, someone who has the tricks up their sleeve to be able to independently assess that a set of CAD drawings converted from one program to another reproduces the original engineer's design intensions cast into the context of modern manufacturing. This would extend beyond just seeing if the file loads, and wouldn't necessarily mean that the part looks the same afterwards... The important part would be that they've signed off the conversion; there is a strong traceabilty between the modern design representation and the original (much as aircraft maintenance logs get signed up by those doing the work).
It feels like a job that's different to the design engineer. A design engineer takes requirements and produces a design. An informationeer simply ensures that the design as cast into more modern representations is the same "design". That would mean that if the design engineer had made a mistake, the informationeer / re-design engineer would correctly carry that mistake forward [though if they detected a mistake, obvs there'd be a means to notify the design owners].
Though I'd hate to be a spreadsheet informationeer. Likely as not, one would find all the horrific mistakes made in the originals, making it difficult to discern what the original intent actually was...
Old Problem
We've been here before. When they (fairly recently) built a Babbage Difference Engine from Babbage's drawings, a major problem was understanding the nomenclature on the drawings; those old Victorian draughtsmen didn't draw things in the way they are in the later 20th / 21st century.
"Though I'd hate to be a spreadsheet informationeer. Likely as not, one would find all the horrific mistakes made in the originals, making it difficult to discern what the original intent actually was..."
In a regulated environment there needs to be that once a spreadsheet gets above a fairly minimum level of complexity it needs to be treated as an initial sketch of a properly constructed system which has a written specification etc.
"It's a problem that the the technology world doesn't care to solve. The "average" user doesn't need this, and so the "average product" doesn't even begin to satisfy such long-lived requirements."
I am coming up to the point where I can shred business documents from the manufacturing company I used to own. The accounting software I still have, but I'd have to dig up an old computer to run it on, hope that the CD's are still readable, etc. I learned early on to just 'ing print stuff out and that saved the bacon on a couple of occasions. Paper and toner were cheap and while it would be a bastard to re-input a year's worth of data into a new system, it could be done. My concern back then was that the accounting software company would go titsup right around tax time and that sort of thing is still a concern except it might also mean that the web-interface, cloudy application would completely cease functioning which is not a valid excuse one can hand the tax board to avoid fines, fees and penalties.
Which is why I still use a 2012 version of my favoured accounting software running (locally) on a Win7 VM.
The only tricky bit was shifting to online VAT submissions. I have to do those via a 2010 version of Excel, because that's the system my accountant provides since our government Made Tax Digital.
Which I believe is where we came in...
Acid free archive paper should be good for hundreds of years. Paper degradation became common in later Victorian times when large amounts of cheap sulfite paper became available for popular books (penny dreadfuls). Many 16th century artwork prints on rag paper by Durer, Cranach, and Baldung are in excellent condition with little degradation.
That's not the biggest problem. All the documentation has numbered sections, subsections, tables, diagrams, etc. It is stipulated it has to be like that. These documents can run to 1000s pages. Ms Word just about copes (I would prefer interleaf).
In Google, all the numbering is done manually. There are no links. It just doesn't.
The Google apps seam like Email from 1980, word and Excel from maybe 1990/2000.
Ah, the mistake you've made is to think of Word as a Publishing Application, which it is not and never has been. It's a Word Processor.
The whole point of a Word Processor is to render words / images as best fits the medium, printer, etc; it's supposed to change word flow with paper size, etc. Take one of the most extreme examples, Latex; You supply it with words, images and rendering instructions, it interprets those instructions in different ways depending on whether it's going to PDF, or printer, or screen, etc. Word is like Latex, except that you have a quasi-wysiwyg view of the rendering as you enter the words, pictures and instructions.
Whereas a Publishing Application is supposed not to do that.
The distinction might seems spurious, but it is a different goal. The boundaries are now very blurred, as are expectations, but that's the origins of Word's behaviour. It's by design. Other WP's do the same.
I've not used Publishing Application since Ventura Publisher; that was (for the day) very good, and no matter what you got the same output on different printers.
That's correct, but users have different expectations. They want their documents to remain readable over time. I've seen a company replace its old PostScript printers with modern PCL ones. Suddenly the Adobe fonts that were available through PostScript were no longer present. Microsoft Word, in its infinite wisdom, decided that in all existing documents the Adobe Courier font was to be substituted by Microsoft Wingdings (https://en.wikipedia.org/wiki/Wingdings). Very awkward if you have a huge store of documents that have to stay immutable for archiving purposes.
Like I said, boundaries and expectations are blurred.
Also, people quite often have unrealistic expectations; they pick up the first handy tool and generally assume that it'll do exactly what they want it to without ever reading up the product manual or any such investigation. Anyone relying on a .doc or .docx being adequate for immutable archival purposes is perhaps asking to be disappointed, despite the spec for .docx being administered by the Library of Congress.
Whereas anyone else relying on a .doc or .docx being infinitely mutable and is therefore willing to put in the font-updating (or at least, embedding fonts) and repagination effort has - so far - not been totally let down; it's still a live, usable format.
Interestingly, the British Library's safest archival format is raw ASCII. It's no good for pictures of course, but they settled on that for text as being the one format that is likely infinitely reinterprettable, just through frequency analysis alone.
Yes, OK, but that was also what Microsoft aggressively used in its effort to get people to pay for updates, and what indeed stopped adoption of alternatives like LibreOffice. "It doesn't look the same" is for the average end user often the sole thing they care about.
Sadly.
Over the years that I have worked with word processors, one rule emerged above all: ANYONE who writes a document longer than one page (and even then too) should be introduced to document styles and its corporate use should be monitored until it becomes habit and culture.
The amount of time that is otherwise wasted on correcting and editing local formatting more than pays for any time training and learning to do it right first time.
Probably a Bill of Materials. Quite a good use for a spreadsheet. These big flying ****ers have a lot of parts, so 20,000,000 cells is no surprise. Having a spreadsheet generated per-aircraft built with a complete BOM for that specific aircraft sounds like a good idea. It would be sound and independent backup for whatever was in the CAD db that existed when the plane was built. It could even be just a CSV file.
I'm an engineer who works on the physical world. I read The Register as I have a passing interest in IT, and it's often amusing
I hate to tell you all, but roughly 90% of the calculations civil, structural and mechanical engineers do involve excel at some point. Even when we do something fancy like FEA or CFD, there's a good chance that we'll postprocess the data in Excel.
A big part of the appeal is that it's built up visually and that you format the output as you go. Programming in something like python is hard for most of us - we don't have the time or inclination to learn it.
I was going to say something similar. I'd add that it's all well and good IT folk decrying the way others use the software (and, in the 40+ years before I retired, I saw plenty of examples where there were better options than those in use) but I doubt neither IT (nor manglement) properly consulted the users before deciding. If you are familiar with working in Excel, and it's doing what you need, it's often folly to switch to something new (even if it's better suited to the task).
And I'd echo the sentiments of those asking how anyone (outside Mountain View's marketing team) would consider the switch from locally managed MS Office to online G-docs a good idea. No software is perfect and it's often safer to stay with what is currently working for you than to move wholesale onto a totally new platform - at least you should already be aware of its significant limitations and bugs.
I'm speaking as someone who worked with such systems rather than on them - the difference being that the outcome was more important than the output (or the route taken - within bounds, of course). An obsession with perfection is often the enemy of adequate.
One of the party tricks someone had for Lotus 1-2-3 back in the day was a full FEA of the structure of a super tanker ship (actually doing the calcs in the spreadsheet too). It was quite good, too, but shockingly impressive at the time.
I'd have assumed that these days, your average professional CAD package such at Catia would just do all the FEA / CFD / visualisation for you. Resorting to Excel sounds, well, old-fashioned! There is the point that not everyone wants to buy Catia or its equivalent, and for a lot of structural stuff it all used to be hand-calculated on paper anyway, so why "over-computerise" the job?
It's one of the frustrating things about Excel - it's good enough for quite a few purposes, and becomes monumentally dangerous when over-used. The line between the two states is invisible, fast moving, and difficult to cross both ways!
Spreadsheet is often pretty good for a first-pass "is this plausible" before trying to do the real thing.
I've prototyped significant pieces of real products in Excel before, including directly controlling the intended physical output to demonstrate that the mathematics did in fact work. Albeit slowly.
It then got used in testing to verify that the real thing did what it was specified to do.
20M cells feels very excessive, though. Must be absolutely horrific to use in practice.
Wow, I am impressed - you actually got it to be used as a prototype ("I've prototyped significant pieces of real products in Excel before").
In my 45+ years as a software developer I never, ever, saw a prototype that wasn't the released protoduct / application.
"For serious work you need a database. "
You need the right tool for the job. Bazza has a good point about BOM's and it really applies to an aircraft "as-built". The only time it changes is as parts are replaced so a spreadsheet can be the best way to do that while a database might be a better choice for A-380's as a family that flows the information into the spreadsheet that will go with each individual aircraft. Something like a snapshot.
It can get very complicated when 'parts' are updated, or entire sub-assemblies replaced. Although Certification can make 'modernisation' undesirable, components can have a common use across multiple products.
Our relatively small, BoMs were maintained by product serial number and a series of 'History Sheets' linked to that unique reference. When products are intended to be in service for a long time, with usual service intervals, the original list can 'soon' become quite obsolete. We were/are plagued by customers who get our products serviced by others whose 'records' are incomplete/non-existent. It becomes our nightmare when something goes wrong; it seems that we are assumed responsible for their actions. I recall being summoned to a meeting with the customer and his service-provider who brought along their tame consultant. After about thirty minutes of abject criticism, I responded by saying: "Why don't you just admit that you cocked it up?" I then asked the customer why he was using this shower at a cost more than we were offering? We did get the next service contracts..... and now we knew what price they were prepared to pay.
"We were/are plagued by customers who get our products serviced by others whose 'records' are incomplete/non-existent."
That can happen. With aircraft, the documentation is hyper-critical. If you find a plane selling really cheap, the reason could be the logs have been lost and it will require a near tear-down and rebuild to get certified to fly again. So, not really a bargain. A CNC mill, anybody can have worked on and not made notes.
I'm not in the aviation industry, but I'd guess that any in-service changes of parts are logged separately (probably on paper, with a signature, kept in a log file back in the hangar). So the current state of the aircraft would be the spreadsheet + all the separately recorded works done. It'd be a piece of work indeed to put that altogether, but having to do so would be a rare event (e.g. there'd been a crash). That way the spreadsheet BOM for the as-built aircraft would be immutable. Having a big spreadsheet that's read-only is a reasonbly good use of a spreadsheet; navigable, importable, searchable, viewable.
Another mistake trying to move to google workspace. It truely is dog shit. I suspect google drive management still relies on GAM (which appeared to be an afterthought by an internal engineer who realised admins had no ability to manage user drives). GAM had a massive security flaw last time I used it. You could steel someone elses setup and run all the admin commands as them with no password challenge.
Google Workspace is fine for 99% of users, but that 1% will regualrly use features that are simply not available in Google Workspace, or the online versions of MS Office for that matter.
File sizes are also a problem, and not just sprawling 20 million cell spreadsheets. After about 50k words, Google Docs becomes incredibly laggy, and that's just plain text. Add formatting and sometimes even a slow typer can be a couple of lines ahead of the screen.
If you want a low cost alternative to MS office, Softmaker Office NX is hard to beat for less than £20 a year per user...
Why would an organization switch from Office to Google Workspace - they are effectively the same thing with the same sorts of problem. I get it that switching to something like LibreOffice woivuld be hard, but switching between Google and Microsoft seems performative more than anything else.
15 years ago. I recall being told that a large retail multiple was an "Oracle" shop by a senior IT manager. However the "Finance" shared drive hosted 430,000 Excel files taking 730GB of disk.
There was a desire to trim this - in theory only as a lack of resource or bottle made it a hill no one wanted to climb.
I assume the only reason Airbus wanted to move to a cloud-based system was because of their multinational cooperation foundation. Probably for some understandable reasons, coordinating between France, Germany, and all the other partner countries and their suppliers and contractors means an incredible amount of bureaucracy, teams spread across different timezones and languages, and customers that have to interface with an engineer in France for one thing, a representative from Spain for another, and a sub-manufacturer in England for a third.
If they wanted to get away from Microsoft, mainly because their cloud solutions are lacking, then the only other alternative is Google despite their limitations in Google Docs, Sheets, etc. There's just no suitable European alternative because there's no giant tech company that operates on the same scale and offers similar products in Europe as any of the FAANG or MAG7 companies. If there is a smaller competitor, I just doubt they have the resources and infrastructure in place to adequately provide for the needs of a company the size of Airbus.