Michael Feathers, author of a book on legacy code, writes about software design, testing, object orientation and code complexity.
HN commenters cite his 'carrying cost of code' post on the hidden cost of features and complexity, and note he wrote the book on legacy code.
This reminds me of a post by Michael Feathers, titled "The carrying cost of code" [1]. Feathers wrote the book about legacy code [2]. I think he makes approximately the same point:
> If you are making cars or widgets, you make them one by one. They proceed through the manufacturing process and you can gain very real efficiencies by paying attention to how the pieces go through the process. Lean Software Development has chosen to see tasks as pieces. We carry them through a process and end up with completed products on the other side.
> It's a nice view of the world, but it is a bit of a lie. In software development, we are essentially working on the same car or widget continuously, often for years. We are in the same soup, the same codebase. We can't expect a model based on independence of pieces in manufacturing to be accurate when we are working continuously on a single thing (a codebase) that shows wear over time and needs constant attention.
[1] - http://michaelfeathers.typepad.com/michael_feathers_blog/2011/05/the-carrying-cost-of-code-taking-lean-seriously.html
[2] - http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
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://michaelfeathers.typepad.com/michael_feathers_blog/2011/05/the-carrying-cost-of-code-taking-lean-seriously.html
That's just the fat model approach. It suffers from similar issues as fat controllers, whereby unrelated functionality tends to accumulate.
Why do models know how to persist themselves? Or send themselves over the network? What does that have to do with the concept they represent? It conflates technical concerns ("how do I serialize myself?") with business concerns ("am I valid?").
It doesn't help that Core Data forces you into the framework superclass antipattern: http://michaelfeathers.typepad.com/michael_feathers_blog/2013/01/the-framework-superclass-anti-pattern.html