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?
5 comments:
I think I'm personally pretty tired of folks on the ALT.NET namespace constantly renaming stuff. "Test" is now a "Fact", "TDD" is now "DBE", "Overhead" is now "Underfoot". Up is DOWN, Smart is DUMB.
There's a "cost" associated with utilizing these tools and techniques. There's also a "cost" for NOT using them (a much steeper, gradual, and insidious cost).
I think we have to start thinking about what we're doing with all these "new names". What are we trying to accomplish? I don't need to sell my development team on this stuff; they buy in because they can see the benefits in the way they work every day. The people I need to get to buy into our methods are our product owners, customers, etc. They don't understand "underfoot", but they understand "overhead". And when I explain to them the costs of each way of doing things, and the gradual, insidious cost of not using these techniques, they get it.
@ChrisHolmes,
Well, the whole post was somewhat tongue in cheek. I just happened to find the idea amusing.
My perspective on Alt.Net nomenclature is simply that we are reinforcing our community identity and culture through language.
Sometimes the result is silly (underfoot, soluble) and sometimes it is quite useful (SOLID). Only time will tell in the end what, if any, of this process matters.
I was talking to someone yesterday on how many moving parts are added to the way we program.
The difficult part is that there are 5 alternatives for doing 1 thing. For DB, there is ADO.net, nhibernate, linq to sql, entity framework, data services etc
I am sure MS and Alt.net is inventing a new one as I write this.
Can't there be tried and tested way of doing things rather than coming up with new way of doing things every few months?
@Kalpesh
Stagnation is death. There will continue to be churn in software frameworks until such time as the details become irrelevant or uninteresting.
The important thing is to make an informed decision upfront based on what's available, what you know, and what you are willing to learn. Settle on those conventions and move forward.
Then on the next project you need to reevaluate your position depending on how far the technology has progressed.
I think the diversity of frameworks is a good thing. They reflect different perspectives and interpretations of the software design problem, much as paintings of the same scene by different artists differ in form, focus, context, narrative and execution.
True. Stagnation is death.
Yet, going at a neck break speed is dangerous.
When you say foundation, it seems that every project needs to write their own foundation layer (db, logging, serialization etc)
I would like to see a time where people don't really have to write these things on each project. I think, this is what business considers is as "overhead" or "underfoot" :)
I commented somewhere saying - does business care whether you use a for loop on a collection or linq?
I admire your views. But, IMO re usability is overrated. Considering there is some common code between all the frameworks with different perspective trying to achieve similar goal (orm, linq example).
Post a Comment