[jrochkind1]

> I identified the point where I complected Drupal and set it on this direction, but that's another article for another time.

I would really like to see that article. Because, I too have been involved in such things, several times, but have not managed to identify exactly where we went wrong (or even convince others that we were going wrong :) ). I think figuring out how to avoid that kind of complexity is one of they key challenges of certain kinds of software these days.

(For instance, some people think Rails has already jumped that shark, some people don't, but I'm not sure even the people who think it has become complectified all agree on when it happened and how it could have been avoided. When I see people starting something new that's supposed to be "like Rails, but without all that needless complexity", I just think, sure, Rails started out simpler than today's Rails too, and you'll end up in the same place (or worse) unless you can come up with an understanding of what went wrong other than "Those other people made bad decisions I would never have made because I'm a better coder", nope, that's not what happened.).

[AdrianRossouw]

you should really read the simple and easy vocabulary guide. It's part of a set of notes about a talk by the author of clojure.

I took so long to get the fourth in this series finished because i needed to get the necessary theory out there first.

http://daemon.co.za/2014/03/simple-and-easy-vocabulary-to-de...

[jrochkind1]

Yeah, I took a look at that when I saw you link to it initially, and will try to find time to read it more carefully and watch the presentation.

I still think actual concrete examples from real world projects would be great. (Maybe the presentation has some).

(That's what I initially thought the 'Beautiful Code' book would be about, but it looked like more about algorithmic cleverness than success in architecting simplicity. Which is good too, but many of us spend a lot more time struggling with the challenges of architecting simplicity)