[jprosevear]

One of the challenges with this approach is answering "how much will it cost" and "how long will it take" - that being said, its often hard for non-developers to articulate exactly what they want without connecting it to something more concrete in the form of user interface.

[boxed]

Those questions aren't answerable in the first place.

I like the general idea behind ShapeUp: don't ask "how long will it take" but "how much time are you willing to literally throw in the bin to learn more about the problem". Committing to research is easy and HONEST. Committing to a finished product by a date is incredibly hard/impossible and a lie.

The first duty of all humans must be to truth.

[SpicyLemonZest]

It's quite rare to be in a scenario where not making timeline estimates is even an option.

* If you're B2B, your marginal clients are constantly deciding whether to sign or renew their contracts, and their money directly depends on promises you make them about when features they want will be available.

* If you have competitors, you have to evaluate how your product will match up with them over time. If there's some killer feature you could build with 3 engineers in the next quarter, you should probably do it. If there's a killer feature your competitors could build that fast, but you have some tech debt that would make it take 3 years, you'd better find a strategy to make that feature less important.

* If you have a large or growing product, you have more potential projects to do than people to do them, so you're going to have to decide which will produce the most benefits for a given unit of time investment.

If you have a small, non-contract-based project with no direct competitors? Sure, it's possible to get away with the "we'll finish when we finish" strategy. But there's not a ton of space in that niche, and unless you get quite lucky it's not where the big bucks are going to be.

[boxed]

I think this is largely a matter of habit, and not of reality. Yes, you might get the business short term if you lie and say some feature will be available Q3. But over time that type of constant lying erodes trust and hurts you.

I get it, you might need to do it to survive in the beginning because competitors will be doing the lying. But I'm saying you need to stop lying as soon as possible for the long term health of the relationship.

[SpicyLemonZest]

I didn't want to quibble about whether it's fair to call it "lying", but I think the term is misleading you. There's simply no such thing as a business relationship without time estimates. It's not a short term vs. long term or trust vs. distrust tradeoff - unless your business model consists entirely of off-the-shelf purchases, your customers will want estimates about what you'll do in the future and when.

[JKCalhoun]

Yeah, that sucks for management. Not my problem. ;-)

In fact more or less everything that I have found burdensome in the last decade or so of my career were things introduced to satisfy management.

Unit tests? Code coverage? For management peace of mind.

Code reviews? I'd argue, same.

Agile development (obviously).