| > Sharing information with non-coders could be an obvious one. You can do the exact same thing with code. You can still output reports and diagrams, and literally anything the "customer/user" wants. > I could have done a database with my wife's sewing patterns collection... Your example is a good one. I didn't think of images. > It was done in 2-3 hours, and she got exactly what she wanted. Fair enough. A spreadsheet was probably the right tool for the job in this case. But if she ever wanted more features, and the complexity increased, I don't know if it still would be. > I worked in a place where both the input and output was spreadsheets, and the users were spreadsheet users. Okay, but should they have been? Would custom software not have been the better solution? > a lot of the business logic (e.g. initial data validation, final presentation of the results) lived on the spreadsheets themselves. When I think of "business logic", "data validation", and "final presentation", a spreadsheet is one of the last tools I'd reach for. > Another interesting one is data-to-visual time. Unless you happen to be proficient in a particular area of programming (e.g. front programming with proficiency in something like D3, or R programmer) getting decent graphs out of data is a chore when going the programming route. With spreadsheets, you put the columns and get the graphs essentially for free. I also disagree with this. I am very much a back-end developer. But using something like GNUplot or a library like matplotlib is pretty easy for outputting a nice looking graph from tabular data. > To me spreadsheets are just another tool in the toolbox; they are appropriate for some tasks. They can definitely be misused and abused. Knowing which occasion is which is where experience comes in. I agree with this. But I guess the difference is I can think of almost no circumstances where it's the better tool for a coder. |