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.
Love ’em or hate ’em, estimates are a manager’s best friend and an engineer’s (developer/producer/whipping post) nightmare.
And they’re not going anywhere.
Reading the comment section on Hacker News today on the article Dear Agile, I’m Tired of Pretending by Charles Lambdin when the subject on estimations came up. Specifically, this comment by bougiefever:
There are two distinct statuses that a software developer will be looked upon by those outside of their respective realm within an organization: as wizards that can turn out miraculous, spectacular(?) software, or as insufferable buffoons who seem to forget that in some cases people’s lives are in their hands and yet they still manage to drop the ball.
This is why I hate it when the upper echelon of my current employer call me “the man”–this placing of me on a pedestal is dangerous and sets a very bad precedent of me being a 24×7 miracle worker. I’m not the Jesus of software engineering, folks.
With estimates, in response to xwdv, while you, the programmer, may reach a mutual agreement with the individual or group requesting the estimate that it is in no way, shape, or form, a concrete definite obligation that it’s going to fall within that time frame, that agreement is moot when they go and construct it as a promise to the next party, whether it be upper management, the customer, or your own mother. And this has led to some small uprisings in the software development community, such as the #NoEstimates movement. From the article Estimates? We Don’t Need No Stinking Estimates! by Scott Rosenberg:
Non-engineers need to understand that software development is not an exact science; a lot of it involves trial-and-error. When the stakes are high, we need time to ensure that everything is copacetic. I know this advice is going to fall on deaf ears no matter how many times I try to teach management and others about how this industry works, but I know you, dear reader, will agree. In any case, perhaps this is a case for business coaches to start teaching their clients about software estimation and project management.
Whatever the case, estimations are not going anywhere, period. Otherwise, you’ll get pie-in-the-sky vaporware that, if it ever does come out, fails to live up to its expectations (“You spent X [months/years] on it! Why does it suck!”) and becomes yet another argument for either waterfall estimation or agile burndown charts (Duke Nukem Forever anyone?). The lack of estimations is merely cannon fodder for management to rubber stamp you as incompetent and find some other schmuck to make that promise. Worse yet, when that check bounces, you’ll still bear the majority brunt of the blow back.
If that’s the case, you might as well project something insane and walk it back. Hey, under-promise and over-deliver, right?
I’ve had a few contracting gigs in my career as a software developer. Really, it is quite common in this industry. Many, if not a good majority, of contractors are not strictly 1099 workers per se (we’ll cover that in a minute); instead, many are employed by staffing agencies such as Robert Half and FGP and farmed out to clients who have an established contract. The employees typically submit hours worked at the client and, if approved, are paid through the agency. There is typically no benefits (or very poor benefits), no paid time off, and, because the you’re not in the “in” crowd of bona fide part-time and full-time employees wholly employed by the client, you may be looked down upon.
From the article Software Developer’s Guide to Contracting Versus Salary Employment by John Sonmez:
As a developer, I can only attest to what my experience was like from the programming perspective. As a contractor developer, it was not uncommon for me to…
- Have what considerable experience I had developing ignored. I’m all for having a uniform code base, but it does not require you talking to me like I’m a complete idiot or am so wet behind the ears that my nickname is “Niagara.” I can respect that as a contractor, my contributions could have a lasting impact–both negative and positive–and that, after my tenure, it would be up to someone else to maintain it. (Read this article for some more anecdotes about being a “highly paid consultant”).
- Be regarded as the lowest rung in the caste system.
- Have items kicked back from QA/other programmers because it didn’t meet whatever imaginary standard they had.
- I should mention that as a trick, if you want to generate some plausibility into why you want to nerf a programmer, have QA keep sending back bugs that have been solved and demonstrated fixed. Do this enough times until you have a good percentage, then you can drop the hammer.
- Be excluded from company events (which was fine; I wouldn’t expect my HVAC guy to join my family picnic).
- Be accosted verbally. This seems to be a running theme in my life…
Contractors make up a large segment of many organizations. For example, Google essentially runs off contractors, the “invisible workforce, off company payrolls” doing grunt work “for the Silicon Valley giants with few rewards.” Indeed, “[p]eople look down on you even though you’re doing the same work” is the sentiment for many contractors not just for FANG but throughout the industry. The federal government lives and breathes contractors (helps avoid public unions).
I coped with these behaviors the best I could, often just riding them out until the next full time endeavor came along. There were times when it was awfully frustrating to be treated with such little regard. I hate being a contractor; it’s simply not my cup of tea. But, my father always told me: “Put up, or shut up.”
So, I shut up, was shown the door after the company merged with another, and landed a full time position in a job I love. If employees are seen as expendable, then contractors are seen as little more than a means to an end.
To employers, please: I know there are a lot of morons that get past the door, but there are plenty of good contractors who are great at what they do. They are a guest in your house, so try to make them at least feel a little bit welcome while they perform their duty.