>Sometimes providing a bad product is only relative to the competition (which may have a worse product).

Eventually will came someone with a truly good product and distrupt the market

will they?

In some fields having a good business and regulatory relationship with the customers (e.g., hospitals, DoD, banks, etc.,) is much tougher than building the product. There are many barriers in place and these fields are not so easily disrupted (having a superior product is definitely not enough).

Also note that having a bad product now that is better than the competition does not mean you cease to improve.

Exactly. I've worked in companies dominating a particular niche. Everything about the technology is "terrible" from an engineer's perspective, and yet nothing shifts their dominance. A massive rewrite that damages customer relationships is more risky than doing nothing to improve it.

Or this company is bought up, which was there first and therefore has the larger financial reserves.

>"maintainable and reliable" are overrated

That is popular opinion among the unemployed, as hoisting that BS on your project lead has real world consequences after your code audit. =)

Here is a quick CEO dilemma: You have startup with about 4 people, you did a quick prototype, showed it to some potential customers and the worse has happened:

They want it! and they want it now!

The head engineer says it's all just a temp hack, it is completely shitty, they could give it to costumers but then the maintenance will be impossible, they will need months to add any new features on top of it, they will probably waste all their time on fixing bugs, and they'll quit if they have to maintain it for long.

What would you do? (A) continue develop until you have a nice maintainable product, or (B) sell the product now and face the consequence of wasted developer time and loss of their motivation.

Sometimes in such situations the answer is (A), but not always. It depends. How much money you got? how certain are you of the timeline for "finishing" the product properly? which option is riskier? How much competition you have and how likely they are to publish a product before you? What could having a real customer teach you about your product? What do you need in order to get the next round of investment?

This is just an example, but IMO product graveyard is filled with great maintainable and reliable code no one had a chance to use. I love software and I'm really not disregarding its importance, I just think it's not always the most important thing.

Yes, I agree, there is a continuum there. It is easy to judge from afar, but it is much more insightful to see what people do in real situations with real resource constraints and complicated human beings trying to succeed -- and not always with the same definitions of success.

For example, for many engineers, what they (a) can learn and (b) be proud of while building a product is a big part of success.

For some CEOs, engineer satisfaction is only a secondary or tertiary goal -- their business success crowds out most other things. This is complex; sometimes this drive is what helps a business succeed; sometimes this is why people get treated poorly or ethics go out the window.

"what people do in real situations with real resource constraints"

As this is mostly on-topic for the parent thread... I can respond...

When faced with a painful product launch/schedule, as management messed up resource budgets etc... there are a few actions one can usually take:

1. ignore the issue, accept a 60% probability of failure risk, and naively hope management is replaced

2. adjust current project scope, follow MVP rules, and defer features for v2

3. cull the project, and eject unprofitable/unhelpful members from the team

4. Leave the company before the shite hits the fan

Note, compromising workmanship is not on the list, as a business "Brand" is often more important than non-stakeholder opinions of intangible asset valuation.

A CEO rarely accepts designing a product for a single customer. If you did, than your team just becomes dependent contractor labor rather than a business.

I will tell you a terrible secret of successful software companies: "One doesn't make money writing software, but rather reselling the same software mullions of times over."

You should know this already. =P

You seem to talk in absolutes while I'm just acknowledging there is more than one right answer.

And I do have specific real cases from my experience in mind... One of a great product that never finished (money ran out, CEO didn't want to provide something that was for "a single customer" as in your words), another of a shitty buggy unmaintainable software that did grow a company from 4 to 100 employees then to an exit and only then came the nice eased-back rewrite.

The 3 year survival odds are about 1:23 for software/services startups, and 1:70 for hardware projects.

I have culled many half-arsed options... and the decisions are far from arbitrary. Also, who budgets for a project burning over $100k a month in labor without a detailed plan... lol

I agree with what you wrote here... I just don't see how it relates to what I said.

Start-up have terrible survival odds. Decisions should not be arbitrary. There should be a detailed plan.

That moment when one person recognizes what is happening in a conversation; namely;

1. when two people are "talking past" each other.

2. It isn't only about 'what I'm saying'; multiple streams of conversation can happen at the same time and all be useful and even true

> You should know this already. =P

Groan. This comment could make its point without assuming what the other party knows or doesn't.

It was Facebook's philosophy and also Twitter used to go down a lot in the early days. So I'm not sure I'd agree with your statement. It depends on your company culture.

In general, a well planned API allowed Facebook to integrate a lot of 3rd party features to attract more users. Simply put, a messy standard is still a standard.

Both are in a strong first mover / network effect industry (social). It's definitely an optimization in certain cases.