I work with VBA now since 15 years. I used it for multiple purpose in automotive industry - getting measurement files with more than 36. entries (1 hours every 1 seconds) and get them into customized excel diagrams for reporting - reading or creating simu structures and use them for example in a signal database list - visualizing requirements and functional strutures from databases or lists by representing them in powerpoint blocks -parison of lists of requirements by retrieval (for example for review purposes) - formatting merging splitting excel cells in several lists The list of useful tasks which can be performed with VBA is actually infinite. The major point is to know and decide when it is useful and when not. From my point of view and personal experience VBA is only useful when you have a recurrent high load of huge repititive tasks to perform under time constraint. In order to decide it properly following main criteria have to be evaluated - time to develop the macros (depends on the skills of the developer) vs time of performing equivalent manual work - consistency and correctness of the results - usability and maintainability of the scripts Time constraintsn The time of macro development should be considerably shortpared to the manual work. So for example if you have topare twice 3 lists of 1 entries it can take manually (with rapid reading skill no help of excel formula and by remaining full concentrated) 2 hours. A well experienced macro developer would take 2 minutes to program it and the macro would execute the task in maximal 3 seconds. If the task is performed more frequently then you will have a big time gain. Consistency and correctnessn Nevertheless it is important to test the script in a proper manner. The most efficient way is to perform spot manual verification checks on a reduced set ofplex data (e.g. cells with long containing special characters and line feed) and also during the use of the tool always to maintain critical eyes on the results. Usability and maintainability nThe most difficult thing by programming a macro is to document it properly because while you program it you are in a deep flow of thoughts and just think about the results. At the end when your script is working you are happy and sometimes exhausted so you don't think anymore about documenting it or you put just a fewments. A good programming habit is always to put usefulments in your code and trying to section the code as logically as possible. Ideally you should at least create a structogram for it. The point is when you are not (anymore) available and the users or your successors want to modify or debug the code then maybe it would be a big challenge for them. Also you have to provide a simple manual and develop the tool for safe and simple usability (make the tool foolproof usable). Since 15 years I work in automotive industry mostly on high system level. That means my work consisted of analyzing or specifying the systems on high level. So it was never the question of programming the system software. Therefore most of time my team leaders (with some exceptions) and colleagues had low skills in coding and were not able to evaluate the efficiency of VBA. Most of time VBA was considered like a kind of exotic add-on and people were always sceptical about it. So if you want to convince someone of using VBA in your team or daily work you have to fulfill the criteria above and demonstrate this fulfillment.