Hacker News Reader

The worst are inexperienced product managers who look at you like you're trying to pull a fast one.

If it's something small, then maybe just code it up quick in a branch named after the PM-Feature (so you can keep track). Then ask them to validate the requirement before you merge it in (hopefully you can help with this). At least this way they know that you aren't being lazy etc.

Next time that PM asks for something "simple", do a quick branch list of invalidated feature requests.

"Namely, the business units are so disconnected from engineering they don't even realize the costs of what they're asking for, and the engineers are so disconnected that they reap zero benefit from whatever business goal is going to be accomplished by this."

I don't think it's just that they're disconnected - some of the orgs I've been in - they simply do not care, and never will, even if they completely understand the "costs". Why not? Because they don't have to pay it. It's not coming out of their budget, the 'costs' of higher support later on don't affect anyone who's making the decision right now, and damnit, we have to get this out now or we'll lose marketshare!

This is a toxic division, and seems to be more prevalent at companies that do not see themselves as software-based companies. Yammer is all tech - Yammer couldn't have existed 30 years ago, but plenty of more traditional companies still see software as something divorces from their main business.

I have similar experiences - it all comes down to accounting structures, in the end.

It happens in tech companies too, especially enterprise companies. Project managers want to close out on their project and deliver to their customers and fuck anything else that's going on.

I've had a lot of success explaining it like this:

"Making something work is pretty easy. Making sure it never fails is the hard part."

I've had some luck defusing these kinds of remarks by calmly but firmly stating that "with though simplifying assumptions, anything is trivial". YMMV.

"with though simplifying" doesn't sound right to me....did you mean something else?

Context tells me he meant "with enough"... touch screens are a wonder for us fat fingered folks.

The mobile experience on HN sucks.

Keyboard input on someone's phone is not something HN would be able to fix.

On my Android browser, I am usually typing with the box half-off-the-screen so I can't see what I've typed. On Android Chrome, font size for replies is incredibly inconsistent (some comments are huge and some are too small to read, and some are inbetween), and the textbox is still half-off-the-screen.

The text size issues is a bug in Chrome. Firefox for Android has a similar bug as well. For this reason alone I switched to Opera; it has its own bugs, but at least the text size is right.

D'oh! Of course I meant "enough".

> the business units are so disconnected from engineering they don't even realize the costs of what they're asking for

In software you get this at all levels, including in the freelance/consulting world - people have no clue of the costs of what they're asking for so when they can't even make bad guesses, they go with "how hard would it be..." for a big feature request or "can't you just..." for what they see as a small one.

I always prefer honesty over this - if you have no idea about even estimating the cost for some feature, just ask "How much will it take and how much will it cost to... ?", don't fuddle around with the "how hard...", "can't you..."... these are just weasel words for when you need to overwork and underpay someone because you really know you need something done yesterday and with almost no budget, but you really need it so maybe someone will just shoot himself in the foot to make it work for you if you ask nicely enough :)

You're putting way too much baggage on to "how hard". It doesn't necessarily carry any implications of "yesterday and with no budget"; it's a scoping question.

"How much will it take and how much will it cost to... ?" condenses down to "how hard…". You can tell they're functionally equivalent because you can give the exact same answer to both.

"Can't you just" is a whole different story, granted.

I somewhat agree with you, it's not "dishonesty", but when people phrase it like "how much will it take and how much will it cost to..." they usually have in mind the fact that it will take time and have a cost, whereas when they use the condensed variant, they tend to think that it can be "squeezed in there and worked on at the same time as everything else without delaying anything" ...it's folk psychology I know, but imho there's a more or less subconscious association between using the condensed form for talking about something and wanting to minimize the apparent cost/impact/etc. of it :)

The people asking probably don't think they have no clue of the costs of what they are asking for, they think they have a vague idea of the relative costs based on their perception of what is involved and their past experience of other changes.

Now, these ideas may often be very wrong, and may be in fact so wrong that "no clue" is the best description, but its not, for the most part, dishonesty when people act like they have some general expectation of the cost.

Your product managers need to understand enough about the quality of the different areas of your system to know what you are talking about when you say that something is easy or hard. It's best to make that a part of your regular discussions rather than something you pull out when there's a problem.

Draw them a picture and have the discussion - frequently.

I actually see these as an opportunity to improve existing code, plus doing something new and different. However, to cover myself, I ask for thorough specifications and test-cases, to which I add risk analysis etc. If it doesn't go exactly right, I blame the specifications.

A designer I worked with had lots of interesting stuff taped to his door, and rotated it regularly.

My favorite was probably the following:

“Can you just...”

no.

Yeah, I find that attitude quite counterproductive in software development. I understand and agree with the argument that some “can’t you just”s are way more complicated than they are presented. But this kind of attitude, taken to its extreme (e.g., having that sort of half-joking sign on your door) is a roadblock to real progress, which often starts with a “hey, couldn’t we...”.

For me the point is that inserting the word “just” is diminishing or belittling the person's contribution, even as you are asking them to make that contribution.