Valid point - you eventually want your revenue to be larger than your expenses (unless you plan to get acqui-hired...)
Invalid point - you need Excel to figure that out. I think a good hacker is more likely to use some combination of R, Python + Pandas, databases and CSV files to do most of their financial modelling. Then those all-important month-end reports can just be automated away...
I work in finance, I toyed with Python and Pandas and CSV files for a while, it won't do. When you get at it, you soon realize that any kind of decision will have to come from high level numbers, no the billions of rows you hear on HN and, in that area, it makes simply no sense using anything other than Excel.
Pandas has all sorts of functionality for summarizing data. I can see sticking with the tool you know or preferring a pointy clicky interface, but you are implying the capability to generate those high level numbers is missing, and it isn't.
Just because something can summarize data doesn't mean it's the best tool to use when trying to explain something. Executives and VC's with non-technical backgrounds might be intimidated by someone using relatively complex tools for what, to them, could be a basic spreadsheet on a platform they know how to use themselves. Excel's value comes mostly from the fact that everyone knows how to use it at some level, and the formulas are relatively easy to follow, so your audience knows they could probably reproduce and verify your work.
Valid Point: High-Ranked execs use it and usually try to translate everything into excel sheets. They would really appreciate seeing excel sheets in presentations.
Invalid point: Formulae are easy to follow and audience can easily verify/reproduce your work.
My friend, excel rocks when MAKING a spreadsheet, but it can be hellishly annoying to follow. when you got a long chain of formulae cells, it is very annoying to trace the data through it to see where it is coming form. Sure, a properly labelled Sheet takes care of it, but that's not usually the case. That's the main reason i am very excited about that excel-sheet visualization tool posted here the other day.
It may be hellishly annoying to follow (and trust me, I've had to clean up many Frankenstein-esque spreadsheets), but it's imo easier than any sort of messy code. Which do you think is harder for Average Joe Exec - following poorly documented and messy code, or following a poorly documented and messy spreadsheet?
PS I'm also very excited for that tool. Will make my life so much easier.
>> Invalid point: Formulae are easy to follow and audience can easily verify/reproduce your work.
Actually this is another valid point of Excel.
Unless the financial model was done incorrectly (using VBA, complicated formula chains, unclear logic), it is very easy to verify financial model in Excel, which is a big plus.
Excel has been partly to blame for many bugs in mathematical models, in part because of its datatypes and in part because of its builtins. Some of these bugs are not at all easy to spot, depending on how you go about the building and the verifying.
What mathematical models? For your company financial assumptions and forecasts you generally need, in essence, the sum(...) function, percentages and multiplication, repeated ad nauseam, and if any of your formulas even have space for 'not easy to spot' bugs then the bug is in thinking of making such formulas in the first place.
Your spreadsheets would be big because of quantity of different things included, not because of complexity of those things
High level? Think about cash flow forecast. How you do this? You need to model your income statement and balance sheet. Start building up assumptions for: sales (duh), accounts receivables, overdues, your cogs, inventory, possible capex investments, opex, etc.
This is very structured data, you can build up hierarchy trees in python, but it will take you too long. Plus, your models will change, people will want to see things from many different changing angles.
Unfortunately, every time I start writing about controlling people desert the thread around here, but it is a fascinating topic.
My obvious example is "what do we have to do to break even?"
What a spreadsheet does very well is allow you to quickly run a large set of simulations right next to eachother for comparison. This can be useful in asking questions like, "if we charge $x, and we have $y in fixed expenses, what should our target of support personnel to customers be?"
You can do that perfectly well with R. Heck, R was designed with that kind of workloads in mind. With RStudio you can even present a table which the non-programmers can directly manipulate to test those conditions.
I usually use spreadsheets only as data entry software and then R does the rest.
If your data is entered in a spreadsheet, is it really faster and easier for you to run the data through another tool, rather than just writing the formulas right there in front of you?
You definitely can do it in R, but the formulas are trivial anyway and writing them in code takes as much time as in Excel, can you help me understand what I could gain by using R here?
I imagine that the spreadsheet is there to support an easy input format that anyone can get involved with. The spreadsheet basically only holds the assumptions and the facts. Then all the modeling is done in something where following the flow control is far more readable because you're dealing with long well named variables, which are rare to none existent in most spreadsheets.
When I worked in Wall Street level finance, basically none of the analysts bothered to use anything more than cell address, e.g. /[A-Z]\{0,1}[0-9]\{0,3}/. They basically treated naming their variables like most software engineers treat commenting their code. That shit was impossible to follow because.
The individual formulas may be trivial, but when you have a complex model with many pages representing different aspects of the business internally and external macro aspects, it can get messy fast.
No doubt, but I would be very surprised if one could set up an R simulation quicker than one could set up a comparable spreadsheet. I don't see R and spreadsheets as interchangeable. They are very complimentary technologies.
I totally agree with your point. Somehow we as technically savvy folks have confused the idea that the tool is more important than the big picture. While tools are great (and I even blog about great tools) it is the knowledge and skill behind the tools that ultimately lead to success. The tool is just an instrument. In other words, a means to an end.
I use a variety of spreadsheets but haven't touched Excel in years.
What a spreadsheet gives you, assuming you have enough math skill to operate one reasonably (i.e. at least a year of college algebra), is an ability to create tables of data following certain assumptions that project various scenarios. This is most helpful as a visualization tool. You could probably do something similar with R and some CSV files, but I find spreadsheets are actually really helpful here.
PS, I really don't like Excel, just because I have run into so many braindead issues with it. That doesn't say spreadsheets are not a very good tool for certain kinds of problems though.
Of course, if you use python/R, you don't need to manually tweak a few assumptions in a spreadsheet and look at a few outcomes. You can instead just assign them a probability distribution and run a monte carlo simulation.
Doesn't that give me an average of the possibilities? I dont think people are usually looking for that... they usually want to specific cases, or graphs. both are very well supported in excel.
PS: I think excel probably has some support for monte carlo too. should look into it.
The output of a monte carlo simulation is a list of N (for N really large) of possible futures. You can average them, you can compute P(business makes a profit), you can do whatever you want with it.
If you want graphs you can spit out not just one, but multiple representative ones, credible intervals, etc.
Well, If I had a choice, I would definitely NOT want to assign a probability distribution and run a MC sim.
First because the probablity distribution itself would have to be pulled out of thin air, and make the results questionable.
Second because writing the assumption->outcome formulas is simply quicker than running an MC sim even if doing the sim is a one-liner (simply ensuring that the data is in appropriate format and testing once will take longer than needed).
Third (and main) because you don't particularly need the actual outcomes at all, the hands-on-tweaking of these assumptions and 'interactive learning' is the whole point of doing it all, you need to personally learn and feel the relation between these assumptions and financial results, and the 'result' numbers and graphs are just a side-effect and notes/docs to remind you later.
And if you need to convince someone else afterwards of your conclusions, then for 99% of audiences you anyway want to use 'specific plausible scenario story' (or comparisons of such scenarios) instead of a probability distribution coming out of a solid mathematical simulation of all possibilities; since it's well researched that the first kind of evidence works better in convincing homo sapiens about anything at all.
First because the probablity distribution itself would have to be pulled out of thin air, and make the results questionable.
Of course. It's just a more systematic version of manually tweaking parameters in a spreadsheet (which are also pulled out of thin air).
With libraries like PyMC, it's one extra step beyond writing an assumption->outcome formula. You write the same formula, but then set variables to probability distributions rather than floats .
And if you need to convince someone else afterwards of your conclusions, then for 99% of audiences you anyway want to use 'specific plausible scenario story'...since it's well researched that the first kind of evidence works better in convincing homo sapiens about anything at all.
If it can handle the same formulas, then I could imagine a market for a tool that takes an existing spreadsheet and does what you say - allows to set a probability distribution for any number, recalculates everything, and shows the distribution for resultcells on, say, mouseover.
Convenience matters in such things, and simply reading a 20x20 data table into any programming language already takes more time than just writing the formulas next to this table in excel.
> First because the probablity distribution itself would have to be pulled out of thin air, and make the results questionable.
All aspects of financial forecasting in the initial stages are pulled out of thin air and are hence questionable. This is one of the big uncertainties one lives with when starting a business.
> Third (and main) because you don't particularly need the actual outcomes at all,
Bingo. That's the key. What you are looking for is not "will my business succeed" but rather "what do I have to do in order to succeed?" The tweaking of the model is the point, not the outcomes.
Don't found a company unless you understand basic business concepts and maintain an accurate audit trail of your financial operations (or use/employ someone who does) - sure. Using Excel? Maybe, but it's not the only option so the original article is way off the mark being so specific. It's akin to saying "if you want to make a telephone call, use an iPhone".
Anyway, based on my current employer, spreadsheets are for:
Holiday rotas
Support call logs / case management
Weekly status reporting (because the format I was using in Word was so tabular 'it might as well be done in a spreadsheet' - go figure!)
Project Management (Make a GANTT chart by colouring in various width/Joined cells) and then spend ages manually adjusting things when dependencies slip.
Manually copying/pasting data from an on-screen query so it can be sorted and deduped before being put into an email. I have now automated the whole process.
If I'm starting a company, don't I want R and E to satisfy an inequality (and one in a particular direction) instead of an equation?
More seriously, Excel has many problems that make it unsuitable for anything that might require statistical analysis. See for example B.D. McCullough and Berry Wilson, "On the accuracy of statistical procedures in Microsoft Excel 2003," Comput. Statist. Data Anal. 49 (2005), no. 4, 1244--1252, available online at http://dx.doi.org/10.1016/j.csda.2004.06.016 but paywalled. I thought that this article, or a similar one, was recently discussed on HN, but I could not find an appropriate link.
On the other hand, I don't know anything about business. I can see an argument for using a widely-deployed piece of software for verifying R > E even if it is inappropriate for data analysis.
Financials and statistics are two very different animals.
In business usage, all your financial spreadsheets including forecasts will have a grand total of 0 statistical functions used; and your marketing/customer segmentation people, when a business starts to have them, will use some statistics but again, looking at your article (somehow not behind a paywall?) - there is zero overlap between the listed problems and with what those people will actually use.
Good analysis of customer behavior (instead of just financials) can use all kind of heavy stats, but it's done by different people and at an different company stage than the original article is talking about; if you're starting a company you simply won't be doing any of that until after a million of other things.
You definitely don't want to be using Excel for heavy data analysis or statistical analysis, and unfortunately some companies refuse to acknowledge that. Performance is very often sacrificed for familiarity and ease-of-use in business.
Even as spreadsheets go, I wouldn't use Excel for statistical analysis (I wouldn't use any spreadsheet unless it was a function coded as a macro). It's not just a performance thing, but also a confidence in results thing. Spreadsheets admit to oversimplifying the processing and then having issues as the assumptions in the data change.
This does not mean that a spreadsheet couldn't be an important piece of the pipeline though. Database to Spreadsheet is actually a very powerful combination, particularly with views.
Absolutely agree with you. Database-to-spreadsheet is the best way to analyze data then summarize the results in a business setting. Unfortunately, the people seeing the results occasionally want to see how you got to your numbers, and since they frequently have non-technical backgrounds the database step is often where they can no longer follow.
I worked at a company where our data was in SQL Server but we basically had to import the entire data set into Excel because none of the higher-ups knew SQL and wouldn't be able to peer review. Those spreadsheets were slooooooow.
It's funny, the other co-founder of Efficito is a financial analyst who writes tools to do his analysis for him in Lisp. He also maintains a Common Lisp implementation. Fortunately I bet your former employer would not be interested in his services.
Q. Why would assembler require more developer time?
A. Because most developers aren't anywhere near familiar enough with assembler to do so and because ruby/python/php/etc are much much easier to use for developing a web app.
Because it is far more clever than anything I could do in Excel. And it doesn't require me to duplicate information all over the place. I'd rather have just one master source of data that I do all the calculations on.
If you're doing deep analysis on large historical data, then it's in essence a MIS system, and most businesses do (and should do) that outside of Excel.
But what the article is about, in a growing startup or a changing company (say, completely new product line) the 'one master source of data' is not in a database but the assumptions in your head; and any clever model based on your historical data will be either impossible or far more wrong than a simple order-of-magnitude calculation done on a paper napkin. And, well, Excel is more convenient than the napkin.
It's not the end of the world to do accounts in a spreadsheet. In fact for certain sorts of things, they are really ideal.
However, it is a huge mistake to keep your general ledger or book of original entry in Excel. The reason has nothing to do with making mistakes or errors and every thing to do about fraud. Paper is the gold standard in anti-fraud accounting systems, particularly if you follow the standard rules like ensuring books are kept in pen. Paper to Excel is fine. Replacing the paper with Excel is not.
I would be curious to know for which sort of accounting things Excel is ideal?
Sorry, I could not comprehend the second paragraph.
Fraud has nothing to do with paper or computer based system. To minimize risk of fraud you need to implement proper sets of controls, like segregation of duties, etc.
As for Excel - Excel is a poor instrument for doing the accounting, therefore it shall not be used ... unless you have some kind of micro/nano business.
> I would be curious to know for which sort of accounting things Excel is ideal?
Well, let's see.
1. Preprocessing data for entry. This might be used, for example, if you want to depreciate fixed assets using a method your accounting software does not support.
2. Post-processing data. You might do this if you have a report from an accounting system but your final report needs to take into account additional factors. Some of my customers use Excel to turn trial balance data from their accounting systems into financial statements.
Another example of post-processing might be if you take aggregated sales reports from an accounting system and further process it by business folk who don't know the programming environment.
As for paper: Yes, separation of duties is a part of it but paper has an advantage that no computer system can match, namely that if you keep your books in indelible ink, then alteration of numbers is obvious on audit. This is a weak point of electronic media. You can lock it down, but it is always possible for someone to unlock it. So with comparable policies, paper wins out anti-fraud-wise.
Interesting, actually what you mention is not an accounting per se, but I agree with you, specifically
>> 1. Pre-processing data for the entry.
For this specific example if the accounting package does not support certain depreciation method (which rather rare), you can easily do this in Excel, both for financial modelling purposes and as a supporting document for the accounting entry.
>> 2. Post-processing data.
What you describe is not accounting. This is financial and management reporting. Yes, Excel is what is used by most everyone.
Perhaps I have a more expansive definition of "accounting" than you ;-) I do agree that Excel is not and never should be a primary tool for bookkeeping.
For a startup, most of what you'd like to do with your accounts is not 'accounting' as such, but management reporting/forecasting/what-if analysis. When you're big, there are all kinds of tools for that as well; but if you're small then you (or most likely someone outsourced) does your official accounts&taxes on a real accounting package, but for everything else there's Excel.
Sounds like a market opportunity. Aside from simple accounting (tracking revenue and expenses), what's the range of startup needs that are covered by Excel?
If these needs aren't met by current accounting / finance packages, it definitely opens the door for a new competitor.
I would never use a spreadsheet for basing decisions on. It is just too error prone. I do not know how many trillions of euros (and dollars) have been wasted due to some excel sheets having off-by-one errors in marking rows or similar issues.
... for various definitions of "almost". Depending on your needs, Open/Libre may run circles around Excel, or fail laughably. Just like Emacs vs. Vi, Language1 vs. Language2, it all depends on your needs and available time.
How would you write and explore, say, a cash flow forecast of a not-yet-existing product line with a cli script? I could imagine doing that in emacs, maybe, because you can probably do everything there; or on plain paper if you're quick+accurate with doing math in your head.. but in a cli script ?
Invalid point - you need Excel to figure that out. I think a good hacker is more likely to use some combination of R, Python + Pandas, databases and CSV files to do most of their financial modelling. Then those all-important month-end reports can just be automated away...