Friday, March 23, 2007

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.

Labels: , , ,

Bookmark and Share
posted by Brian at 11:26 AM 0 comments links to this post