Computer Science = Not enough to solve production problems.

Some thoughts occurred to me today as I looked back over my career:

• My Computer Science degree taught me nothing about how to build great tools for actual people working in a production environment.
• Nor did it tell me how anything about how such tools get created in the "wild" -- neither ideally nor poorly.
• Small companies tend to build production tools from the bottom up, based on informal conversations between people needing tools and the developers.
• Once a small company grows too big or gets bought out by another company, a top-down approach takes over.
• This approach is a mostly linear flow:
  • Users complain about a problem.
  • Production or Management determines whether this problem is worthy. If so, it creates a ticket in the tracking system.
  • Developers see ticket and build tool.
• Seems logical enough, but I have yet to work for a company where this invading top-down methodology:
  • Improves the actual production for the people using it or the customers they support.
  • Doesn't waste time & money and actually cause lower production over time.
  • Isn't initiated by so-called experts outside (and with little knowledge of) the production wanting vague results like "accountability" and "return on investment" and other business buzzwords.
  • Doesn't discourage bottom-up ideas from going through the new top-down process, EVEN THOUGH the new system mantra is "Please, send us your ideas to improve the system."
• The top-down folks and the bottom-up folks tend to speak very different languages.
• Managers from both sides host meetings with minimal feedback from their teams.
• Hierarchy, a concept from the top-down folks, gets imposed to keep folks under the manager of the developers from going around and talking directly to the other teams they are building tools for.
• The flow from top to bottom results in tools built to specifications that are weak because the folks needing them:
  • Speak different languages amongst themselves and the developers.
  • Can't determine precisely what it is they need.
• The developers adopt a mentality of "Just build what is asked -- that way we are not accountable. It's their fault if they don't get what they want."
• Meanwhile, the experts in actually making the production work without decent tools get overworked.
• They finally burn-out and leave, leaving behind a gaping hole of lost knowledge.
• Sometimes, the original developers become "operations" and new developers called "engineers" are brought in to formalize the (mostly unknown) process.
• These engineers:
  • Have no understanding of the legacy system,
  • Often discourage feedback from the original developers
  • Make grandiose promises of a panacea for management.
• The panacea never happens.

Next time, I'll describe what has worked.