301–310 of 834 posts
Friends don't let friends use Excel. Unfortunately Excel is the great swiss army knife of software and it's hard to avoid.
Earlier quoted context omitted.
In my org excel might have been the start, the intent being to move over to a DB once someone got it stood up. Then nobody would stand up the DB - because not urgent, we have the excel for now. The DB would be completely forgotten, and 3 years down the road everybody would be wondering wtf we have this huge excel file for. Then we would have six weeks of meetings to discuss the file until something else comes up and…
That's why Excel wins. Because it's right there, infinitely adaptable to any change in workflow you may need to make. No need to send official requests through half a dozen layers of management to get the IT people to maybe, in half a year, add a column to the database. No need to involve 20 people for a year to create new software for a new workflow. You just agree with your co-workers on a change, swap a column, ad…
You're not wrong, but...
I wish there were some alternative where we instead fixed our ossified, byzantine processes gradually over time, so that we didn't need to break out the sword arm tornado in the name of getting work done and then, in hindsight, say, "well, shame about the negative externalities, but there really just was no other way. Ah well, let's move on, everyone who isn't a pile of flesh and blood and bits on the floor tidy up. Gotta get everything clean for the next sword arm tornado."
When I use Excel to open a CSV with too many rows, I get an alert saying 'File not loaded completely'. I have to dismiss it by clicking 'OK' before I can interact with the spreadsheet. So Excel isn't silently discarding data.
The BBC reports the problem was saving spreadsheets with more than 65536 rows as XLS. Can you verify Excel also throws an error for that case?
The problem is that anyone who isn't a decent coder think excel is a sensible choice for this, because they've seen it in their school or work. So when the proposals come in, you're going to see one guy who says it's all common sense and we use familiar old excel for everything, and another lunatic who says something called "pigsqueal" is actually the standard, connected to a "frontend" which for some reason is now s…
IMO, a much more likely scenario: a brittle, haphazard system was set up with extremely short notice at the start of everything. One administrative snafu led to another, ran into "well, it's working so let's not touch it", and we got to where we are today.
The problem is that anyone who isn't a decent coder think excel is a sensible choice for this, because they've seen it in their school or work. So when the proposals come in, you're going to see one guy who says it's all common sense and we use familiar old excel for everything, and another lunatic who says something called "pigsqueal" is actually the standard, connected to a "frontend" which for some reason is now s…
Come on, this is a government department of a first world country. They have databases for all sorts of things. They're not using excel for any other NHS databases, or the terrorism watchlist. There are plenty of people capable of making a good decision here. I think you let them off too easily by just assuming they're dumb. This a bad decision by people who definitely should have known better.
So the limit for Excell is 65,000 rows for the old format, and one million-plus rows for the new format (from the article). Then I wonder, is there any tool that mimic Excell but with Sqlite as the backend? The limit of rows in Sqlite is 2 raised to the power of 64 (18446744073709551616 or about 1.8e+19). https://sqlite.org/limits.html
Mimicking a spreadsheet with an RDBMS would be a neat hack, but I think the better solution is to simply use the database like a database. If an amateur carpenter is trying to hammer screws into wood, you hand him a screw driver, not try to invent some sort of hammer with a twisting mechanism that turns screws when you wack them. Use the right tool for the job, and use it like it's meant to be used. If the workers in…
That's a thing, it's a manual impact driver. And sometimes it is the right tool for the job (for example, when you have stuck screws and a regular screwdriver would just strip the head).
Earlier quoted context omitted.
That would imply non-tech people having some surprisingly deep visibility into technical details. What they really see is Excel vs. some contractor doing "a system". The reality is that Excel is available today and works, and scales up... well, until it doesn't. Still, you have data entry that everybody in the field understands, that's rock solid (so no need to unit test anything), and has a tried and true authentica…
Couldn't you achieve exactly what was needed here with Airtable? Or, easier yet, Google Sheets and a Google Form?
I would be much more upset to find out a governemnt employ on a deadline used Google Sheets or Airtable to share my medical data instead of an Excel doc on a secure government file server.
Earlier quoted context omitted.
This reminds me of developers talking about the git CLI. At some point you have to stop blaming the users.
I dont know what is your point? Defending guy who wrote an useless story, how he used Excel once, didn't know what he is doing so something went wrong and then his conclusion is that Excel sucks? Millions of people use the program every day, it has its own fair share of problems (like everything), but if random Karens in any corporation can learn how to use it, then you should expect the same from a random programmer…
Earlier quoted context omitted.
Umm, who is qualified to write programs in any programming language, if both programmers and developers frequently have errors in their code? https://cve.mitre.org/cve/
That exactly right, noone is. Thats why noone uses C++ or javascript in safety critical devices Even in 'normal' industry its is a huge problem and we need safer languages, i.e. Rust (merits to be seen)
JS... of course no one uses that mainly because the abstraction level is too high, the number of layers of non-safety-critical code massively outweighs the application code.
The critical thing about safety-critical code isn't really about the code... its the whole development process. Implementation is just one small part of that process.
Each test result creating several rows of data seems like a problem too. In clean data, every observation is one row. It makes working with the dataset much easier. In this scenario, I would expect one observation to correspond to one test result. The multiple rows are then better off pivoted into columns.
If the schema is consistent between rows, and it turns out a test result is made up of several rows because the test is composed of several stages, I would leave it as is until reporting time.
If you pivot prematurely, you could end up dropping data because there are new stages didn't exist when you implemented the pivot.