Great question about what I mean by managing an add-in. What I mean is how do you maintain appropriate control over its whole lifetime.
If you consider the lifetime of the app (well if you did you would be in the smallest of small minorities!):
- You need to develop an understanding of what is needed
- come up with some idea on how best to implement the conflicting requirements
- build it
- test it
- Get it out to the users
- maintain it’s operational integrity
- make corrections, updates and enhancements
- facilitate appropriate removal
I guess I’m talking about 3 onwards, or perhaps 2, maybe 1 if you consider prototyping.
These are partly to do with the actual technology, and also partly to do with the availability and accessibility of code, components, resources etc. So for example the unit test frameworks that target .net are probably a little more mature than those that target VBA.
For C# there is the .net framework itself, and the .net MVP contributions. For C++ there is std and boost and all the open source stuff, for VBA there is all the MVP contributions and a ton of VB6 stuff.
You would have to be pretty blinkered to claim one tech is better than all the others. They each have their place and the most appropriate will depend on many factors, some of which are above, others may be personal to the developer or the client. Existing body of knowledge and skillset are a couple of these that can be very influential, and sometimes in unexpected ways.
I’ll point out the highlights and lowlights that I know about as we go through