Occasionally, I do, that is when writing Excel macros in VBA (Visual Basic for Applications, Microsoft's Visual Basic flavour for macros). The reason why I do

Occasionally, I do, that is when writing Excel macros in VBA (Visual Basic for Applications, Microsoft's Visual Basic flavour for macros). The reason why I do this is that the - for better or for worse - the world runs on Excel and some things (e.g. reporting, ad-hoc conversion of CSV data), especially one-off solutions (I know, nothing lasts as long as a prototype in production ...), are faster to implement in Excel and will also be more readily accepted by users because Excel often is what they know already. The language is alright, the IDE within Excel, less so. I try to write VBA in a maintainable manner but especially with Excel's macro recording feature it's possible to create quite messy code. Macro recording is fantastic for bootstrapping functionality but you have to edit the resulting code if you want it to be maintainable further down the road. Other developers often frown upon Visual Basic and don't consider writing VBA code in particular to be "proper software development" but it gets the job done and that's what counts.