Pick one (or more):
* they don't know the alternative
* they're afraid to speak up and sound un-cool
* they don't realize it's actually killing their ability to focus
* they do so privately and are ignored by the higher ups
Audio-visual distractions have proven to be detrimental to focused, "intellectual", work. Not by an article on Medium, but by actual research. Time and time again and again, ad infinitum.
Open office is the anti-vaxx of today's tech world, where all known data is ignored in favor of superstition.
 https://www.amazon.com/Peopleware-Productive-Projects-Second... http://www.news.com.au/open-plan-offices-make-you-sick/story...
Project Management with Respect to Time and Budget
There are a couple of books you should check out:
Joel Spolsky posted a quick estimation technique.
I found this software project management blog.
I attended a Project Management class (as part of a Masters in Technical Management) and they used the Project Management: A Systems Approach to Planning, Scheduling, and Controlling book. It is a very dry book but has a ton of very useful information; luckily our professors were pretty good at their job (one topic that helped me a lot was dealing with conflict -- but that has little to do with estimation and budget which your question seems to focus on).
I think that the book, Micro-ISV: From Vision to Reality, discusses that. Basically, you should already have established a relationship with some people that represent your customer base and who have cobbled together a crappy solution. If your software represents an elegant solution that fixes their needs, you ask them 1) would you use this if it was free? If they say yes, then you ask them 2) Would you pay a million dollars for it? At which point they'll say, no way, the most I would pay would be $500 (or whatever) -- that's one way to price your product. :)
If you are going to be managing people, read these books:
by Tom DeMarco and Timothy Lister
alt text http://ecx.images-amazon.com/images/I/51MlUgcSICL._SL500_BO2,-64_OU01_AA240_SH20_.jpg
This classic book encourages us to think about the people instead of the process. It's full of practical advice on team building, productivity and office environments. It's a must read, not just for managers, but anyone related to software development.
Get two copies, one for you and one for your manager.
Interestingly I just finished reading PeopleWare, and the authors strongly discourage individual metrics being made visible to superiors (even direct managers), but that aggregate metrics should be very visible.
As far as code specific metrics I think it's good for a team to know the state of the code at the current time, and to know the trends affecting the code as it matures and grows.
The question is obviously not focussed on .NET, but I think the .NET product NDepend has done a lot of work to define and document common metrics that are useful.
The documentation section on metrics is educational reading, even if you're not doing .NET.
"The most surprising part of the 1985 Jeffery-Lawrence study appeared at the very end, when they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others (see Table 5-3)."
Table 5-3 Productivity by Estimation Approach (Full Result)
Effort Estimate Prepared by Average Productivity Number of Projects
Programmer alone 8.0 19
Supervisor alone 6.6 23
Promgrammer & supervisor 7.8 16
System analyst 9.5 21
(no estimate) 12.0 24
Peopleware: Productive Projects & Teams http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...
Delivering Happiness: A Path to Profits, Passion, and Purpose http://www.amazon.com/Delivering-Happiness-Profits-Passion-P...
Rapid Development: Taming Wild Software Schedules http://www.amazon.com/dp/1556159005/?tag=stackoverfl08-20
The Five Dysfunctions of a Team: A Leadership Fable http://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fabl...
Fundamentally, cultivating a healthy team culture is the most important role you can play. Foster open, transparent communication, and avoid falling into the trap of micromanagement. Keep things happy, keep it real. All the best!
In my case, I'd like him to read Fred Brooks' "The Mythical Man-Month", to make him understand how a programming system costs a lot more than a simple module.
"The art of multiprocessor programming", excellent book on parallel programming theory with code explanations: http://www.amazon.com/gp/product/0123705916?ie=UTF8&tag=nirs...