Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Software IT

Formula 1 Chief Appalled To Find Team Using Excel To Manage 20,000 Car Parts (arstechnica.com) 187

An anonymous reader quotes a report from Ars Technica: Starting in early 2023, Williams team principal James Vowles and chief technical officer Pat Fry started reworking the F1 team's systems for designing and building its car. It would be painful, but the pain would keep the team from falling even further behind. As they started figuring out new processes and systems, they encountered what they considered a core issue: Microsoft Excel. The Williams car build workbook, with roughly 20,000 individual parts, was "a joke," Vowles recently told The Race. "Impossible to navigate and impossible to update." This colossal Excel file lacked information on how much each of those parts cost and the time it took to produce them, along with whether the parts were already on order. Prioritizing one car section over another, from manufacture through inspection, was impossible, Vowles suggested.

"When you start tracking now hundreds of thousands of components through your organization moving around, an Excel spreadsheet is useless," Vowles told The Race. Because of the multiple states each part could be in -- ordered, backordered, inspected, returned -- humans are often left to work out the details. "And once you start putting that level of complexity in, which is where modern Formula 1 is, the Excel spreadsheet falls over, and humans fall over. And that's exactly where we are." The consequences of this row/column chaos, and the resulting hiccups, were many. Williams missed early pre-season testing in 2019. Workers sometimes had to physically search the team's factory for parts. The wrong parts got priority, other parts came late, and some piled up. And yet transitioning to a modern tracking system was "viciously expensive," Fry told The Race, and making up for the painful process required "humans pushing themselves to the absolute limits and breaking."

The idea that a modern Formula 1 team, building some of the most fantastically advanced and efficient machines on Earth, would be using Excel to build those machines might strike you as odd. F1 cars cost an estimated $12-$16 million each, with resource cap of about $145 million. But none of this really matters, and it actually makes sense, if you've ever worked IT at nearly any decent-sized organization. Then again, it's not even uncommon in Formula 1. When Sebastian Anthony embedded with the Renault team, he reported back for Ars in 2017 that Renault Sport Formula One's Excel design and build spreadsheet was 77,000 lines long -- more than three times as large as the Williams setup that spurred an internal revolution in 2023.

Every F1 team has its own software setup, Anthony wrote, but they have to integrate with a lot of other systems: Computational Fluid Dynamics (CFD) and wind tunnel results, rapid prototyping and manufacturing, and inventory. This leaves F1 teams "susceptible to the plague of legacy software," Anthony wrote, though he noted that Renault had moved on to a more dynamic cloud-based system that year. (Renault was also "a big Microsoft shop" in other areas, like email and file sharing, at the time.) One year prior to Anthony's excavation, Adam Banks wrote for Ars about the benefits of adopting cloud-based tools for enterprise resource planning (ERP). You adopt a cloud-based business management software to go "Beyond Excel." "If PowerPoint is the universal language businesses use to talk to one another, their internal monologue is Excel," Banks wrote. The issue is that all the systems and processes a business touches are complex and generate all kinds of data, but Excel is totally cool with taking in all of it. Or at least 1,048,576 rows of it. Banks cited Tim Worstall's 2013 contention that Excel could be "the most dangerous software on the planet." Back then, international investment bankers were found manually copying and pasting Excel between Excel sheets to do their work, and it raised alarm.

This discussion has been archived. No new comments can be posted.

Formula 1 Chief Appalled To Find Team Using Excel To Manage 20,000 Car Parts

Comments Filter:
  • Numb3rs (Score:5, Funny)

    by bugs2squash ( 1132591 ) on Wednesday March 20, 2024 @10:38PM (#64332517)
    Don't tell me, they migrated to Numbers or Calc or Lotus123
    • Nah, they'll probably start the transition over to PPT & MS Paint ASAP. PPT's ideal for organising large, complex datasets into interconnected representations.
      • Nah, they'll probably start the transition over to PPT & MS Paint ASAP. PPT's ideal for organising large, complex datasets into interconnected representations.

        Funny you should mention that. I noted in a post above, some guy brought in a huge PowerPoint into our department asking if we could "fix it up". It was a service manual he put together for his deliverable.

        In PowerPoint.

        Problem was he sucked the project dry putting it together, and wasn't happy that the entire thing had to be redone. That interconnection thing yaknow - in a program that doesn't do basic indexing.

    • by maxrate ( 886773 )
      You forgot Google Sheets
  • Seriously? (Score:5, Insightful)

    by Baron_Yam ( 643147 ) on Wednesday March 20, 2024 @10:42PM (#64332521)

    That's almost a trivial task to handle with a free database server and a web front end. A single tech geek with some SQL and web experience could do it - and you're not even talking intermediate level.

    I know, because something similar was the first thing I ever did when learning database administration. I can't imagine it's gotten MORE difficult in the last 20 years.

    • Re:Seriously? (Score:5, Insightful)

      by fuzzyfuzzyfungus ( 1223518 ) on Wednesday March 20, 2024 @11:02PM (#64332543) Journal
      ERP systems typically don't fail because of their databases or frontends(and, when they do, they tend to be big, huge, must-talk-to-all-the-legacy-systems-and-support-analysis-and-reporting-at-nontrivial-scale situations that isn't a trivial matter to handle with just some basic web experience). They fail because the process of capturing(and where necessary taking a hard look at and changing) all the business processes so that the dev side can implement them or make sure that they are handled by the product they've chosen is ugly and complex.

      Similarly; nobody picks excel because of confusion about its power and capabilities: overwrought-but-inadequate excel is what happens when there is no effort, or no successful one, to get business practices codified into requirements that can be shoved over to the devs and implemented; so you get ad-hoc development of local bandaid tools; typically bolted together by a fair amount of manual copy-paste and futzing; implemented in whatever the people who are familiar with the processes are familiar with. Not uncommonly excel ends up being that; as it's at a pretty favorable intersection between "power" and "number of basically nontechnical users at least partially qualified to work with it".
      • Similarly; nobody picks excel because of confusion about its power and capabilities: overwrought-but-inadequate excel is what happens when there is no effort, or no successful one, to get business practices codified into requirements

        It's called "tribal knowledge" and it's hard to convince people it exists and even harder to capture accurately.

    • Re:Seriously? (Score:5, Interesting)

      by bugs2squash ( 1132591 ) on Wednesday March 20, 2024 @11:09PM (#64332545)

      This is done in excel because no-one trusts the single tech geek - so they pay huge sums to a major RDBMS vendor who fleeces them and locks them into an inflexible slow system that is worse than the spreadsheet.

      moral of the story - support your local geek

      Actually, with all the CS education in schools you would think that any average Joe could put together something functional if only to keep the data "clean", it's not just F1, I hear similar stories from many nonprofits maintaining their donor lists for example, turns out even simple queries are just too much

      • Re:Seriously? (Score:5, Insightful)

        by evil_aaronm ( 671521 ) on Wednesday March 20, 2024 @11:54PM (#64332597)
        It's likely less nefarious than this. No one starts a race team with IT needs at the forefront of their planning. So some wrench monkey gets tagged - or gets sick of the chaos and volunteers - to keep track of "all this shit," and the least common denominator, Excel, gets pressed into service to fill a badly defined need because that's what they know, and they're not getting paid to be an IT guy. Things spiral from there.
      • Re: Seriously? (Score:5, Informative)

        by SuperDre ( 982372 ) on Thursday March 21, 2024 @05:53AM (#64332955) Homepage
        And what if that one IT-geek goes off, or dies? Then you must have a backup person, also let's not forget the infrastructure needed for a real database/webfront application vs just an excelsheet. Even in our IT company, a developer wrote some backoffice services, but never actually transfered the knowledge to others, and now we have to fully replace it because none of us knows how to update or maintain the system (at least not with confidence or time needed to do it).
        • This particular case isn't rocket science. It's extremely basic. If your original geek gets hit by a bus, you hire another.

          As long as you didn't have some asshole who deliberately obfuscated things or refused to document, or maliciously locked everything up and didn't share the passwords, you're fine.

          • I interviewed with Williams for a software position about 15 years ago and they seemed to know their CFD stuff but needed someone to help link things together. They decided to go with the other candidate. I've always been sad that I didn't get that one, and I'm doubly sad now.

        • Re: Seriously? (Score:4, Insightful)

          by bungo ( 50628 ) on Thursday March 21, 2024 @06:22AM (#64332993)

          Pity I don't have mod points, this is insightful.

          I've seen many times that a previous techie built a custom support system (to maintain servers, ERP systems, development rollouts, patching systems, etc...) and once that person was gone, the whole thing was ripped out by the next person or I've been told to replace it.

          This is usually because the previous techie didn't produce much for documentation and didn't pass on their knowledge. I've seen where the knowledge was not passed on, on purpose, in a misguided attempt to have job security.

          This is why larger enterprises go for expensive solutions and need a lot of convincing to use and open source tool, even when the open source tool is better suited.

          • I'm not sure that the excel sheet is any better documented.

            Maybe excel should just add easier-to-use features to support field type enforcement. That seems to me to be the only real drawback of the spreadsheets, that they let people type in any old garbage and then wonder why they can't use it as a clean source for mail merge or export it to some other sensible program to run queries. There's not much intrinsically wrong with using a spreadsheet to hold tabular data otherwise.

            .

      • Actually, with all the CS education in schools you would think that any average Joe could put together something functional if only to keep the data "clean"

        A little bit of knowledge is dangerous. The average Joe can make a database. Can they document it in a way that after they leave it is possible for the average Jane replacing them to maintain it or modify it as requirements change?

        Excel has this problem too as soon as people hit Alt+F11.

      • The industry lacks a de-facto standard tool/stack for smaller-volume code-friendly CRUD that doesn't have too many layers (wannabe web scale). And DOM sucks the big one for CRUD use. [reddit.com]

        MS-Access kind of filled this need, but MS is not porting it for web and hinting at deprecation. MS is chasing "enterprise" and "web-scale" while small-end is getting shafted. PowerTools/Apps doesn't have a code option like MS-Access does.

        • Drupal is a great answer. It makes it fast and easy to develop tools like this, and you get to pick your RDBMS as long as you are happy picking MariaDB or Postgres. There is support for other databases but it is not very good, although I do believe there is a push to improve sqlite support going on now. However if you need to interact with other databases in a way that does NOT involve the Drupal DB stored in one of them, you can do that pretty easily with the Views Database Connector module.

    • Yeah, no. You either want a solid enterprise-grade system, or something that's accessible and fully transparent to non-technical users (like a spreadsheet). Some cobbled-together database by someone's nephew who "knows computers" is neither.

      • You either want a solid enterprise-grade system,

        like Postgres,

        or something that's accessible and fully transparent to non-technical users

        like Postgres.

        Some cobbled-together database by someone's nephew who "knows computers" is

        Excel spreadsheets.

        • by jcdr ( 178250 )

          Exactly. I nerver understand why postgres is not more popular. I use postgres based ERPs or with data visualization tool, or directly with libpq, since two decades now and it's proved an absolutely rock solid reliability and super good performances on complex queries when proper index and keys are in place. With postgres I managed dataset by far exceeding multiple times the scale of this F1 team, on multiple projects.

          • ...With postgres I managed dataset by far exceeding multiple times the scale of this F1 team....

            We use Postgres for years with resounding success on some fairly large datasets, and it works great. I have many complex queries on multiple tables that each contain over 121M rows, and most of those queries run in a small handful of milliseconds. I have a few of those queries that take several minutes to run, but they are monthly or yearly reports. The day-to-day transactional queries are very fast.

            I also rewrote the operational software for a small, multimillion dollar local company (they outgrew their o

    • A single tech geek with some SQL and web experience could do it

      It's precisely that attitude that causes you to build horrible inflexible databases which don't meet user requirements, and can't expand and grow with the business leading someone to say "If we export this into excel we can manage the data more easiliy".

      Building a database is trivial. But if you're not having 6 months of meetings and carefully analysing customer usage and requirements your single tech geek is going to produce absolute garbage.

      • Building a database is trivial.

        Most people do that in Excel.

        Even though plain text files are simpler, faster, and easier to maintain.

        But if you're not having 6 months of meetings and carefully analysing customer usage and requirements your single tech geek is going to produce

        an Excel spreadsheet, like the one TFA is talking about.

        • Building a database is trivial.

          Most people do that in Excel.

          Even though plain text files are simpler, faster, and easier to maintain.

          Well there ya go, Excel being a spreadsheet, that is not a database that solution fails instantly.

          For people who wanted an off the shelf solution, I have put together Filemaker Pro Database systems. Not perfect, but everything they needed is accessible, and since different people want to look at different things, everyone can have their own layout.

          All that said, a person or two has to know a little something about relational databases. But if a programmer doesn't document and quits suddenly, going ba

    • But that requires a developer who maintains the server, website, software and database, and especially these days, security. A lot more non techies know how to use excel, and I'll bet it started out with a simple excelsheet, which grew over time. Inreality, it is perfectly possible to do what is needed (and missing) with excel. Excel is much easier to maintain as a whole online database application. Ofcourse it would be better to actually create a whole cloud-based application for this NOW, but as I said, t
    • Re:Seriously? (Score:4, Informative)

      by jenningsthecat ( 1525947 ) on Thursday March 21, 2024 @06:35AM (#64333015)

      ... A single tech geek with some SQL and web experience could do it - and you're not even talking intermediate level.

      Came to say pretty much this, in response to "You adopt a cloud-based business management software to go 'Beyond Excel.'".

      Why does it have to be "cloud based"? Are they magic clouds? The tasks and workflows described could easily have been handled 20 years ago on then-current hardware running SQL. And if there's any integration between the design software that they're using and the database, wouldn't that be better done on-premises?

    • The problem is when they need to integrate into design and manufacturing systems and processes, and likely accounting. Your glue is very sensitive.

  • by kenh ( 9056 ) on Wednesday March 20, 2024 @10:43PM (#64332523) Homepage Journal

    As they started figuring out new processes and systems, they encountered what they considered a core issue: Microsoft Excel. The Williams car build workbook, with roughly 20,000 individual parts, was "a joke," Vowles recently told The Race. "Impossible to navigate and impossible to update." This colossal Excel file lacked information on how much each of those parts cost and the time it took to produce them, along with whether the parts were already on order.

    The issue is that the race team employed a spreadsheet that was inadequate for their needs. The worksheet could have tracked all the datapoints they lacked, it's just that no one added those columns or felt the need to update spreadsheet.

    That said, using an Excel spreadsheet as a database is a bad idea, but the deficiencies of the spreadsheet points to the designers of the spreadsheets, not Excel itself. (MS doesn't sell Excel as a turn-key race team inventory management system.)

    If the solution was instead a custom application implemented in C, would we blame the C language or the programmer?

    • by OrangeTide ( 124937 ) on Thursday March 21, 2024 @03:00AM (#64332765) Homepage Journal

      Yeah the whole thing doesn't smell right to me. 20k rows in a spreadsheet isn't a big deal these days. And I track shipping and receiving orders. So I know what has been ordered, when it was ordered, when it was shipped to me, and when I received it. Both the order price and shipping charge are tracking so I get a sense of the value of my held inventory, my inflight inventory, and the amount spent on shipping. With a little extra work these can be turned into a monthly report on another worksheet.

      Would a customized app with SQL backend perform better? Of course, especially if you have multiple people entering data. But if your shipping department is just one dude, then you probably can handle it this way for a very long time without Excel being the bottleneck.

      People used to be able to organize physical paper receipts in a way that you could run a productive business. (Actually people used to be able to do this on clay tablets). But you also had business back in the day that used filing cabinets as a place to stack paperwork that nobody ever visited. Rather than the intended purpose of an organized reference. Adding computers and spreadsheets and databases doesn't suddenly solve a deficiency in humans unable to make proper use of available tools.

      • 1k rows is where most Excel stuff starts breaking. Especially when you get to calculations, filters and pivot tables, you regularly run into issues where stuff just isnâ(TM)t calculating anymore properly because a filter has been set or reset or a pivot table runs into another one and silently refuses to update. Multi-user 20k rows is untenable.

        • by cmseagle ( 1195671 ) on Thursday March 21, 2024 @06:12AM (#64332983)
          Neither of the issues you mention (filters, clashing pivots) have anything to do with whether your spreadsheet has 1k rows or 100k rows. I regularly manipulate spreadsheets with 100k+ rows without an issue.
          • Same. I have many workbooks with more than 10K rows feeding multiple pivot tables and they work really well. The problem is likely not the software but the implementation. Managing performance is straightforward: let Excel do most of the heavy lifting since it's always going to be faster than what you do in VBA, use memory judiciously (INDEX/MATCH instead of xLOOKUP), minimize formatting to keep things simple. Above all, have a database person look over your work before you publish if you're not that person

      • by MeNeXT ( 200840 )

        A simple small business accounting app would handle this better than excel and will/can offer other benefits such as the financial operations of the whole organization, builds, taxes, history audit trails........

        If you don't believe me look at Money Works or Quickbooks.

        • A simple small business accounting app would handle this better than excel and will/can offer other benefits such as the financial operations of the whole organization, builds, taxes, history audit trails........

          If you don't believe me look at Money Works or Quickbooks.

          Or Filemaker Pro. I've built apps for people who don't want to hire developers and programmers that do everything wanted, allow for customized personal layouts, Like if doing it in this case, there can be layouts for people who want to identify parts, for costs, for each users case.

          I could even design something that looks like Excel although that would likely lead to problems. But yes, there are good solutions to this issue, and none are Excel.

    • I manage a multi $100m line of business entirely with a series of excel workbooks. I was shocked when I first started using it, but it works just fine, and 20k rows is nothing.
    • I was thinking the same. I'm a scientist that would never analyze large datasets in Excel because that's not what it's made for. But it does have a lot of capability, especially for financial analysis, and is quite convenient for quick calculations (for my work, at least).

      I'd like to see the history of this excel workbook. I bet this started a very long time ago as a small-ish workbook when they realized they needed to transition away from paper, and excel was easy to implement. There are many many examples

    • If the solution was instead a custom application implemented in C, would we blame the C language or the programmer?

      As long as they were delivered what they asked for, then it is management's responsibility. Management is entirely to blame. The language is just a tool and the developer develops what is asked for.

    • by burni2 ( 1643061 )

      From my pov, you are correct, but I would precise the RCA a bit more,
      this team has not thought about how they are organized and who does things (translate:processes),

      so basically when they don't do that, or don't find a consultant that puts them straight, they are inbound for disaster with any program not just Excel.

      No program will solve your problems, when you don't get to know your problems first.

  • by Brett Buck ( 811747 ) on Wednesday March 20, 2024 @10:47PM (#64332529)

    Formula 1 cars are fiendishly complex and the design extremely exactling. The idea that you could keep track of the parts or do extensive design work using something like Excel is *utterly nuts*, it's like doing the real-time orbit determination for Apollo using an abacus and a wood stick in the dirt.

        The Williams team has an amazing history of innovation and was at one point in the late 80's/early 90s the dominant team, leading one of their drivers to say "you could put a retarded ape in one of these cars and win the championship". They have been operating in a shoestring (or Formula 1) budget for years, with little success, and have recently been bought out from the founding owners - the late Sir Frank Williams, and his daughter Claire - and all this was discovered when the new owners hired other Formula 1 management.

    • by ISayWeOnlyToBePolite ( 721679 ) on Wednesday March 20, 2024 @11:37PM (#64332571)

      it's like doing the real-time orbit determination for Apollo using an abacus and a wood stick in the dirt.

      As I understand it, for early Apollo missions it was completely hand calculated https://en.wikipedia.org/wiki/... [wikipedia.org]

    • "you could put a retarded ape in one of these cars and win the championship".

      Sounds like a challenging sport.

    • by Cochonou ( 576531 ) on Thursday March 21, 2024 @03:05AM (#64332769) Homepage
      I do not think it is so bad actually. When you need a lot of flexibility, fast turnarounds and have small production volumes, you will find that big ERP systems are often not really suited for the job. I actually work in the space industry. We manage those kind of part lists in heavyweight PLM and ERP software, but it is mainly because they bring a lot of security, traceability and reliability during production. But during the engineering and development phases, we use that kind of giant excel tools coupled to internal databases to manage the fast evolving part list. It tracks the costs and lead times quite well. The main advantage of Excel (or any other spreadsheet software) is that any user with a need can be a developer and improve the tool. The drawback is that any user can break the tool if he is not cautious. In practice this has not caused significant issues if version control is implemented. When the development winds down and the production phase begins, everything is automatically exported to the heavyweight PLM and ERP tools, with limited amount of data massage required. So in the frame of an F1 team in which everything is moving fast, I can see them using such tools, even if it seems the one used at Williams was inadequate. More sophisticated tools are not necessarily better : Renault Alpine F1 might be big ERP cloud users, however I cannot help but notice that their current F1 performance is terrible. Of course correlation is not causationâ¦
    • The idea that you could keep track of the parts or do extensive design work using something like Excel is *utterly nuts*

      Excel is nothing more than a list with items separated into columns. The fact that there's a lot of parts doesn't make the tool any more nuts. The question is not one of "keeping track", the question is *what are you trying to achieve*.

      it's like doing the real-time orbit determination for Apollo using an abacus and a wood stick in the dirt.

      It's nothing like that because ERP systems do not require the use of complex calculations (or even simple calculations, orbital determination isn't rocket science. ... well.... yes it is, but it's not brain surgery, it's the course we all took at university for an easy A). It

    • Formula 1 cars are fiendishly complex and the design extremely exactling. The idea that you could keep track of the parts or do extensive design work using something like Excel is *utterly nuts*, it's like doing the real-time orbit determination for Apollo using an abacus and a wood stick in the dirt.

      Or Excel.

    • it's like doing the real-time orbit determination for Apollo using an abacus and a wood stick in the dirt.

      Umm... didn't they use sliderulers rather than an abacus? I am pretty sure they used chalkboards rather than the dirt.

      Are you certain that was the example you wanted to use? :)

  • It could have been worse, they could have been using Siemens Teamcenter.
  • by Valgrus Thunderaxe ( 8769977 ) on Wednesday March 20, 2024 @11:35PM (#64332567)
    Access is the way to go.
  • by christoban ( 3028573 ) on Thursday March 21, 2024 @12:23AM (#64332627)

    This is exactly what Access is for. And it's part of Microsoft Office.

    No need to make a web site, not for something this trivial.

  • by sonoronos ( 610381 ) on Thursday March 21, 2024 @12:55AM (#64332645)

    The number of lines for an excel spreadsheet mentioned in the article sounds pretty pedestrian for anyone who has worked in any corporate job in the last 15 years. Spreadsheets of this size are commonly used for a number of mundane tasks.

    This reads like some kind of anti-microsoft drivel written by someone who is oblivious to how people actually do work in companies.

    The only thing I learned by reading this article is that the number of parts being tracked by formula one teams is way larger than I expected. But compared to the average corporate spreadsheet? The amount of lines is trivial.

    • by TRRosen ( 720617 ) on Thursday March 21, 2024 @01:36AM (#64332697)

      It's not a damn database. It's the absolutely wrong tool for the job. it has nothing to do with capacity. a pipe wrench is strong enough to tighten your lug nuts, that does not make not appropriate.

      • by thegarbz ( 1787294 ) on Thursday March 21, 2024 @07:44AM (#64333179)

        It's not a damn database. It's the absolutely wrong tool for the job.

        It may not need to be. You're quick to throw the word database at a recording problem without understanding the nature of the record. For a 2 dimensional data problem a simple table is not only more than adequate for the job (regardless of the number of entries), but it may actually be better performing (in terms of quick results for a user) than throwing a database at it. Not every data problem requires a database.

        a pipe wrench is strong enough to tighten your lug nuts, that does not make not appropriate.

        You use a different cutting tool for cutting down one bush in your yard vs razing an entire forest to the ground. A database is important for complex scaling problems. You say excel isn't suitable, yet not only has this F1 team functioned with it so far, others clearly have as well.

        I think the world would be a better place if everyone who uses the word "database" before using the words "customer requirements analysis" just leaves the IT industry.

      • What? Of COURSE it's a database. It's not a relational database. It's not a good database. But it absolutely is one.

        Excel can handle hundreds of thousands of rows, but only poorly and slowly. At least it will do it, though, unlike LO Calc or frankly most spreadsheets. A more likely place they failed is in writing functions and/or macros.

        If performance matters then they would have been better off using a RDBMS with an application in front of it. There are probably systems like this available for similar purp

    • This reads like some kind of anti-microsoft drivel written by someone who is oblivious to how people actually do work in companies.

      Not anti-Microsoft, but rather it sounds like standard buzzword computing. The hint is right there in the summary "cloud based business management software". This guy is ringing all the alarm bells.

    • by ledow ( 319597 )

      Just because "other companies" do it doesn't mean it's the right thing to do.

      Just because "it can be done that way" doesn't mean it's the best way to do it.

      Just because "Excel can do the job" doesn't mean you should be using Excel, that your first thought should be Excel or that another tool wouldn't be more suitable.

      Just because "The team's been doing it that way for ages" doesn't mean that someone - for instance a guy coming from another successful Formula 1 team who don't do it that way - can't improve t

  • No, let's do a full-blown ms dynamics implementation so we can follow where exactly in the supply chain our 4 top wishbones are! Or sap, let's do sap!

  • Facepalm (Score:4, Insightful)

    by TRRosen ( 720617 ) on Thursday March 21, 2024 @01:31AM (#64332693)

    Excel is not a database. do not use it as one.
    It is for presenting data, not storing or working with it. If you're not producing the Q3 earnings report you're using the wrong tool.

    • Re: Facepalm (Score:4, Insightful)

      by OrangeTide ( 124937 ) on Thursday March 21, 2024 @03:10AM (#64332771) Homepage Journal

      It's certainly a tool for working with data. Excel is a big calculator that works on a grid. There is a lot you can do with it that it, ehm, excels at. It's not a database, but a lot of things aren't solved with a database. If you feed a spreadsheet data, it should pop out answers if you've set up you cells correctly. If you need to do complex queries, it sucks at that. But it does OK with date related evaluations, so you can use it in some interesting ways like to get a delivery estimate out of it. This can be used for some pretty basic project tracking that is below average for engineering teams but punches above it's weight for just about anyone else.

    • Re:Facepalm (Score:5, Insightful)

      by thegarbz ( 1787294 ) on Thursday March 21, 2024 @03:31AM (#64332793)

      It is for presenting data, not storing or working with it.

      That is just an absurd statement given that 99% of excel functions are for working with data rather than for storing or presenting it.

      Look we know to every IT person every problem can be solved by throwing a database at it. But the reality is a database without a complex relationship is nothing more than a large excel table with significantly less functionality. If your data is 2 dimensional, and accessed by single users at a time then a database is the wrong tool for *storing* the data, because you don't have data, you have a list in a table form, and Excel is pretty damn good at dealing with a list.

      Now sure there are limitations. The 1million row limit in Excel proved to be a problem when tracking the number of COVID cases in the UK, but for the over whemling majority of "data" in the world, Excel is perfectly fine given the required simplicity and the required ease of understanding.

      • It was actually the 65536 row limit in Excel 2003 that was the problem in tracking Covid cases in the UK.

    • Excel can be a great engineering tool though. I have had plenty of 9,000+ row spreadsheets over the years for design and analysis. Data is in that table and you use pivots or charts to analyze it. It happens because you get source data that might have hours in a year that you manipulate with additional columns. A database is the wrong tool for that kind of task.

      The situation doesn't change until you have a need for dynamic updates to the source data. Unfortunately for the Williams team, this was the positio

  • by nicubunu ( 242346 ) on Thursday March 21, 2024 @02:16AM (#64332719) Homepage

    You know the KISS design principle? Keep It Simple and Stupid. I am sure they went with Excel in the first place because it seemed the KISS solution and a lot of places are doing the same. To use a database app you don't only need the programmer to develop it initially, you also need the programmer continuously to maintain it (server, framework, database updates and such) and customize it when you need something that was not in the initial specs. Sure, if you can afford a F1 team, you probably can afford an IT team too...

  • I suppose it's better than using a spreadsheet because you didn't know Word does tables, but I'm sure there's someone out there with the ultimate worst example.

  • ...but excel is typically used by people who have something else to do with their time and effort, and for whom the system used is of secondary importance.

    Let's remember all the massive subjects where complex, for-purpose software development spent millions or even billions and ended up useless or worse than useless, Cf the dept of defense or the state of of MN's decade long driver license boondoggle.

    Excel may not be perfect, certainly, but neither are bespoke software solutions, either.

  • 25 years ago I worked in a factory automation group in an Alcan Aluminum plant. We were building a scheduling/tracking system using an Oracle database and C for the back end, and VB for the UI. While we were building ours, one of our sister plants built a scheduling/tracking system using Excel. There was the usual back-and-forth sniping about who's approach was better. We said that theirs would fall over once they tried scaling it up. They said ours was too expensive and would take too long to develop.

  • Most people are terrible at their jobs, and developers are no different.

    Organizations have good reason to be reluctant.
  • I worked in the auto industry for a number of years. In my experience, engineers are generally very comfortable working with spreadsheets in technical and non-technical areas. This is in sharp contrast to the (pure) software engineers I've worked with who seem to take a much more holistic approach and find best tool for the job. Personally speaking, it's my pet hate when engineers abuse spreadsheets in this way. In the past I've resorted to opening the terrible ones in python + pandas to avoid tearing hair
  • So, I'm all anti Microsoft and all in on open source and everything... but.... I've seen built and worked on spreadsheets (back in the day) that were ridiculously complex. Ha ha funny story ... the Senate of a certain country, I... ahem... live in... ummm... did their corporate budget in a...it must have been lotus 123... I don't recall the number of lines, or functions or macros, but it was LARGE... in the thousands. Computer RAM of 32 MEGS was considered MASSIVE back then..

    It worked. Perfectly.

    I learned
    • The reason you use a db instead of a spreadsheet is that it is a lot easier do do certain kinds of calculations and turn them into reports.

      Say, "which parts are costing us the most, and compare with shipping times and costs from different sources" so you can trade time for money or vice versa.

      Once the raw data is loaded in, your db can answer all sorts of questions without having to spend hours fiddling with manually built tables and lookups in Excel.

  • Is there a current entrant in the "database for normies" category that actually works?

    In the mid 90's I supported ordinary secretaries who used Filemaker for all sorts of database things.

    Some even had relational setups (though few).

    The company switched to Access as their only option and it was impenetrable to them so they started using Excel sheets instead, with greatly reduced functionality (Excel was always an option for them).

    I hear there's a good online database site these days but it there any decent o

  • "their internal monologue is Excel"

    I have worked with ERP systems for about 30 years and no matter what business the customer has been in a huge amount of data ends up in Excel at some point.

  • I'm using Excel as a stand in for any generic spreadsheet.

    What is Excel actually useful for?

    If the data is worth storing as an inventory, Excel isn't the right tool. If the data requires serious computation, Excel isn't the right tool. If you need clarity, organization or usability, Excel isn't the right tool. Really when you boil it down, Excel it for very simple cell based work, and that's it. If it's more complicated than a home accounting system for Tins of Pipe tobacco, Excel is the wrong tool.

I'd rather just believe that it's done by little elves running around.

Working...