if your using a good ticket tracker (Such as Jira from Atlasian) and you've spent time entering all the different categories, user stories, urgency levels correctly and with the agreement of your team mates, then actually calculating these metrics (and more) are amazingly easy.
On a previous project, we used Jira to manage our bug/task/todo lists, and in the end it actually showed us that the biggest cause of delays and problems turned out to be inefficient management practices.
Strangely enough, when that information came out, we where suddenly told that we would no longer be using Jira, and that a new product would be brought in to replace it.
In the mean time, all requests for data to be passed through Jira had to be sent to the management team, and we had our direct access removed.
What wasn't noticed was that as part of the stats calculation, the dev team had Jira poking data to a web hook, and this web hook was used to pass data to an end point on some internal servers, where we had code that created these reports automatically.
We started monitoring the web hook, and found that even though we where told that Jira was no longer used, it remained very much alive for a considerable amount of time longer (6+ months to be exact) and the wholesale abuse by upper management was just plain rampant with incorrect use.
Of course, it doesn't have to be something as complex as Jira.
If you want a low yield solution, you could use a google-docs spread sheet, and the GDocs notification API, to track tasks/tickets/bugs/feature requests etc.
GDocs itself can now issue web-hooks and all sorts of things.
Couple that with Git and/or Github and some hooks that trigger when code is committed to your repository, and you've got a reasonably efficient home brew system, that can record a surprising amount of data.
In general however, out of 100% of a products natural lifetime, the split between greenfield dev and maintenance is generally 20/80, most of the cost in the ALM (Application Lifetime Management) cycle is taken up on maintenance and support costs.
There's no such thing as spending too much time fixing bugs, beacuse it's simply not possible to write bug-free code.
Good testing and continuous integration policies will reduce the deficiet , but you'll never completely eradicate it.
Anyone who believes otherwise (IMHO) doesn't have enough knowledge to make an acurate judgment, or is blind (The more usual case) to just how difficult it actually is to write software.
If your manager is up for it, and some of them are, then you might want to suggest that he shadows you for a day, so he can see exactly what you do and how you do it.
Iv'e worked in a few companies where this kind of work was actively encouraged, with upper level staff shadowing lower level staff, and vice-versa, it can be a really, really good learning experience for both involved parties.
