>Why are you writing a program for work unless you are helping to solve a problem? I'm not entirely sure what your point is here other than implying that the p

>Why are you writing a program for work unless you are helping to solve a problem? I'm not entirely sure what your point is here other than implying that the programs I/we write aren't solving a problem, which is not the case. > The implementation only exists to work with business logic and data. This is true. I would say that any implementation of automation is really an implementation of business logic that turns one set of data into another. For example, taking financial transaction data and using business logic to convert this into data that measures company profitability. > Excel is an implementation that does not care about business logic and data. Yes and no. Consider the example of transaction data -> profitability measures. If you compute this in excel, you are hand entering data (or using data inputs if you're not a neanderthal) and you're inserting business logic into cell formulas that relate to other cell formulas. Maybe you're even using VBA. Business logic is embedded in the worksheet. This is why you end up with a lot of small companies that have "THE" accounting spreadsheet and "THE" inventory management spreadsheet. It is the extent to which they can automate. I don't know if you've ever tried to detangle the business logic from an excel spreadsheet, but it is a pain in the ass, and it is very bug-prone. Tracking down bugs and errors in an excel spreadsheet is spiritual torture. > Anyone can add their own business logic and data. I guess you may have read my post from the perspective of a small company, where it is entirely feasible to store your company's data and business logic in spreadsheets. I'm coming from the perspective of a large enterprise where having excel spreadsheets on the critical path of any business process is a disaster.