Comment by zaptheimpaler | Hacker News Reader

Comment by zaptheimpaler | Hacker News Reader

Parent Full thread

Controversial because it's disconnected from reality. You're putting ALL the responsibility on devs as if they are free to present any estimate they like that will then be then accepted without questions or negotation by management. In this fantasy land management is presumably operating in a vacuum with no pressure from customer deadlines, costs, investors, long term product roadmaps etc.

I don't know about you but that is typically not at all how things go at my job.

I can present a 3 week estimate to manager, he will say why 3, seems like it should be easy??, Bob says it would take 2, can you provide a breakdown of the estimate, why does estimate have 3 days for "unforeseen obstacles"?, let's cut that out. We only have 2 weeks but we can't cut scope. 1 year later everything takes twice as long as it would in a cleaner design, management is wondering why dev productivity is low and won't allocate time to maintenance (we can't spend even MORE time on some refactor thingamajig, our productivity is already low!!). Meanwhile im trying to figure out some monstrosity of a codebase written by an engineer who left last year, and also neglected to document their code (unfortunately their manager felt 1 day for documentation was unnecessary). I think this is closer to the scenario most devs operate in. In all but the best high trust scenarios, every estimate is a negotiation.

In reality technical debt is 10% a communication problem (as this and many blogs like to frame it) and 90% a "do you trust your mechanic to have your best interests at heart" problem.

In your scenario your manager appears to be your adversary and not your manager. Those comments are what I would expect from a stakeholder, but not a manager. Your manager should provide a unified front to business and senior management. You two should agree on the correct approach. If your manager doesn't believe that your team should build things correctly and minimise technical debt then he's a terrible manager and you should leave.

Your entire scenario would be moot if you practised scrum and estimated the work effort as a team. Your manager might get a vote, but that's it.

> If your manager doesn't believe that your team should build things correctly and minimise technical debt then he's a terrible manager and you should leave.

If you or your manager believe that there is only one "correct" option and that technical debt should always be minimized (vs being balanced against other factors), then odds are you're bother either terrible or very naive. In almost every moderately sized piece of work, there are multiple options and there's a choice of which one to take based on various priorities (ie, the best option varies depending on multiple factors).

While true, this doesn't change the premise. Both parties should agree on the "correct" approach in the context of this discussion: minimising technical debt.

Your manager is always potentially your adversary: after all, they can fire you if they are unhappy with what they are seeing.

Not to mention that some managers simply are adversarial, period. When you apply to a company, you can rarely choose your manager, and sometimes cannot work under a different manager without leaving the company entirely.

I've had adversarial managers in the past. Unsurprisingly, the team underperformed and the culture was terrible, so I left. I don't agree that one's manager should be one's adversary. I've worked with many managers who work with me instead of against me. This is a crucial difference.

The real issue in a situation like this is the use of the Agile Story point BS to create competition between developers in order to have leverage exactly this to push back against the Engineering team with. You need to have a Dev-only meeting so Bob doesn't feel specifically called out and talk about how you all want to negotiate the interests of Product/Business with the dwindling engineering situation, i.e. Tech Debt.

Bob, and others like Bob who live to impress management with their personal 'agility', will implicitly feel more pressure to not go against the whole engineering team if you're able to reach even near-unanimity about what that strategy will look like, in this case, perhaps coming to agreement about how certain tasks will be pointed univocally, amongst other possible strategies. Your only obstacle at this point is a head of Engineering whose interested in their own career over and above his team.

Agile SCRUM exists, largely and for the most part in my experience, as an abuse to prevent this kind of 'collective bartering' on the part of Engineering.

Sorry to tell you this, but it sounds like you have a bad manager. Your story is like not how healthy teams operate, which in my experience actually are much more like the post you're replying to.

Thank you, really. It is nice to hear someone else acknowledge it. I'm going to start looking for a better job.

> Bob says it would take 2

Tell Bob I wish him the best of luck in this endeavor, he's clearly a better programmer than I am.

Bob can remain lucky for longer than you can keep your credibility intact (aka "markets can stay irrational for longer than you can remain solvent"). Ultimately, that stance gambles on Bob's luck running out and his lack of skill being exposed in time for you to profit from it.

Or realistically, bob looking good racking up tech debt and quitting before anyone needs to pay it off

Reply on news.ycombinator.com