Archive
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.
Meet The FOCHers
FOCH == Frequency Of CHange
A Bum Rap
Middle managers often suffer from a bum rap. There’s pressure from above to meet schedule and cost, and there’s pressure from below to trade schedule and cost for quality. Since their bread is buttered from above, the likelihood of middle managers being able to deftly handle those conflicting demands equitably is low, very low. Ya can’t blame them for capitulating to the demands from above, right?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 