Hacker News new | ask | show | jobs
by shashank 1928 days ago
That's awesome, Navneet! I have heard from big hedge fund managers, and seen first hand working at "cutting edge" 401K fintech companies that spreadsheets are the backoffice workhorse in many many companies doing serious business and handling serious data.

I am curious about one aspect though: Debugging spreadsheets is seriously hard. How do you help customers verify their spreadsheet has the right things they are looking for, avoiding regressions due to a random change by some inexperienced person, etc.?

Also, at what point do you see companies move from spreadsheets to simply hiring developers to do what they want? It seems like beyond a point, spreadsheets can get in the way, and the company has enough resources to hire a team to build custom internal tools.

Good luck with Coefficient!

2 comments

Yeah spreadsheets are ubiquitous workhorses -- small companies to large, old to new, across geographies ...

Spreadsheets have many problems. We are going after their "connectivity" to the rest of the company systems. Hidden errors / debugging is definitely another big problem which we are only tangentially solving. If your data is imported into the sheet through Coefficient (instead of a copy-paste of a downloaded CSV), then you can always trace the lineage/timestamps/etc all the way to source.

As for hiring developers, the truth is that day-to-day business needs grow faster than you can hire devs. So yes, at a certain point companies move some workflows to dev-built tooling or specialized SaaS tools, but their bucket of unhandled workflows still grows larger every day. That is why you can't kill spreadsheets.

Debugging can be hard. That's often because what they're used for is done very fast. So, there's a business expert reasonably IT literature that has a powerful tool with a built-in IDE that doesn't take approvals or hiring requisitions or even budget and a problem's solved within a week on what otherwise would be a month (being kind).

The problem starts when whatever frankensheetvbasharepointdb is now an engrained part of a workflow, excelbizdev has disappeared, and 'maintenance' falls to nonexcelwhizz, or perhaps worse, a dev team that lacks much legacy business understanding to figure out why the particular implementation was done, screws up understanding, and creates something worse.