The Dark side of Dependency Injection

I have been thinking about dependency injection from time to time. I have long suspect that the issue of couplings being adressed by DI framework must have given rise to some problems elsewhere. There is no free lunch. Remember whack-a-mole syndrome?. Like a nuclear reactor with almost indefinite energy production and  yet generate those radioactive waste as the consequence of operating one. The following article "This dependency injection madness must end!" highlight problems created by  using DI framework. Notable quote from above article:

First, understanding which dependency is actually used (and why!) can require a lot of brain power: It will require you to consider all possible configurations when you look at a dependency and it will not work well with the normal code navigation functionality of your IDE. Second, the configuration will tend to deteriorate: When you no longer use a dependency, will you check whether you can remove it, or will you just leave it there to be safe?

America need more Edwin H Lands..

My wife and I were taking our kids to the Museum of Science, Boston(MOS) since they were out of school for a day since their school being used for yesterday's November 2, 2010 mid-term election.
By chance, I came across poster board this relating to Edwin Herbert Land, one of the early pioneer in photography at the MOS..

Above link says, "In the matter of U.S. patents granted, Land (with over 500 to his credit) stands second only to Thomas Edison."

I can't help but notice this quote attributed to him:

"An essential aspect of creativity is not being afraid to fail.."

That "Lambda Calculus" thingy again, please!

I came across this presentaion on InfoQ last week and tried to listen to the speaker talking about Functional-Languages-101
No doubt, the speaker is qualified, but after 5mins, she starts to mentioning the term "lambda-calculus" thingy. The presentation starts to smell "academic".
The speaker forgot that her presentation slide has a "101" to it.
Therefore, her presentation joined a long list of  unsuccessful FP proponents and evangelists who failed to convince the masses of the power of FP. Sorry. Nice try.
Someone commented on the presentation sums up my thoughts nicely, which I quoted verbatim:

"Without diving into the discussion of imperative and Functional Programming (FP), my biggest concern about FP is not that we as a programmer don’t understand what a FP is all about; but how to write reusable and readable code.

All the experts feeding us the idea how beautiful FP is, never mentioned a single word about code reusability and readability. OO paradigm has been a success not because it was technically superior than Functional paradigm and vice versa, but because you can see the whole software as a blue print just looking at the API, and it is so easy to maintain and read someone else code.

I don’t claim to be an expert of programming paradigms especially FP, but say it for surety that no FP expert can convince you that reading and maintain the FP code is the easiest thing to do."

Agile from Hell

Today, I came cross this InfoQ posting on Agile by Karthik Dinakar.

Agile Development: Overcoming a Short-term Focus In Implementing Best Practices

After watching it, I would termed this as "Agile From Hell".
The sad thing is that the Engineering Manager has 12+ years experience from CalTech and the Product Manager  has a business degree with SCRUM certification.

One can't help but thinking whose eyes these two dudes are trying to pull wool over, considering that they don't even implement the very basics of Agile!!. Shame on them.
The saddest part was admitted by the speaker, " They still retain control over the design..". Power struggle?
Having done SCRUM before, I really sympathized with the poor chap.

Warning: Cloud KoolAid

I came across this presentation by Chris Read in QCon The-Cloud-Silver-Bullet: Which Caliber Is Right For me? It's worth watching this presentation to avoid drinking the cloud koolaid or cloud bubble burst.

May the Best Attitudes wins...

I came across this quote in a forum. Someone posted this question about the choice of hiring someone who has...

1) Excellent skillset, poor Attitude 

2) Excellent Attitude, average skillset.
Who would be your choice and why ?? 

Who would you hire and why?. I think the best answer is posted by someone with a quote from Charles Swindoll:

“The longer I live, the more I realize the impact of attitude on life. Attitude, to me, is more important than facts. It is more important than the past, the education, the money, than circumstances, than failure, than successes, than what other people think or say or do. It is more important than appearance, giftedness or skill. It will make or break a company... a church... a home. The remarkable thing is we have a choice everyday regarding the attitude we will embrace for that day. We cannot change our past... we cannot change the fact that people will act in a certain way. We cannot change the inevitable. The only thing we can do is play on the one string we have, and that is our attitude. I am convinced that life is 10% what happens to me and 90% of how I react to it. And so it is with you... we are in charge of our Attitudes.”

-Charles R. Swindoll

Myth of the Genius Developer

I came across this posting "Myth of the Genius Programmer" today.
This is a very well presented Google IO video presentation.
I strong encourage  you or your development team  to take time to watch this video.
Also, a good video to watch if you are hiring developers.
If your team has the following traits:

 1. Resistant to code review...
 2. Tribal knowledge that few knows...
 3. Existence of "hero" developers("elitism")....
 4. Reluctant to help each other...
 5. Has low project productivity....
 6. No visibility...
 7. Skill rots over time...
etc.
Recognize yourself or your team with these traits?
Then its time to change or get out.

Quote from above video:

"There is a pervasive elitism at work in the programming community. Add anonymity to the mix, and everyone is suddenly  elite."

Search Engines and energy consumption: Deja Vu

Google is in the news again. This time for something more salient:  Google Energy LLC.

At the heart of the Internet search giant is its humongous energy consumptions. Make no mistake, every web pages indexed, ranked and sorted requires computing power. Factor in the upcoming  cloud computing data centers, could this be the new "Big Autos" T-models-equivalent of the 21st century? Deja Vu.
You can't get something for nothing. You can't defy the Laws of  Physics. Extracting information from the web requires energy. Maybe its high time that we have a  web efficiency energy rating of some sort?
For Google to enter into searching, indexing and storing of all imaginable digitized media,
the energy consumption can only go up and not down. More social sites and probably more specialized sites will spring up to take advantage and harvest newly available info: explosion in "infomation plantations".
That in turn means more energy consumptions. More oils and coals. And more CO2.
This raises the issue of Cloud Computing's carbon footprint. ElasticVapor has an article on this that sums it up succintly:

"Then there is the question of consumption, we now have the ability to run our applications on thousands of servers, but previously this wasn't even possible. To say it another way, we can potentially use several years worth of energy in literary a few hours, where previously this wasn't even an option. So in direct contrast, hypothetically we're using more resources, not less. On the flip side, if we bought those thousand servers and had them running (under utilized) the power usage would be significantly higher. But then again, buying those servers would have been out reach for most, so it's not a fair comparison. There we are -- back, at where we started. You may use 80% less energy per unit, but have 1000% more capacity which at the end of the day means you're using more, not less energy."

Functional Language: Gut feelings

In my last post, I written about my email to Barbara Liskov and raised some issues about Functional language.
I let out my feeling that something is not "right". That gut feeling.
Today, I came across Ted Neward's blog post on his 2010 prediction.
One of  his 2010 crystall ball point  seems to resonate with what I was trying to express then.

Quote:

"... functional languages will start to see a backlash. I hate to say it, but "getting" the functional mindset is hard, and there's precious few resources that are making it easy for mainstream (read: O-O) developers make that adjustment, far fewer than there was during the procedural-to-object shift. If the functional community doesn't want to become mainstream, then mainstream developers will find ways to take functional's most compelling gateway use-case (parallel/concurrent programming) and find a way to "git 'er done" in the traditional O-O approach, probably through software transactional memory, and functional languages like Haskell and Erlang will be relegated to the "What Might Have Been" of computer science history. Not sure what I mean? Try this: walk into a functional language forum, and ask what a monad is. Nobody yet has been able to produce an answer that doesn't involve math theory, or that does involve a practical domain-object-based example. In fact, nobody has really said why (or if) monads are even still useful. Or catamorphisms. Or any of the other dime-store words that the functional community likes to toss around."

I would hate to see Functional Language assuming the status of  Brahminian dialect, like Latin.
But again, who is to say folks are not motivated to learn and master Latin?

Veni. Vedi. Vici. 

On Barbara Liskov's Power of Abstraction, Functional language and PCP

Barbara Liskov  OOPSLA keynote at InfoQ site is worth listening to. 

She is best known for formulating the Liskov Substitution Principle(LSP)

Her presentation is very clear and well-delivered.

She's is not convinced of functional programming and emphasized readability and hinted  that DSLs could introduced cacophony into the language landscape.

Managed yesterday to fire off an email to her about some concerns I have about Functional language. After all,  I have begin to dip into Clojure for a few weeks now.

I got a reply this morning.

The gist is that readability may not be an issue with Functional languages but it could be due to something else. I felt that something is not natural or right. Maybe its my time and familiarity with Object-Oriented language for long time?. Or is it a paradigm change?.

Could Functional language be walking down the metaphor road of the new Sorcerer's Apprentice?

"That old sorcerer has vanished
And for once has gone away!
Spirits called by him, now banished,
My commands shall soon obey.
Every step and saying
That he used, I know,
And with sprites obeying
My arts I will show"

I don't know but I hope  PCP ("praise, certainty and perfection") is not at work. 

Only time will tell. Meanwhile, I got a copy of "Programming F#" by Chris Smith and started to read it for comparison with Clojure.