I've been pushing this idea for the past couple of years with clients, and when I give talks at conferences. The fact of the matter is that unless an organizat

I've been pushing this idea for the past couple of years with clients, and when I give talks at conferences. The fact of the matter is that unless an organization knows what the carrying cost is for their features, and the effect in terms of complexity, they are flying blind. In essence, it is Joel's Law of Leaky Abstractions at work. You can't manage a software project just in terms of a set of features you agree upon with business. The codebase is a key constraint that underlies all of those discussions and unless the effects of feature choice are on the table, you end up incurring radically different costs. This isn't just about paying attention to technical debt. It's about having the discussion about whether it is worth targeting some features or not, taking the code into account - using it as a factor in business decisions. http://www.confreaks.com/videos/717-rockymtnruby2011-opening-keynote-code-blindness http://www.confreaks.com/videos/717-rockymtnruby2011-opening... http://michaelfeathers.typepad.com/michael_feathers_blog/2011/05/the-carrying-cost-of-code-taking-lean-seriously.html http://michaelfeathers.typepad.com/michael_feathers_blog/201...