"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
Sunday, November 26, 2006
Even winners lose sometimes
Charles Lynch said "You can't be a winner and be afraid to lose". Don't let fear guide you.
Monday, October 23, 2006
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.
“Effective leadership is not about making speeches or being liked; leadership is defined by results not attributes.”
Indeed.
Friday, July 14, 2006
Web frameworks - looking for QWAN
IPM has published results of the "Pre-requisites of a Good Framework" poll. The answer options were:
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:
- 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
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
- Java - Spring Framework
- Ruby - Ruby on Rails
- PHP - Code Igniter
Thursday, July 07, 2005
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!
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!
Tuesday, July 05, 2005
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 :)
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 :)
Subscribe to:
Posts (Atom)