Tension

"The time has come when the normal revolt against time, space, and matter must assume a form not overtly incompatible with what is known of reality -- when it must be gratified by images forming supplements rather than contradictions of the visible and measurable universe."
H.P.Lovecraft (from S.T. Joshi, "H.P. Lovecraft")


Gehry Tower (1999)
Architect: Frank Owen Gehry
Photo by Tim Schredder

Frozen

"Architectural photography can involve a lot of waiting; the building becomes a kind of sundial, while you wait for a shadow to crawl away from a detail you want, or for the mass and balance of the structure to reveal itself in a certain way."

William Gibson - "The Gernsback Continuum"


Fred F. French Building (1927)
Architect: H. Douglas Ives and Sloan & Robertston
Photo by A.Olszewski

It's hard to predict future

Joel Spolsky wrote in 2004 - "Here are a few examples of things you can't really do well in a web application:

1. Create a fast drawing program


2. Build a real-time spell checker with wavy red underlines


3. Warn users that they are going to lose their work if they hit the close box of the browser


4. Update a small part of the display based on a change that the user makes without a full roundtrip to the server


5. Create a fast keyboard-driven interface that doesn't require the mouse


6. Let people continue working when they are not connected to the Internet"

OK, that was just 3 years ago and it's amazing what we managed to achieve.

Frank Patrick on sources of project failures

Frank Patrick has published his thoughts on the sources of project failures. What is different from many such lists I have seen so far is his focus on real-life factors (common especially in corporations) like inter-project dependencies and productivity killing influence of multitasking.

Frank's list:

1. "Failure to appreciate the impact of a multi-project environment on single project success


2. Irrational promises made due to a failure to take into account the variable nature of task performance


3. Irrational promises made due to a failure to take into account the statistical nature of project networks


4. Insufficient identification of dependencies necessary to deliver the project


5. Focus on (and active management of) only a portion of what should be the full project -- a true bottom-line value adding outcome for the sponsoring organization


6. Reliance on due-date, train-schedule, and actual-against-budget-to-date performance to drive project performance, resulting in the wasting of any safety included in the project (to account for 2 and 3 above) and in the effects of Parkinson's Law -- Work will expand to fill (and exceed) the time allowed


7. Wasting of resources through underutilization because they aren't the "best resource" for the job


8. Wasting of the "best" resources through over-utilization, multi-tasking, and burn-out


9. Delivering original scope when conditions/needs change. Flip-side: accepting changes to scope without sufficient analysis of impact on the project (or on other projects)


10. Multi-tasking, multi-tasking, multi-tasking, multi-tasking, and multi-tasking. Commonly thought of as a key problem in multi-project environments, where resources are expected to address tasks from different projects in a coincident time-frame, multi-tasking also impacts single project durations (and wastes safety) when dedicated resources are expected to wear several hats"

Some of those sound very familiar to me. And how about you?

Best practices in library design

John Resig presented some very interesting thoughts on a JavaScript library design based on his experiences with jQuery and FUEL.

John advises how to write a solid API (those ideas seem to be useful not only for JavaScript developers):

• perform universal actions (like CRUD)


• fear adding methods (defer to extensibility, less but more powerful methods)


• constantly review and remove unused code


• provide an upgrade path for deprecated APIs (plugins / extensions supporting obsolete methods)


• reduce to a common root (by finding common usage patterns)


• care about consistency (naming, arguments order)

Here is the presentation video:



Presentation slides are also available at SlideShare:

Rise and fall of the great warrior

Kaoklai Kaennorsing "was the first Thai K-1 Grand Prix winner at Seoul in July of 2004 at only 176lbs, beating fighters of 195 and 216lbs in the process. As well as winning the GP in seoul, two of Kaoklai's other great moments in K-1 came as he demonstrated the true attributes of a great Muay-Thai fighter. Beating the giant 6'5, 258lbs Belarussian Alexey 'the Red Scorpion' Ignashov to a decision over 4 gruelling rounds and his spectacular 1st round KO over the American Mighty Mo weighing in at 273lbs!

Kaoklai has proved time again that being the smallest fighter is no disadvantage by mastering the art of Muay-Thai; with bone shattering, lightning fast techniques and exhibitng immense levels of conditioning and endurance." (from Wikipedia)

"Rudeness is the weak man's imitation of strength." Eric Hoffer

"This plane isn't going to crash. I'm on it." Muhammad Ali

"I have said I'm the greatest. Ain't nobody ever heard me say I'm the smartest." Muhammad Ali

"Never idealize others. They will never live up to your expectations." Leo Buscaglia

You do not win just by being brave

"Those who will play with cats must expect to be scratched." Cervantes