> It's interesting exercise to argue the case for and against your own software! With the passage of time I can look back at this. There are devotees for the function approach, but I can tell you that there are serious detractors out there too. So let's consider the arguments. After all, if you are going to use BF it's quite likely that you will use it for some pretty important stuff - it’s an important decision.
Pros
Many of these are mentioned elsewhere, but in short:- There are some functions you just couldn't model yourself with the same degree of accuracy. S curves, property leases - if you want "accountant" level accuracy, we don't see how you cannot use BF or something similar.
- BF has been around over 20 years and been actively managed. It's still got bugs (;o!) but is substantially debugged and reliable.
- It's fast, documented, loads of examples etc.
- If you are at all familiar with the library, picking up someone else's model is much easier than deciphering freeform Excel formulae.
Cons
Is it a panacea? Is there a downside? Well, some could claim, with some legitimacy:
- "It's over-complicated": This is possible. We are trying to put a lot of capability into a single simple component, a function. This even results in a few functions that actually have 29 arguments! We try to address this with documentation and examples and many defaultable arguments. But the simple answer is if you want to avoid complexity, don’t use the more complex functions with the long argument lists. Many short functions like the Con… family and the Pmts… family don't have many arguments and are very powerful and will greatly improve your model (in our view).
- "It’s not future-proof": Its been around a long time and works on several versions of Microsoft Excel. However, some new directions of Excel towards online spreadsheets (Excel Services) may prove challenging, but we don't know anyone seriously using these. Furthermore, Microsoft has continued the development and support of the Excel add-in API and illustrates continuing commitment to the C++ add-in methodology. Newer approaches being currently promoted including the use of Javascript cannot hope to get near the same level of performance as a C++ xll add-in.
- "It's a black box". Of course, decluttering spreadsheets - by abstracting calculations away to a library - does to some extent black-boxify your models. We address this hopefully by good function design, documentation, examples and by making the source code partially available in the help files. We also have a unique Trace facility that outputs debug messages from all the functions. Also, as a design methodology, the functions tend to call each other and use a quite small kernel of core functions, thereby reducing bugs. It is perhaps more a set of building blocks, each of which is a black box, rather than a single black box.
The key argument really is to what extent you are happy with black-boxing some really important formulae. Well, ever since the stone-age we have been black-boxing tools into things we use everyday, so it's not so evil to do this in a spreadsheet, is it? And the key benefits are fast, accurate, compact and flexible models that your competitors simply cannot build!