"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
- Donald Knuth
Start with a gsheet, when it breaks build something else.
True story - I know a guy who built an application using Excel for tracking toll charges for car rentals back in the early 2000's. Over time he built out a team and an application. Piece by piece he automated things, but he initially did everything by hand, tracked it in Excel and printed it in PDFs out to his customers for reconciliation.
He sold the business for $400M. No outside capital, he was the only owner.
Anecdotal, my previous employer had a contract once for a gas storage / exchange, for years their whole business relied on an Excel sheet (basically tracking gas storage transactions from various customers). I don't remember why but they decided to migrate that to a proper application, I think it took a full development team two years to build in all.
But it's likely that, as these things go, they added much more features and visualizations on top instead of just a like-for-like replacement.
TL;DR that company was bootstrapped successfully on just a spreadsheet.
> Start with a gsheet, when it breaks build something else.
Absolutely don't. The one who built the spreadsheet will have changed companies and the "business logic" and the knowledge will be gone with them. You're now stuck with a blackbox that no ones knows the specs of but everybody depends on.
If the sky doesn't fall the sky doesn't fall. Buddy of mine in sales is using some old DOS software from the 90s to control inventory and quotes. I bet there are absolutely zero people who know how it works in that company today. But, it works.
Turns out when you make relatively simple software, it doesn't really need maintenance. How often do you need to maintain a function like f(x)= mx + b? If it works it works.
It is kind of interesting seeing the fear developers have over "everything in finance is on excel." It kind of reeks of armchairism where one assumes the worst immediately and assumes this assumption has somehow not been realized by the domain experts in this space who are in fact also smart spend all their time on the thing.
To an accountant, excel spreadsheet is a source of truth. There is no undetermined behavior. They can look at the calculations underlying the spreadsheet and understand what is happening, no different than a developer looking at source code. They do in fact have their own forms of unit tests considering these data are audited in a far more rigorous fashion than most any code that ships with unit tests.
A spreadsheet doesn't scale, is easily lost or corrupted or stolen, doesn't have security and people that tend to use it don't add data validation and don't care about atomic properties or data consistency.
These are different reasons than given previously. Regardless, Google Sheets are automatically versioned and have extensive access controls, both at the document level, and cell level. Further still, these types of documents are not black boxes, since anyone with access can inspect the data themselves. Arguments regarding scale and atomic operations/properties/consistency are fine, though I do not believe all business logic is necessarily beholden to these qualities.
Let's qualify spreadsheets as software: critical software should not be made by a non-technical person that doesn't know software engineering principles.
I guess Google Sheets invalidates some of my arguments, but Excel certainly does not. And, even if the feature is there, I've never seen them applied.
- Donald Knuth
Start with a gsheet, when it breaks build something else.