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

Don't celebrate before the victory

"Success is a lousy teacher. It seduces smart people into thinking they can't lose." Bill Gates

Energy and persistence conquer all things

"If I had to select one quality, one personal characteristic that I regard as being most highly correlated with success, whatever the field, I would pick the trait of persistence. Determination. The will to endure to the end, to get knocked down seventy times and get up off the floor saying - 'Here comes number seventy-one!'" - Richard M. DeVos

Even winners lose sometimes

Charles Lynch said "You can't be a winner and be afraid to lose". Don't let fear guide you.

Drucker about leadership

I came across this quote from Peter Drucker and couldn't resist to publish it here.

“Effective leadership is not about making speeches or being liked; leadership is defined by results not attributes.”

Indeed.

Web frameworks - looking for QWAN

IPM has published results of the "Pre-requisites of a Good Framework" poll. The answer options were:

• Strong separation of data
• Web 2.0 support and preferably libraries built in
• Strong naming conventions and smart English recognition
• Robustness (ability to handle large volumes of traffic and data)
• Rapid development features (scaffolding etc.)
• A great IDE (preferably Eclipse)
• Others

Christopher Alexander (his works inspired the Gang of Four), described a feature which some buildings possess and some do not. He stated that it is not measureable, but you can just feel it. He called this feature Quality Without A Name (1, 2).

My requirements for the good framework aren't about the technology. They are rather about the feelings I look for when evaluating the framework. They are about the Quality Without A Name...

So here are my Alternative Pre-requisites of the Good Framework:

• gives you well-thought, clean "frames" to work within - easy to understand paradigm of thinking about app, directory stuctures, etc. letting you avoid a "design paralysis"
• makes you feel natural and comfortable when working on the application - eases things, instead of making it harder
• is documented well enough, the docs are not over-detailed, but friendly and easy to use
• doesn't try to be everything for everybody - is focused to solve selected class of problems

Where have I found Quality Without A Name in the world of web frameworks?

• Java - Spring Framework
• Ruby - Ruby on Rails
• PHP - Code Igniter

Of course those choices are based on my subjective feelings (not comparison of features). Every one of them provides its own way of doing things, very specific to the language and the areas of intended applications.

Software development is not construction

Three days ago I've posted my opinion that technical competence is required for PM managing IT projects. Of course understanding technology is not enough. PM should be aware of an essential difference between software development and traditional construction-type projects.

Software development is not construction engineering, where most activities are repetitive and can be described in a detail by the procedures or automated. Kidd distinguished such kind of procedural work from the effort of knowledge worker, who's job is based on creativity and communication. Therefore software developer should be considered designer because, as Reeves pointed - code is the design. Moreover, in software all the effort is design, as stated Fowler.

Every design activity is more similar to research than the production. Design is hard to schedule, because of its very nature. Conklin and Weil have studied the designers behaviors and concluded that solving complex problems (design is such activity) is non-linear, chaotic and nearly impossible to plan - "the flow of their [designers'] thinking was full of upredictable leaps" (Conklin, Weil - "Wicked Problems: Naming the Pain in Organizations").


Figure 1: Actual pattern of problem-solving activity of one designer - the "seismograph" (source: Conklin, Weil - "Wicked...") [click to enlarge]

Also Fowler says that creative processes are not easily planned, and so predictability may well be an impossible target. This could be one of the reasons of the failure of applying the deterministic project management techniques to software projects.

It is important to understand the essential difference between traditional construction engineering and software development. Those who don't get it, won't see anything wrong with building a bridge an agile way :).

UPDATE (2005-07-18): Mishkin Berteig pointed me to the article supporting my argument. Really worth reading. Thanks Mishkin!

Can you manage something you don't understand?

As a leader managing IT project you must have technological background or - at least - deep understanding of project domain and technology used by your team. Without clear vision of what and why your people do, you won't be true leader. You won't be able to freely communicate with your team.

Goleman describes 6 leadership styles (Goleman et al, "Primal Leadership"). He values the visionary style as the most effective. Visionary leaders lead through inspiration of the people to achieve common goal, they move them towards a 'shared dream'. But Galford and Drapeau claim that the real leadership takes more than inspiration - it takes a trust between the leader and his team. The first step to build trust is to show understanding of the needs of team members and the group as a whole (Galford, Drapeau, "The Trusted Leader"). How can you understand their needs if you're not able to understand what they do?

That was Machiavelli who said: "And therefore a prince who does not understand the art of war, over and above the other misfortunes already mentioned, cannot be respected by his soldiers, nor can he rely on them." (Niccolo Machiavelli, "The Prince").

Dilbert would probably get my point :)