I dived into learning what I consider my weakest area, Internet Marketing, and it’s a project that absorbs almost all of my spare time.
If you ask a solution provider, any solution provider, if their solutions were “intelligent”, you can bet you won’t get a single “no” answer. Consequently, every solution out there is intelligent, right? But is it?
Some time ago, I wrote about John, the fictive trekking leader, who came to fame and glory out of ignorance, and drew parallels to project management today. As it turns out, I didn’t have to invent a fictive story to illustrate the situation – there is an astounding historical example that backs it up 100%.
On this terrific Wikipedia page about common misconceptions, I found this: Read more >>
In “The Costs Of Not Doing Something Else“, I made the aside conclusion that John’s trek only needed to meet some minimum criteria in order to be considered a success. That is an inherent property of what can be called an uncompetitive system.1
Coming back from treks to projects, I state:
Read more >>
- An uncompetitive system is a system lacking comparison to other systems of a kind. [↩]
I finished my last article on the project management topic with the thought:
It is common to measure the cost of what we do. But how do we measure the cost of what we don’t do, or don’t do differently?
In essence, it’s a question of how to measure the relative advantage or disadvantage of doing things one way or another.
To exemplify, I’d like to metaphorically use the notion of a trekking leader. (In many ways, a trekking leader is a good metaphor for a project manager, I believe.)
I’m talking about the kind of “project” defined purely for administration purposes, and otherwise lacking the immanent properties of a real project, such as, and most importantly, a defined goal, and a limited time.
In my prior articles, I wrote about my views on simplicity, my objections to putting diffuse concepts into seemingly straight rules, and the risk of unintentionally sending the wrong messages therewith. Since then, I seem to keep stumbling upon stuff that somehow adds to my position.
In two recent posts, I wrote about the notions of clever and dumb code, and the possible implications of their usage in their every-day language. There’s a particular point of interest related to these posts:
A common – and very understandable – motivation for requiring code to be “dumb” is the reasoning that if the code was dumb, then less skilled – and less paid – programmers could take on software development.
This is anther example how doing (or thinking) the “obvious” is a clear sign of shortsightedness.