Tobias Müller and Yannick Müller directly faced such challenges from previous experience in finance roles, creating Flike to address these issues. Flike is building “GitHub for spreadsheets" to allow for more effective collaboration at scale via automation and version control. The San Francisco-based startup has recently raised a pre-seed round of $1.6M from notable angels and is a part of Y Combinator’s W22 batch.
… Tobias Müller and Yannick Müller : Finance professionals’ biggest issues are the time-consuming nature of gathering input, keeping an overview of different versions, and frequent errors in spreadsheets. File-owners often create multiple templates since there are no features to get input into the main file easily. One risks the “inputter” breaking things or overwriting the file by sending the whole file. Data sensitivity issues are also a key factor since the main file often contains confidential data which is not supposed to be seen by the contributors.
The second piece, version control, is currently solved by constantly saving and renaming a file. It’s not uncommon to see a file called “Financial_Model_v124”, i.e., 124 versions of the file exist! Our mission at Flike is to empower knowledge workers to spend their energy and focus on what truly matters rather than managing file names.
Lastly, according to studies, 90% of all spreadsheets contain errors. All finance folks are trying to reduce the errors in their sheets, which often get introduced by complex copy-paste exercises. By getting rid of all kinds of copy-pasting, we help teams reduce error rates.
Diving deeper, finance workers often need to gather input from co-workers, which needs to be copied & pasted into the main file. This simple “input-gathering” is very tedious in the status quo. In high-trust teams which collaborate closely, the file owner might send across the whole file to the person she is requesting input from or allow access to the file on a shared drive. For collaboration across bigger teams or with other departments, finance professionals often set up a template sheet that they send around. This leaves the main file in the hands of the file owner, getting her full control over input. Specifically for the latter case, our tool allows users to gather input efficiently while staying in Excel (no need to manage siloed communication channels anymore, e.g., Slack and Email). By having an acceptance feature (allowing the file owner to accept/reject the suggested input), we also make copy-pasting obsolete and increase the validation threshold for inputs, leading to fewer errors.
It has to do with how changes are tracked, and really how people interact with the system in general. How does Excel code usually work? Excel code, of course, is usually formulas, and people will copy and paste… and then people often insert/delete rows and columns… and how will that come out in github, eh?
The reason I say “I wish them well”, for this “github for Excel” has to do with how Excel users generally behave, and how one thinks in terms of inputs/outputs, inventory of unique formulas that are replicated, etc.
I’m writing a lookup or sumif, and go to another sheet for references, and then come back to the original sheet and click on a range-- excel assumes I want the sheet name in the formula for no reason. Super annoying.
The workaround is to click on everything I want before walking away, but I always forget.
I hate how the little formula-helper popup overlaps the column headers. You can turn it off, or move it aside, but you can’t just make it pop-up somewhere less stupid.
You can change it so that Excel doesn’t convert strings that look like dates as dates. And the other conversions that it has done as defaults (I just unchecked all those defaults.)
Now I’m wondering just how hard it is to do this and not affect every date ever in current Excel spreadsheets. IMO, negative numbers as dates prior to 1900 seems best.
The Google found an answer: use Google Sheets or other spreadsheets that recognized the stupidity of Excel’s date restriction. Can also use VBA, though I think that works only for Gregorian dates.
In a technical way, there is; it all depends on how they’re using the bits of the encoded information. Most likely, they’re not using the first bit to capture “sign” and using all available bits for the date/timestamp logic.
That’s not to say that they couldn’t revamp the whole thing to accomplish the “change” . . . but it would very likely be a very extensive overhaul of source code (at the very least, a pretty exhaustive review of all date-related functions/functionality).
