Lots of great tweets and links this week too! Randomly ordered:
- @martinfowler Eric Evans explains why encapsulation is for objects not for people OMA: 2 min video. watch it :)
- @raganwald “Python vs. Ruby: A Battle to The Death” OMA: 28 min video. In short, he feels python is more beautiful, but the ugly Proc of Ruby enable beautiful stuff like RSpec to happen.
- @anderssv: blog: Hibernate performance and optimization OMA: Using an ORM like Hibernate? Then this is a MUST READ.
- @Tordf RT @bishoph Agile. Scripting. Git. NoSQL. Haskell. Top 5 Trends In Software #Development via @eabarquez | simple sum-up
- @kristfh NoSQL going mainstream OMA: Another, “I love noSQL and hate relational dbs” with a comments section of “you’re a dork, relational dbs will win this one too”, I’m guessing the title is false, but too me, the noSQL dbs like MongoDB, redis, couchDB and many more, looks really interesting, and promising.
- @gregyoung interesting article luck its an easy skill to learn OMA: You decide whether you’re lucky or not. A study of lucky and unlucky people. Eye-opener!
- @gamsjo RT @bjartek: true simplicity is about minimizing and managing overall complexity God oppsummering! OMA: You know KISS? Keep it simple, stupid? To me that says, “it’s stupid not to keep it simple“, not to be confused with “stupid simple”, which is like deliberately being an idiot (no, that’s not a good idea). This article is a must read, IMO. I didn’t really catch the “simplistic is not good”-part, but maybe that’s because english is my 2nd language. Wrap up: It’s not news, but we all need to be reminded of this stuff.
- @Tordf RT @MrPaladin 25 alternative database management software #programming |recommend trying alternatives,might surprise you OMA: it says recommended, he’s not lying!
@debasishg: A good abstraction has the side-effect of making lots of boilerplates disappear .. #higher_level_of_abstraction
@unclebobmartin: Showed a little lisp to my 8yo grandaughter. She “got it” immediately. Now I’m looking for good logo implementations to teach her.
… before I leave for a weeks vacation in the Norwegian mountains, with snowboarding, outdoor hot tub(?), beer and lots of great books(lean, agile coaching, scala, clojure, art of scalability)
ABOUT KISS and GOOD ENOUGH
From Simple ain’t Easy: Myths and Misunderstandings about Simplicity (one of the bulletins above).
[…] it means that the partial/incremental solution must be easy to subsequently change in order to refine and improve!!!
If I install something that is incomplete with the intent of making it more complete, and if it is very hard/painful to change, then I may end-up with the current-state-of-affairs for a number of IT solutions and business-processes: short-sighted, insufficient solutions that the organization defends, and chooses to suffer and impose on others because they don’t want to suffer the impact of the change that could bring about relief from the suffering they have become accustomed to living with.
This was written in 2006, guys, I’ve been working with cultures like the latter (impossible to change proven bad code, mostly due to lack of will) in 2010. DESIGN/FACILITATE FOR CHANGE, not only because of changing business demand, as in “embrace change”, but as an acknowledgement of your upfront design incapabilities, understanding that you’re acquiring greater knowledge about the problem at hand as you’re developing your solution. Keeping the feedback cycles short (as in agile/lean), getting valuable information on the table, which you may (should) act upon. This is what I, as an agilist, stress to push. It sounds easy, should be easy, but real life proves me that it’s not. Because people are involved, we need agility. Because people are involved, agile is so damn hard.
This turned out to be a rant, I’m sorry about that. Have a beautiful week!