Ways to annoy your senior engineer

I understand and sympathize with the managerial PoV as well. :) It doesn't make the exercise of estimates any less pointless, though.

> I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI.

Don't get me wrong. I didn't mean "control" in the sense that they want power over the project. It's more that they want to feel that these processes make the project more predictable than it would be without them. This is what I argue is a fallacy.

Whatever estimates they get back from the dev team, and whatever extrapolated metrics like "velocity" they think help them get a feel for the team's productivity, is ultimately pointless. The problem is that these metrics are relied upon, when they're really no more reliable than not tracking them.

Your house example is how management wants to visualize software development, but it's just not an accurate analogy, and never will be. Software development is nothing like "real" engineering, despite what developers like to call themselves. When building a house or any real-world object, you can rely on physics to make time estimates. You know how long concrete takes to set; you know how long a machine takes to cut wood beams; you could even know how long it takes for a builder to lay bricks. You can then extrapolate this to the building requirements, and more-or-less give an informed estimate, where only unpredictable circumstances like weather or human-related issues could delay the project.

Whereas software development depends entirely on humans (for now, at least; AI is not reliable yet), and there's no predictable physical component to it. Every project is entirely different from every other. This is not like building a house, where most houses have something in common. This is like inventing an entirely new way to build a house, from entirely different components, every time. The problems you run into each time are wildly different. Even when using the same programming languages, frameworks and APIs, the interaction between all of these changes every time you put them together.

But I'm sure you know all this. I'm just saying that the exercise of estimates is pointless, and the value they bring to the company is an illusion.

The author seems to work for a company where engineers are treated as pawns in political games; and where leadership is more about perception than accomplishment.

The best way to handle situations like this is to leave, quickly! Companies that operate like this don't last long, because someone else will come and out compete them.

Edit: One thing I do when interviewing, is when I talk to the manager, I point blank ask, "how often will I be asked to change a task before I complete it?," and, " how many meetings will I attend during a day?." It screens out situations like this very quickly, because the managers who are looking to hire pawns won't hire me after asking questions like that.

> Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.

Ouch. Usually the ones writing very aggressive comments filled with attacks on stereotypes are the ones with anxiety problems :) You are fighting with the windmills. I do make estimates, and I'm usually better than many at it. It doesn't mean that the others like my estimates.

Also, you didn't even understand what I'm saying. TL;DR: You need to allocate a considerable amount of time on analyzing the task to make the estimate (around 10% of the time it'd take to solve it). I also take a jab at people injecting workarounds for the sake of keeping it in the estimated time and failing.

8 is the worst.

In my last company there was a new top priority every two weeks. And i still had a very junior team who needed a ton of mentoring and development to be able to turn things around quickly. Who were then getting blamed for not hitting impossible-in-the-first-place deadlines.

Well, it helps if you have retrospectives, though I see them rarely done properly.

What kind of works is tracking similar efforts (in the same code base) and measuring how long they take. While every task is different, there are usually a small number of different classes of tasks, and knowing how quickly these can be done helps in both estimating as well as defending the estimates.