Every now and then we talk about the "overhead" associated with implementing better practices.
For example, designing a stratified architecture requires some up-front planning to separate the tiers, identify roles, decide on the interfaces, establish conventions, and resolve cross-cutting concerns. During implementation, there will almost certainly be additional code required to marshal messages across tiers, additional configuration required to glue them together and additional infrastructure required to host them. Quite probably the team will also need to learn new skills and adopt other ancillary design/implementation practices at the same time to make it all work out. This effort all takes time, effort, and money.
Likewise adopting TDD/BDD/DbE, using continuous integration, leveraging IoC, adopting one-way asynchronous message passing (instead of RPC), applying command-query separation, and "going SOLID" all have one-time and recurring costs... (and benefits of course.)
I think "overhead" is a misleading label for these costs. It presumes that the costs are excess terms that could be eliminated through greater efficiency. However these costs in fact purchase greater efficiency. They are an investment in laying a foundation for future. They pad the space under our feet not the space over our heads. They let us reach greater heights!
Let's try this paragraph with underfoot instead of overhead.
Building this proposed multi-tier platform will have an initial 20% underfoot while we retool and lay the foundation. Once that is done we will be 50% more efficient though we will have to spend an additional recurring 5% underfoot to keep the axles greased.
Which do you prefer?