It’s pretty much an open secret that in software development, asinine (and sometimes completely outrageous) deadlines, like estimates, are a way of life. The comic below shows what is–sadly–a typical representation of your average private sector software engineer.
That being said, it should come as no surprise that everybody has advice on how to try and combat the problem. From TechRepublic‘s 10 tips for meeting IT project deadlines to the utilization of agile software methodologies (see Deadlines in Agile by Stephan Kristiansen). Besides the usual suspects of scope creep, inept employees and managers, and micromanagement from both up top and from the customer. But for the most part, it’s typically managers that cause the most issues, sometimes through no fault of their own (for instance, if the company is riding on the release of a product, it’s either get it done or everyone is out of a job, and us developers don’t get golden parachutes).
A typical communication flow, ideally, would look like below. The bold red arrows represent directives, requirements, and specifications for the project (e.g., deadlines). The thinner black lines represent feedback. This is then processed and sent back down through the bold red arrows.
This is what it looks like in real life, at least from my perspective based on my experiences.
The thickest red lines are the same before. The thinner (but still thick, cause I like ’em thicc) red lines represent pressure, chastising, or other negative reactions. Notice that there is no feedback loop, only a one way path. This phenomenon is called shit rolls downhill. It is a common trope among any team that develops a product.
Some may argue that the idea is to get a product out the door before a competitor eats your lunch. While I agree with that, it can also be argued that getting a quality product out the door that stands apart from your competitors is just as important. To achieve this balance between speed of delivery and quality. Always refer back to the Good/Cheap/Fast paradigm:
I can appreciate that people up top have a vision. I, and many other developers like me, want that vision to become a reality because we share it, too (in most cases; I’m not naive to the fact that some of us just want a paycheck). But reality can be disappointing, and because we live in that reality management has to be open to the fact that some things just cannot be helped. It’s fine you want a deadline, but you have to be realistic about it.
But they try to get around this.
Next time, we’ll examine the Good/Cheap/Fast paradigm and the Mythical Man Month and how wily managers try to cheat the system.
He then proceeds to list the following fallacies:
- Nirvana (perfect-solution)
- Appeal to authority (argument from authority, argumentum ad verecundiam)
- Historian’s fallacy
- Misleading vividness
- Survivorship bias
Let’s take a look at what I feel is the most common fallacy we as software engineers (or any professional, really) faces constantly: Appeal to authority.
This can be a bit problematic when you have multiple people vying for a shred of authority in their role. I worked at a location once where everybody around me nitpicked every line of code I emitted because it didn’t follow their ideas. When challenged, they would fall back on either “This is the way he [architect] taught us to do it” or “This is a best practice” or the implied “I’m older than you and therefore smarter than you so you should bow down to me.”
I think programmers are now afraid of taking the risk of applying what they know and have experienced and instead are falling back on the results of others. Let’s say that you write a method that causes a memory leak. When you’re called out onto the carpet, you explain that the way in which you constructed the code was based on the directed opinion and approval of the project architect. Even though you noticed the potential for a leak, you ignored it because, hey, why should you doubt the architect? Isn’t s/he supposed to be the smartest person in the room? In turn, you get to be thrown under the bus while the authority that you yielded to denies all accusations.
At least with blogs, talks, and other tangible items, they can’t fight back.