Archive
Stress Particles
In a terrific duo of videos, George Pransky makes the observation that most people believe unequivocally that stress is objectively “out there“. He makes an analogy with fictional “stress particles“. Ya gotta stay away from places and events that are infested with stress particles, lest your physical health, mental health, and quality of life deteriorate as a result of becoming contaminated.
The fact of the matter is that all stress is man-made. To be more specific, all stress is self-made. Granted, it’s hard to argue that events such as job loss, divorce, moving, and the death of a loved one aren’t stressful, but the intensity of suffering one experiences is person-specific, no?
I think the amount of stress one manufactures for oneself is a function of one’s perceived control over situations and the degree with which one expects to have control. Control freaks who are in environments where they can’t or aren’t allowed to exercise control create more stress for themselves than non-control freaks. Control freak or not, environments where an individual can control his/her activities and influence the environment are perceived as less stressful.
As can be inferred from the diagram, there are at least two ways to increase one’s “unstressful” region while decreasing one’s “stressful” region. Reduce expectations or increase perceived controllability. A better way is to realize the truth of the matter – there is no controllability, there’s only the ability to influence.
Growing Wings On The Way
If you don’t have wings and you jump off a cliff, you better hope to grow a pair before you go splat. With this lame ass intro, I introduce you to the title of the latest systems thinking book that I finished reading: “Growing Wings On The Way“.
GWOTW is yet another terrific systems thinking book from small British publishing house “Triarchy Press“. The book defines and explains a myriad of tools/techniques for coming to grips with, understanding, and improving, socio-technical “messes“. Through numerous examples, including a very personal one, Rosalind Armson develops the thought processes and methods of inquiry that can allow you to generate rich pictures, influence diagrams, system maps, multiple-cause diagrams, and human activity system diagrams for addressing your “messes“. If you want a solid and usable intro to soft systems thinking, then this may be your book.
Biased Comparison
Let me preface this post by saying what lots of level-headed people (rightly) say: “choose the right tool for the right job“. Ok, having said that, take a quick glance again at the first word in this post’s title, and then let’s move on….
Take a look at the diagram below in terms of flexibility and performance. C++ provides developers with several programming style choices to solve the problem at hand and Java (Smalltalk, Eiffel) “handcuffs” programmers with no choice (in BD00’s twisted mind, Java Generics are clumsy and they destroy the OO purity of Java, and thus, don’t count).
Regarding program performance (<- ya gotta check this interactive site out), there’s “virtually” no way that a Java program running on top of an overhead “middleman” virtual machine can be faster than native code running on the same CPU hardware. Of course, there can be the rare exception where a crappy C++ compiler is pitted against a highly optimized (and over-hyped), “JIT” Java compiler .
Nevertheless, a price has to be paid for increased power and flexibility. And that price is complexity. The “learnability” of C++ is way more time consuming than Java. In addition, although it’s easy to create abominations in any language, it’s far easier to “blow your leg off” using C++ than using Java (or just about any other language except assembler).
Having spewed all this chit, I’d like to return to the quote in this post’s first paragraph: “choose the right tool for the right job“. Seriously consider using C++ for jobs like device drivers, embedded real-time systems, operating systems, virtual machines, and other code that needs to use hardware directly. Use Java, or even simpler languages, for web sites and enterprise IT systems.
The main weakness of OOP is that too many people try to force too many problems into a hierarchical mould. Not every program should be object-oriented. As alternatives, consider plain classes, generic programming, and free-standing functions (as in math, C, and Fortran). – Bjarne Stroustrup
Mostly True
“Adding people to a late project makes it later” – Frederick Brooks
If an underway project is perceived as a schedule buster (and it usually is if managers are thinking of hurling more bodies into the inferno) then this famous Brooksian quote is true. However, if the project’s tasks are reasonably well defined, loosely coupled, and parallelized to the extent they can be, then adding people to a late project may actually help it finish earlier – without severely degrading quality.
Alas, the bigger the project, the less likely it is to be structured well enough so that adding people to it will speed up its completion. Not only is it harder to plan and structure larger projects, the people who get anointed to run bigger projects are more likely to be non-technical managers who only know how to plan and execute in terms of the generic, cookie-cutter, earned-value sequence of: requirements->design->code->test->deliver (yawn). Knowledge and understanding of any aspect of the project at the lower, more concrete, project-specific, level of detail that’s crucial for success is most likely to be absent. Bummer.
It’s About The People, Stupid
Check out the chapter names in part III of a brand spanking new “Project Manager‘s Handbook“:
So much for valuing “people and interactions over tools and processes“, no? The closest the book comes to mentioning people is that the word “staff” is mentioned once and “resources” twice. And no, the first two parts don’t emphasize the importance of people either:
So, aspiring young project manager, it’s obviously all about you. All ya gotta do to be successful is mechanistically follow the infallible recipe; dot the i’s and cross the t’s. Fuggedabout developing trusting, helpful, two-way relationships with the people who will be executing your project work. It’s not important or even necessary. All you have to do is: develop the plan, “acquire the resources”, and push the “go” button. 1-2-3.
To be semi-fair, I haven’t (and don’t plan to) read the book. The author may indeed address the thorny issues associated with monitoring progress and product quality, guiding the effort, and ensuring the well being of the people so that they’re willing to do their best – but I doubt it.
Home Grounds
In Barry Boehm and Richard Turner‘s book, “Balancing Agility And Discipline“, they present the concept of the “home ground“. Agile and plan-driven (a.k.a. waterfall) software development methodologies each have their own turf where one is superior to the other for getting the job done within time, budget, and quality constraints.
As the figure below shows, the Boehm/Turner definition of “home ground” is based on 5 dimensions: personnel (experience/expertise), criticality, dynamism, size, culture.
At the origin of the 5 dimensional chart, where dynamism is high, culture is liberally open, project size is small, criticality of application is low, and the majority of the project staff is highly competent, agile approaches are more effective and efficient and efficacious. At the extremes of the 5 axes, plan-driven approaches are more effective and efficient and efficacious.
Do you think Boehm and Turner have got it right? Are there any dimensions missing from their model; like level of management humility, quality of management-knowledge worker relationships, quality of tools, quality of physical work environment?
Definition Of Done
When the definition of “done” for a software development project is solely based on allocated time and budget, it’s relatively easy to be perceived as successful. When the schedule and budget are exhausted: the work stops, the software is delivered/released/deployed, and victory is unequivocally declared. Whoo Hoo! As long as the software runs, regardless of its quality and usefulness, all is well – in the short run.
When the achievement of one or more difficult-to-measure, but meaningful, quality metrics is added as a third criterion to the easily measured time and budget metrics, the meaning of “done” becomes less vague and more realistic. That’s why it’s rarely done in practice.
Ya see, CLORGs and DYSCOs are full of themselves. By not measuring the things that matter for long term viability, they can stay infallibly full of themselves till the fit hits the shan.
Boring, Genius, Lunatic
Silo City
The title of this strategy+business article, “One Way to Lose Employees: Train Them”, is not shocking, no? If you believe it, then you’ll most likely believe a fictional, complementary article titled “One Way To Retain Employees: Don’t Train Them“.
Regarding the first, real article, the authors assert that mechanistic training is not enough to retain employees. It just makes them more marketable to competitors. If they’re not treated well and not allowed to grow, they’ll simply leave.
Regarding the second, reinforcing ghost article, the author summarizes his/her message as:
The researchers found that the deliberate withholding of funding and the lack of active encouragement to participate regularly in seminars, training sessions, and workshops kept workers from leaving because it left them thinking that their skills were becoming obsolete and feeling that they were unmarketable and “stuck” inside the borg. Additionally, the dearth of career mentoring and unhealthy boss–subordinate relationships instilled a culture of fear and an unsettling feeling of quiet desperation among employees. The lack of job rotations also decreased employees’ hopes of a bright future, the researchers found. A policy of no rotating assignments prevented employees from learning about different aspects of the company and from forming new social contacts across the organization.
Between the research findings summarized in the two articles, it’s a slam dunk. To keep employees from leaving, simply don’t train them and keep them sequestered within their one dimensional silos.
But wait! All is not lost. To retain employees while simultaneously training them to be more productive to the org, the authors of the real article recommend this multi-faceted approach:
The researchers found that regular participation in seminars, training sessions, and workshops sent an important signal to workers that the organization was investing in and valuing them. Additionally, career mentoring and healthy boss–subordinate relationships built loyalty among employees. Job rotations also increased employees’ hopes of a bright future, the researchers found. Rotations allowed employees to learn about different aspects of the company and form new social contacts across the organization.
Constrained Evolution
In general, I’m not a fan of committee “output“. However, I do appreciate the work of the C++ ISO committee. In “Evolving a language in and for the real world”, Bjarne Stroustrup articulates the constraints under which the C++ committee operates:
Bjarne goes on to describe how, if the committee operated with reckless disregard for the past, C++ would fade into obscurity (some would argue that it already has):
Personally, I like the fact that the evolution of C++ (slow as it is) is guided by a group of volunteers in a non-profit organization. Unlike for-profit Oracle, which controls Java through the veil of the “Java Community Process“, and for-profit Microsoft, which controls the .Net family of languages, I can be sure that the ISO C++ committee is working in the interest of the C++ user base. Language governance for the people, by the people. What a concept.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 