Are We Biased Toward Labor Intensive

For those of us techies who are not managers or owners, it seems that our proposed solutions tend to be biased toward more labor-intensive solutions and tools than those who are not. That labor intensiveness could be training or skill level or a TechniqueWithManyPrerequisites. (I'm also considering the cost of education and purchasing skilled services as a "labor cost" here.)

Our desire or focus may be to "do it right", which may be in terms of sufficient features, well-thought-out UI, lots of error checking, careful performance tuning etc. And, we tend to get wealthier the more our services are requested. Thus, we technicians perhaps lose sight of other economic variables that are not something we focus on as heavily in our day-to-work, such as budgets, deadlines, office politics, odd HR rules, marketing, etc. We may be neglecting the affect of those other factors, including labor costs. We may be subconsciously biased toward lining our pocketbooks and/or dependency on us.

It's not that we are "evil", we're just human, and humans tend to naturally rationalize, often unconsciously, in their own direction of benefit. Evolution instills such an instinct because those individual organisms that don't tilt the "environment" in their favor had less offspring, meaning purely altruistic organisms don't proliferate. This is not a moral justification either way, only a report on the forces of nature that probably have shaped human nature over hundreds of millions of years.

-t

How are you measuring "labor-intensive"?

More than necessary or more than economically justified. The cost of feature X is greater than the net benefits of feature X. Perhaps the title should be "Are we biased toward techniques that rely on our own profession", but that's too long. Topic ponder.

Similarly, those in education may be biased toward education-heavy solutions to everything. Programmers "should" master advance techniques and spend more time in your, the instructor's, classes to get that advanced education. -t

You suggest that education is more costly than being educated. Education is a one-time investment, whereas lack of education is an ongoing cost. This is true even when education is limited to learning language feature <x>. Assuming <x> replaces a more complex, or risky, or tedious but known feature <a>, then in the long run it's almost certainly cheaper to learn <x> and gain the cost-saving benefit of using <x> than to not learn <x> and keep using <a>.

Well, of course ItDepends. One needs to ask if the "investment" pays off. I agree it's "good" to have lots of knowledge, but from a purely economic standpoint, there may be point of diminishing returns. Related: SoftwareDevelopmentIsGambling. One thing I notice is that you have to pay attention to maintenance of existing code by other developers if you want to be perceived as a "good" programmer in the longer run. Even if YOU know a great technique, a future maintainer may not and thus it may irk the organization to use certain techniques because it could hold up or gum up change requests. One has to target a kind of "middle common denominator". Some WikiZens seem bothered by this aspect of the real world for some reason, sometimes even leaning toward an AynRandDesignPhilosophy.

Of course, the "middle common denominator" in (say) a non-IT-industry, mainly end-user computing IT department may be very different from the "middle common denominator" in (say) a cutting-edge financial services industry software development firm. The former may deprecate your use of spreadsheet macros, because your replacement might not be able to understand them. The latter may expect every hire to have in-depth knowledge of advanced Haskell.

Of course ItDepends on the organization and their goals. But almost by definition, most organizations are not looking for "cutting edge" IT, but rather road-tested stuff. Start-up and skunk-works projects may indeed try to leverage cutting edge and "elite" personnel and techniques. It's usually understand that such an organization or project is a bit of a gamble. And I hope we are not drifting into the ol' EconomicsOfAdvancedProgramming debates again.

No, but I hope it's clearly recognised that what you consider "cutting edge" organisations are sufficiently prevalent to warrant higher-order language features in popular programming languages. The fact that, for example, "Java lambda" returns about 15,000 Google hits suggests it is hardly an obscure or ignored feature.

I am not arguing here for removing features from languages. And the "hits" may merely be from people who want to pass their tests and thus is a poor guide to field usage. Plus Java is sometimes used for SystemsSoftware, where HOF's may be more useful.

As for field usage, you're right that some hits may be from people looking to pass certifications, but if people are learning it to pass tests they'll probably wind up using it. On the other hand, look at some examples. Isn't the lambda-based example on NodeJsAndHofGuiDiscussion simpler and more readable than the anonymous class based example?

Often people forgot a lot of stuff from classes if not refreshed by usage. There's a shelf full of details from formal education etc. that has rotted away in my head from disuse (no jokes please). As far as the other topic, I'll leave that issue there.

Must... Resist... Obvious... Insult... ...arrrrrgh...

I know you are going to be sore in the morning from the strain.

CategoryEconomics, CategoryEmployment