EDABlog

Loved this post  so had  to emphasize and post it.

"That's not the case. A framework user doesn't give a **** about how many different patterns the framework is using and how great and awesome it's internally and how it will ultimately evolve in the bringer of world peace. A framework user is interested in whether the framework takes care of things the framework user can't afford to spend time on. After all, the framework user can't afford to spend time paid by the customer on plumbing, on writing infrastructure code. The framework user is paid to write code directly related to the problem at hand: the application for the customer. No customer should accept that the team hired for writing the line-of-business application has spend time on writing a report-control or for example a grid control. So why should a customer accept to pay for time spend on other plumbing code? Just because the customer doesn't know any better? If so, isn't that erm... taking advantage of the inability of the customer to judge what the 'software guys' did was correct?

Yes, it's that extreme. The software industry should grow up and realize that it shouldn't be acceptable anymore to write frameworks and framework code, plumbing code etc. paid by the customer, just because the customer doesn't know any better. And we, the software developers, should grow up and accept that the job many of us have isn't to write plumbing code and infrastructure code, but to write code using the plumbing available. If the plumbing at the place where you work is broken, it's very likely that someone will call a plumber to fix it. So why accept that if the plumbing used for a project is broken, one has to fix it themselves? With all the bugs, loss of time, focus and ultimately: money, as a result? "

I dont think its extreme at all , the same attittude in the industry is pervasive ( See where has the productivity gone) . The industry routinely delivers software that is over engineered for the job and the additional code and complexity instead of reducing maintenance actually makes support and maintenance more costly.  This also applies to implementing SOA  and EDA architectures for organizations which are too small to see the benefit.