[pyrale]

> I think this is a relatively popular development strategy.

...And this is why PoCs should be small-scale but technically sound things, rather than a shortcut competition. People are rarely going to complain about a PoC delivered a week late, but they are definitely going to complain later on, after they ship the PoC against your opinion and development slows down.

[sumtechguy]

Even if you make it clear they will continue to use it.

I have one bit of code 'i do not claim any knowledge of' that I bashed out in under 1 day with promises that it will be re-written soon. 5 years on I still get questions about it. I get questions because it is a PoC that does one thing very well and everything else badly.

[btbuildem]

I strongly disagree, I think you misunderstood the purpose of a PoC

We build these things to flesh out ideas, to put something in front of PMs and ideally customers, to get feedback, and to make sure that we have a good bead on what the Most Important Problem is.

PoCs are disposable, sticks-and-ductape contraptions to demo features, and maybe have a small subset of users to play with for a limited time. They are by no means starting points for actual development.

[jeromino]

By that time the POC shipper got promoted for releasing fast, and no longer does dev on that team, and the replacements get harangued for delivering late. Business doesn't care who created the problem in the first place.

[mejutoco]

People can complain about anything. That does not mean they are right.

If a PoC is later extended, it will of course have limitations. We do not need to change the meaning of PoC to full product to preemptively solve that.

Instead, when a PoC is done everybody involved needs to understand the implications. If people insist on misinterpreting them, that is on them. Those are political problems, not technical ones. They can be solved by aligning incentives.

TLDR. A PoC is a PoC, not a full product.

[pyrale]

> Those are political problems, not technical ones. [...] TLDR. A PoC is a PoC, not a full product.

Politics eat technnological semantics for breakfast though. It's up to you to decide whether this is a hill you want to die on.

> They can be solved by aligning incentives.

Often enough, that means shipping the poc.

[mejutoco]

> Instead, when a PoC is done everybody involved needs to understand the implications.

> Politics eat technnological semantics for breakfast though.

I see where you are coming from, but I have to disagree. I am not debating semantics, but reality. A prototype will always have limitations. That is the definition of a prototype.

I understand in reality sometimes it is worth to push through (startup), and sometime it is not needed but it is demanded. I am not starry-eyed, but it is useful to know what the reality is before one tries to bend it or adapt to it.

If you want, Nature/laws of physics eats politics for breakfast :)

Aligning incentives in this case could mean making the developer have a stake in the outcome (bonus), have competent people and clear deliverables, and bonuses for products that work well/convert. Not just for speed or busyness.

Basically you are assuming a sort of feudal relationship between someone handing arbitrary deadlines and (whatever you must do) and someone in charge of implementing it having no say in anything, and obeying blindly. That is not how the best engineering is done. Places exist (I have worked in some of them) where people can be professional, and a lot still gets done at the end of the day, even more than with the stick and harsh words approach.

A certain amount of back and forth is healthy and can produce much better outcomes for the company.

[pyrale]

> If you want, Nature/laws of physics eats politics for breakfast :)

It would be that politics eats tech, but culture eats politics.

And strengthening your PoCs is a predictable cultural consequence of any organisation where leadership forces PoCs in production.

For leadership to align incentives is to prevent engineers from suffering the consequences of PoCs pushed to production. What you described may work in some situations.

> A certain amount of back and forth is healthy and can produce much better outcomes for the company.

The reaction I described is a kind of back and forth, if a bit conflictual. However, it's leadership's responsibility to ensure that communication happens in a non-conflictual way.