WTPayne

There will always be a need for people who understand the details. Having said that, building demonstrable product quickly is more important in the early days of an enterprise, so developers really need to be able to switch from one to the other; working at a high level of abstraction early on, when you need to move quickly to disrupt and / or capture a market, then move to a lower level of abstraction to optimize and tune the enterprise to make it more efficient within it's niche.

Information overload is definitely a problem; too many disparate pieces of information, too many new languages and technologies to learn, too many priorities at work; too many interruptions... (too much caffeine) all of this leaves me in a constant state of near-panic. What I feel I really need is a sort of automated PA / life coach; to help prioritize (home & work), schedule; simplify and motivate. Something that takes the clutter and noise of the world and blocks most of it out, most of the time, feeding me what I need to know, when I need to know it, and keeping me on track.

Yesterday, Joel Spolsky talked about Software Inventory (http://www.joelonsoftware.com/items/2012/07/09.html), and mentioned a minimalistic project management tool that he would like to see made called "Five Things". Well, I think that we have a bigger problem of Intellectual Inventory - a glut of information, too many books, academic papers and articles that sit on the to-read list, all relevant, all interesting, and not enough time left in our life to digest it all. (It is true ... I did the sums - I have about 300 years worth of reading in my backlog)

So here is my problem: Intellectual Inventory management; productivity optimization; focus management.

Love it!

Well, everything that jmolly says is true, but decoupling data and functional behavior is only part of it. Indeed, OOP was designed specifically to couple data and behavior together, so some people (at least) think that this is a good thing.

In my mind, the difficulty lies not with OOP per se, but in the thought-patterns and practices that have grown up around modern OOP programming, and the mental confusion that we have between the construction of models, the design of algorithms, and the creation of machines to help solve a particular problem. To a large extent, we lack the intellectual tools required to understand the problem; or, at least, the use and understanding of those tools is not widespread.

Personally, I suspect that there is a significant difference between product-centric thinking (design the product, ignore all else), and product-line-centric (or capability-centric) thinking (design the machinery that will make it trivially easy to design the product). This, for me, is a more important distinction than OOP vs FP, or any other dichotomy that you might care to mention.

I am not suggesting that I am right here, mind you: this is just the way that I feel; my gut instinct ... so perhaps some Socratic questioning might be in order here:

Let me start.

What problem, as software developers, are we actually trying to solve?

Better programming tools; particularly mutation-based fuzz-testing tools; code structure visualisation; statistical, nonlinear code quality metrics, structure-based code similarity metrics and similarity-based code search/suggestion; better linting & static analysis tools; refactoring tools that integrate with unit tests; continuous testing tools; better documentation for existing tools.