News Formula 1 management shocked team used Excel for 20,000-part inventory, now replacing 'impossible to navigate' sheet

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
I think the entire F1 league (and obviously others) could benefit from a structured configuration management program/product ran by an expert who knows how to ETL this stuff into a datalake.
 
1996 : some poor schmuck was tasked with keeping a list of spare parts from an old stack of paper files, then some content was added, then dependencies were bolted onto it, then another inherited it and tried to ad some more stuff on it with macros, then another inherited it and used it for another purpose, then someone else added some more dependencies...
Some people use Excel as a programming environment : formatting, data storage, forms, etc. all packed into one with no consideration at ALL for the principles of Model-View-Controller development, inherited by incompetents (they have another job to do) for DECADES, giving you a completely impossible to understand blob of data, macros and formatting with mistakes all over the place that will take WEEKS to make sense of.
Once you've understood what it's for, then you must model a new software from the ground up and enter the data piece by piece, and then REMOVE all the fixes used by whatever was connecting to the Excel blob that dealt with its idiosyncrasies before you can switch to said proper software.
And that can't be done by a wet behind the ears intern, you need a good analyst and a good software developer, along with a good project manager to follow all of that - that's a $3000 a day job, stretched over 2-3 months at BEST : here, $300 000.
That's what one calls technical debt - had the job been done properly (basic database, a few forms, some script in Perl or Pascal/Delphi or Java) in 1996 when that spreadsheet was created, you could have cut a zero or 2 out of that cost : of course you would have had to reprogram a great deal of it to port it to a modern language, you would have to redraw the views etc. but any programmer worth his/her salt can do that in a few days, the data would have to be migrated to match the new data object model, but at least it would be CONSISTENT ! you usually get a test version in under a WEEK and can do regression testing over a couple more weeks, but you've already saved more than a couple months in debugging time and regression testing more than likely doesn't have to cover as many shims and quirks.
Been there, done that, got the T-shirt.
 
  • Like
Reactions: Chips4all
Excel can do a lot for a small team and it can function like a database. It’s very flexible and can be used with integrations etc. But for a high performance organizations that’s looking for every competitive advantage, it does seem pretty bush league. Could it be that it worked well enough and they just felt the money needed to go into other projects that helped them compete on the track? Likely. How critical is this parts inventory list to how well the team actually runs? Sounds more like a cost management deal. Every new leader does this sort of thing… rolls into a company, finds a few low hanging fruit to hold up as quick wins, tries to show they are quickly making decisive moves to rapidly improve performance. This sounds like just that. You find odd pockets of tech debt like this in every organization to be fair.
 
An F1 team is much more than "small".

And they do have a very large budget.

SQLServer, or even MS Access, would have been much better.
And not cost much more, if anything.

People start with Excel, because it puts everything in nice neat rows and columns.

But very quickly run past its capabilities as a database.

As said, I've seen this exact scenario many times.
Oh...so, so many times .... especially in 80's - 20xx in manufacturing.... 45+ year career...LOL fun! ☺️
Another level --- when the data is then shared and data flows+ manipulation by scripts vs programmed modules against hybrid clouds need to be integrated into operations. LOL fun! ☺️
 
1996 : some poor schmuck was tasked with keeping a list of spare parts from an old stack of paper files, then some content was added, then dependencies were bolted onto it, then another inherited it and tried to ad some more stuff on it with macros, then another inherited it and used it for another purpose, then someone else added some more dependencies...
Some people use Excel as a programming environment : formatting, data storage, forms, etc. all packed into one with no consideration at ALL for the principles of Model-View-Controller development, inherited by incompetents (they have another job to do) for DECADES, giving you a completely impossible to understand blob of data, macros and formatting with mistakes all over the place that will take WEEKS to make sense of.
Once you've understood what it's for, then you must model a new software from the ground up and enter the data piece by piece, and then REMOVE all the fixes used by whatever was connecting to the Excel blob that dealt with its idiosyncrasies before you can switch to said proper software.
And that can't be done by a wet behind the ears intern, you need a good analyst and a good software developer, along with a good project manager to follow all of that - that's a $3000 a day job, stretched over 2-3 months at BEST : here, $300 000.
That's what one calls technical debt - had the job been done properly (basic database, a few forms, some script in Perl or Pascal/Delphi or Java) in 1996 when that spreadsheet was created, you could have cut a zero or 2 out of that cost : of course you would have had to reprogram a great deal of it to port it to a modern language, you would have to redraw the views etc. but any programmer worth his/her salt can do that in a few days, the data would have to be migrated to match the new data object model, but at least it would be CONSISTENT ! you usually get a test version in under a WEEK and can do regression testing over a couple more weeks, but you've already saved more than a couple months in debugging time and regression testing more than likely doesn't have to cover as many shims and quirks.
Been there, done that, got the T-shirt.
Yep LOL fun! ☺️. 45 year career -- have T-shirts from manufacturing floors & logoed polo shirts from the cubes .... Yeppers...I worked with the guys who did the excel macros + the original Oracle designers on the initial data models in exactly the time period, mid-80's - 2000 you've identified. After that much more rational oo event- driven data manipulation!
 
Last edited:
Obviously any database should be properly "normalized". That has nothing to do with Excel.
A database is a set of tables (Excel tabs). So, Excel is good at that.
Each data element needs to be defined (Excel, Data, Data Validation)
The relationships between data elements needs to be defined (Excel, Index, Match)
You need to create Excel, Forms to make data entry clear and pre-defined
Having many individuals update Excel simultaneously is usually solved by normalizing the tables within the groups of people updating them.
In 1984, I setup a Lotus 1-2-3 database for a division in a large corporation to perform annual budgeting. Given the technology available at the time, I had to create separate, normalized spreadsheets for individual departments.
I love it!!!!
"Given the technology available at the time..." is exactly the issue with people simply declaring "excel is not a database". In the 80's I had an engagement to audit expenses for a new budget --- kept in excel --- so a lot of modules written for reconciliation that was embedded in either c- modules of a dbase system or some excel macros for pre-processing for the division manager's staffs. Also a process manual, audit procedure to port the modules to a new TBD db ... gave hints for Oracle port.
😊 Fun
 
I remember about 20 years ago, I was brought into project the server infrastructure cost for this huge SAP financial system project for a multinational corporation. I sat in on meetings about financial reports which had something like $20 million budget. I talked them into scrapping the project and just creating a system for selecting and summarizing data to be downloaded into Excel. The consulting company hired to work on the project was SO angry and the accountants were so happy.

Anyway, a properly designed database is a set of relational tables (Excel tabs) that have been "normalized".
If you don't think Excel can be a database - then you do not know what you are talking about.
Issues involving high-performance transactional capture (e.g. airline reservation system) obviously something that Excel can't provide.
SAP is such an expensive beast to use and evolve. Yep....extracting data for a report in excel especially for some accounting work or an audit type engagement is standard for most accounting firms.

You have avoided the accusation of "excel is not a database". ... but it can be an easy to use and well-known report tool 👍🏼😳