Hacker News Reader

Comment by vault_ | Hacker News Reader

Where this breaks down, as I've experienced at least, is that the product management side maintains basically zero awareness of the production constraints engineers are working within. If you've built out a painting production line around spray guns and beige, that has knock-on effects as to what results are attainable. A PM asking for polka-dots next sprint is throwing into question the entire body of practice, but this happens with extreme frequency in software.

View on HN

This I think is a broader problem of a certain personality of "idea guys" that lie about requirements, often without being aware of it, and it being our problem as engineers to read their minds and be two steps ahead of them.

Director: "We need a factory that's tooled around manufacturing boxes of cookies with blue frosting. We don't need any other colors, just blue frosting!"

Junior Engineer: "He's going to come back in two days and ask for red frosting. Better make sure it can do any color."

Mid Level Engineer: "He's going to come back in a week and ask us for multi-color boxes. Better make sure it can do any combination of colors in each box."

Senior Engineer: "He's going to have the big idea to add sprinkles, writing, and branch out into eclairs. Better make sure the factory is extensible and can retool itself per-batch to make each box to-order."

The worst part about this is you can see where uncertainty leads to over-engineering and consequences if your psychic senses are off. This is where a good PM steps in and forces folks like this into a roadmap on a long-enough time-scale that you can see the mid-level's design is all we'll need. And if you still want eclairs we can talk about that in 2026.

Seasoned Engineer: "He's going to come back in a week and ask for croissants, better focus on just making blue cookies now and worry about the future later".

This. Engineers talk about feature creep, but forget to mention configuration creep. You can make anything you want! Yes it’s taken two years and no we didn’t nail the principal usecase. But we can make a version 2!

Ideally engineers should have a sense of the business and so know which are expected feature creep and which are unlikely. So you design the blue cookies, but you leave extra space because next week you will be installing more paint guns so you can do more colors, but you limit it to 6 colors and when the CEO asks for more say we are out of space, do you really want to invest in more colors, eliminate and existing one, or the new idea. Crescents may be a good investment, are they likely enough and similar enough to do them on the same line. (if you cookies have nuts the correct answer might be we want a whole new factory even if there is commonality just so we don't need the "nuts also used in the facility that" makes this label)

Don't leave extra space. Ask the question and get a "no, we don't need that", then call out the frequent specification misses when the schedule slips due to all the rework. (Or that doesn't happen and realize they might know what they are doing)

Pain like this is critical feedback for a organization. Blunting it hurts more in the long term.

Reply on news.ycombinator.com