Many technology companies like structure and planning. They invest time in creating detailed designs and specifications that will inform development, quality assurance, documentation and marketing. Other companies, even today, fly by the proverbial seats of their pants. Having worked for a number of software developers over the years, I've been in a position to see the industry from the inside. And what I've seen isn't very pretty.
It's days like today that make me regret ever accepting a ticket to this ringside seat. It's one thing to be a software user and to be frequently frustrated by buggy programming and poor design; it's another to be party to it and to understand how and why bad software makes it into the users' hands. Today my manager pulled our heads together to inform us about a change that was forthcoming in a program we've been testing for months--and to admonish us for not having raised a concern about the issue that prompted the change.
I resented the admonishment, not because it was not a valid concern; it obviously was. I resented it because we are one of those companies that make things up as they go. Crudely scrawled diagrams on a whiteboard or handwritten notes on scrap paper are the best planning documents we have. And those are never shared with the quality assurance team. No, the quality assurance analysts have to wait until the product is finished and the code is ready to be deployed to the lab environment before they even have an inkling about what it's supposed to do. We're winging it.
And we are expected to raise questions about design flaws. Never mind that once a product has been built it's a little late to be addressing design flaws. The only way to undesign bad design is to start over. That, of course, is out of the question. Around here it's damn the torpedoes and full speed ahead.
What's even worse is that most of the questions we raise about poor design decisions are dismissed. It works as we intended. That's what we hear almost every time we raise an issue with how something functions.
But my manager wants to hold us accountable for decisions over which we ultimately have no control. I understand why the issue is being raised, and I agree that it ought to be raised. Just don't dump this in my lap.
Adding injury to insult, I was then informed of the next testing project. The manager admitted knowing next to nothing about how the system is supposed to work and acknowledged a language barrier. But somehow I'm expected to be able to take on the testing for the system and make some kind of judgment about whether it's working correctly or not. Have you ever wondered why your software doesn't work correctly? I think I know the answer.
Once again, I feel like I've awakened inside a Franz Kafka story.
