TechnicianBias

Last edit May 6, 2013
This is to catalog reasons why technicians may be biased in their assessments of technologies and techniques. It's not an accusation, but merely a catalog of potential influences. These may be both conscious and unconscious.

  • JobSecurity - We want the customer to have to keep coming back to us. This may include techniques such as:
    • Convoluted or confusing internal construction:
      • Excessively "advanced" or obscure technique for the job at hand such that follow-on maintainers probably won't know it.
      • Poor design, such as partitioning that has no documented or easily-determinable rhyme or reason.
    • Bugs
    • GoldPlating - Run up the time bill and/or complicate the system with extra features not explicitly requested, increasing the maintenance costs.
    • Misaligned goals - Example: focus on machine performance/speed over code maintainability even though customer never stated such a preference.

  • Tool familiarity - We want others to use our favorite tools or techniques so that we are better able to hop in and be immediately helpful/useful. This may push us to view our preferred approaches as "better", and promote them as such.

  • High Barriers - We spent the effort to climb a high barrier, so expect other technicians to have to climb the same or similar barrier to be granted the "right" to participate or replace us. Example: "I had to figure out this code base without comments, so you should also, and I forbid you to add comments."

  • More to come...