No no no. People at my company already use spreadsheets where they don't belong (in the place of databases, note taking apps, regular expressions, and one time someone tried to do page layout with it). The last thing we need is for these bozos to program with it. I see the need for an intermediate entryway into programming (Hypercard), just don't tack it on to an already bloated program like excel.
I think you need to sit down next to those "bozos" for a day or two and see their actual workflow. I've seen and worked closely with people using Excel instead of databases; hell, myself I used it as a map editor for a 2D game (for page layout I prefer PowerPoint).
The reason Excel is so popular is not because non-coders are dumb. It's because "tools" provided by IT department are usually piece of crap that makes work more difficult for people using them. Take using Excel instead of databases - why spreadsheet is better? Because it has easier data entry, and it's free-form. When you need to modify your workflow to include some additional notes, you don't have to write to the manager of the manager of the internal procedures to maybe consider updating the schema somewhen before next decade. You just add a new column and you're done.
I'm sure when someone creates a program that actually solves the problems those people encounter every day, they'll gladly switch to using it. But it's easier to say that users are stupid instead of actually caring about what their needs are.
I don't think the users of spreadsheets are dumb. I think they don't have an appreciation for organization of data to allow for efficient machine-readability. Your use of a spreadsheet as a game editor shows that you're one of the exceptions that proves the rule.
The free-form nature of spreadsheets, in my experience, almost always makes for human readable repositories of data that are nearlyuseless from an automated processing perspective. I cringe when I'm asked to export data from a database into a spreadsheet for users to edit, because I know I'm going to get back an unparsable mess that I'm going to have to invest time in to make usable again.
The spreadsheet is, effectively, shifting the user's inability to understand why data needs to be organized well off to a programmer (or some other grunt) who ends up fixing all the data up. (Or, alternatively, nobody fixes it up and the business ends up making bad decisions based on garbage data that came from a spreadsheet that's a disorganized mess.)
> I don't think the users of spreadsheets are dumb. I think they don't have an appreciation for organization of data to allow for efficient machine-readability.
Well said...it's that concept of machine-readability that is so core to efficient data investigation and interoperability with other enterprises (such as web apps)...theoretically, such a concept is learnable without a decent jump into the computer science/programming waters...but honestly, I haven't run into many lay persons who have figured it out well enough for themselves.
I would say that Excel is more a writing environment rather than a reading environment, the problem is not with Excel itself, it's just there is always a lack of validation, consistency and proper backups / history with Excel. So people just jump on it because it's simple to use and just make sense but the problem is that they don't see the broader picture and how the things they are actually creating are going to be used in the future (and if they can).
And considering that even running some CRUD app framework like Rails or Django is verboten in many corporate environments, Excel (or Access, but even that seems to be getting rarer) is simply the most powerful tool available to most people at work.
Isn't it exactly the opportunity at hand? No matter how much you don't want them to, people will still use spreadsheets, and the reasons why don't even matter. Instead of getting in another lost battle (Hypercard), just give people what they want, and combine their love of spreadsheets with their need for data connectivity.
Which, from an interoperability perspective, is an improvement, no?
I feel like this is one of those things we as geeks tend to miss. We look at that document and say "Ew! Look at that crappy HTML." But we miss the point that, no matter how crappy the HTML is, the fact that it's HTML at all makes it better in many ways than the same doc was when it was locked in .DOC or .DOCX.
That was exactly my first thought as well. The LAST thing any company needs is more excel sheets—unprotected, easily lost, bloated, no-backup excel sheets.
Leaving alone the observation that, in many companies, the rank-and-file don't even know how to insert a new row in a spreadsheet, let alone muck with functions..
It's the ones that know the functions that you have to worry about. Especially finance people. Excel is the software they are most comfortable in, and they never want to leave it. My boss just made our company events calendar in excel. Why not do this in a calendar program? Because he can do it faster in excel.
If he can do it faster in excel, isn't that a good enough reason?
If the problem is that the spreadsheet later becomes an unworkable mess, isn't that an argument you can use to convince him to use other tools? And if he remains unconvinced... maybe excel was right for him after all?
That's a very good reason. I perfectly understand not willing to learn yet another fancy tool that looks nice, but is unfinished, buggy and will probably be gone next year. Some people are too busy doing actual business to waste time on that.
The biggest benefit of Excel is its flexibility - you can do what you need, how you need, and you can adjust and readjust your sheets on the fly to match the changing and messy needs of doing business. That database you're trying to force those workers to use? It's probably designed wrong the moment you save the schema, because the needs changed.
So Excel is unsecure and people keep losing their spreadsheets by moving them between each other on flash drives? Solve that. Maybe with a Dropbox-like solution for syncing documents (no shiny webapp bullshit, no logging in to domain NAT Samba Kerberos Windows Briefcase Sharepoint nonsense, just "a folder that syncs" and enforces some security).
I have the feeling that a lot of problems between IT and non-tech workers stems from the former treating latter like morons instead of trying to help them to do their jobs efficiently.
>I have the feeling that a lot of problems between IT and non-tech workers stems from the former treating latter like morons instead of trying to help them to do their jobs efficiently.
No. I know this sounds bad, but they really are morons.
OK, maybe that's too much. They're not morons. But neither are babies (could you learn a language as quickly as they do?). Like babies, they just don't know stuff. And they never have an incentive to learn it. Programmer is always there to save the day.
When the ability to code is seen as essential to be in a C-level position, I predict that many frustrations with IT will just magically disappear.
>I predict that many frustrations with IT would magically disappear if IT stopped calling everyone who doesn't know how to program morons or babies.
That's already happened. Have projects magically aligned to budgets and schedules? Have we been able to fire all the programmers and replace them with business analysts yet? Have Excel sheets become maintainable?
Certainly it's a good thing if IT doesn't hold itself as superior; but that does not mean that it's not a bad thing that most business people don't have what is becoming a more and more essential skill.
1. People have to read this calendar.
2. People have to edit this calendar.
3. Other people in the office don't know Excel as well as him.
4. Other stuff is designed to work with our calendar software, but not excel.
A hammer can drive a nail into wood. With a little help, it can also remove nails, smash glass, and pry things open. But if you're using a hammer to stretch pizza dough, get help.
Those are pretty good arguments you can use to convince your boss to start using your calendar software! So why hasn't he switched? I see some possibilities:
- No-one has pointed out these shortcomings to your boss.
- You have, but he is stubborn and refuses to see the downsides even though they are obvious to everyone else.
- You have, but you're overstating the downsides and the current setup actually works well enough as it is.
Even though he may be able to start working faster, there's no guarantee that the time-to-completion is faster. Also, in a calendar program it's going to be orders of magnitude faster to change stuff like the design in hindsight. And you're likely able to achieve designs that are physically impossible to do in Excel.
I think a better idea would be an easier way for those people who built a spreadsheet (that was supposed to be temporary but then became permanent, and then became critical) to transition to a database (that lives on your own machine) would be a better idea. More data lives on spreadsheets than databases in a typical office environment, and part of the reason why is data entry speed, but another part of the reason why is that it's hard to get people to transition to the database.
This could be a good approach. Let people figure out optimal workflow with their spreadsheets, and when those spreadsheets stabilize, then help them move to a database. Aside from data entry speed, part of the reason is flexibility, especially when you're just figuring out what's the best way to collect and process data for a particular task.
As a developer in a company that does custom integrations, I wholeheartedly agree. Let them pay us to convert their unstructured files, instead of letting some automated importer do the job.
I'm only half kidding; the margin on our Pentaho Kettle transformations is quite good.
I would love to see a modern Hypercard. Use http to share plain text info; use "Supercard" if you want to build a complicated visual presentation with bells and whistles (rather than cobbling together from html, css, js, etc.). There has got to be some demand for this.
