| Excel is powerful, but it is also important to consider its limitations. Things will get real when your orgs problems/needs grow from something that was totally cool to do with spreadsheets to something requiring higher complexity, performance, resilience, testability, coordination, ... — and the point at which you cross over into the latter is not always clearly marked. It would for example not be advisable to use Excel sheets as a replacement for a distributed database of central importance, unless your org is a lemonade stand with 3 employees. I would also prefer maintaining a python script with written tests over maintaining an Excel file containing complex business logic, but maybe that is just personal perference. Don't get me wrong here, Excel is amazing and we should all use it where it shines. But as with all tools we need to be aware of the fact that they heavily color the way we look at problems, as expressed by Maslows famous aphorism: "If the only tool you have is a hammer, you tend to see every problem as a nail." Good engineers should not be blinded by their tools, but accutly aware of their limitations and know which to use when. Just like with hand tools you could probably also just hammer a nail in using a shovel or "drill" a hole using a screwdriver and Excel is very versatile in those regards: it can get you very far without being the best solution, a bit like a swiss pocket knife. |