[JonChesterfield]

> because you don’t build on the PoC

Ah yes, I remember that idea. Naturally we shipped the proof of concept.

Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced.

Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.

[Etheryte]

There is a somewhat malicious compliance way of avoiding this, and that's to write the proof of concept in an obscure language or using some other set of tools that makes it impossible to pick up as-is by the rest of the team. The downside is that it also adds an additional cost to you when building it.

[ZaoLahma]

Does not work and makes life worse.

I once in an earlier life worked in a very Java centered company, and we had a C# component that our "normal" Java blob was communicating with that an old team member left behind right before he left the company.

So no one in the team wanted to touch the C# parts, but once per year or so we had to when we (sometimes unknowingly) introduced backwards incompatible changes to the API that the C# component was using for communicating with our Java blob.

Last thing we were thinking about before I left was... NOT to rewrite the C# parts in Java properly, but to wrap all of it in a thin Java layer that we could use as an adapter when the API inevitably changed.

[OkayPhysicist]

How inflexible do you have to be that nobody on a team bothered to pick up C#? Java and C# are probably the two most similar languages that are still considered distinct.

[ZaoLahma]

It was never about competence. Most of us were of different backgrounds.

It was about the need to track down, secure licenses for and install the dev environment that you'd use for those 4-8 hours per year that it took to add support for the new API.

The entire company lived in the JVM otherwise.

[kmstout]

"I myself find it faster to work out algorithms in APL; then I translate these to PL/I for matching to the system environment."

--Fred Brooks, The Mythical Man Month, Ch. 12.

[ghosty141]

Obscure is not even needed sometimes, for embedded stuff you can just use a lang that doesnt run fast enough on the tafget hardware

[TeMPOraL]

I did that once, almost a decade ago, when I was working on some PHP backend code implementing some moderately complex data processing in context of reservations of venues (the complexity came from the fact that venues could sometimes be reserved fractionally, and reservations could sometimes overlap, based on a variety of factors). I had a huge mental block then, caused by overall burnout on the project I got stuck in.

Back then, I've had my first crush on Lisp, which made me think a lot in terms of higher-order functions. When I noticed that thinking "in lispy ways" lets me avoid mental blocks, I used this to finally figure out the solution for my work problem; I then implemented a quick and dirty prototype in Common Lisp, tested it, and proceeded to rewrite it in PHP.

Obviously, it was a slog, but half-way through crying and thinking things like "if only PHP had #'mapcan...", I finally figured that, with a little abuse of some more obscure (back then) PHP features, I could implement in PHP all the high-level constructs I used in my Lisp solution. So I did, and then I was able to trivially translate the whole solution to PHP.

End result: it worked, but it's good that the CEO didn't manage to hire those promised additional developers for that project, because I do not envy anyone who would have to read through my hacky solution implemented on top of a non-idiomatic Common Lisp emulation layer...

So sure, write the PoC in whatever obscure language you like, but be aware that past certain size/burnout level, someone (or you) may figure it's easier to port the language you used than just the PoC.

[majewsky]

I can't remember seeing Greenspun's Tenth Rule invoked so literally.

[fho]

That story sounds very familiar to me ... I was working in Java but used Haskell for toy projects ... the amount of "if only Java had" thoughts were insane and I tried to do things with Generics that just weren't possible.

In the end I actually were able to use Haskell "in anger" for a work project ... that quickly cured me and actually getting things done in Haskell became the same slog.

[loloquwowndueo]

I’ve seen entire teams get fired for using a non-approved language to build the PoC :(

[btbuildem]

I've done this a number of times, it seems to work quite well, and I don't think of it as malicious.

A "softer" way of handling this is to assign the prototyping / PoC development to a different team. The tribality / process worship / power dynamics between teams virtually guarantee that no code will be reused between the PoC and prod.

[delecti]

Do you have experience with that second approach actually working? I'm currently stuck maintaining and upgrading multiple microservices that are a total mess because nobody understood how they were built, and we just had to cope with their weird spaghetti.

[btbuildem]

The way I've seen it work is that the PoC defines the features, then the dev team breaks this down and implements it any way they see fit. It's up to the teams to maintain their best practices and interoperability of the different solutions. Whomever built the PoC doesn't face any of these constraints, their focus is to help finalize the functional spec.

[auggierose]

You also lose knowledge gained through building the PoC.

[btbuildem]

I think that depends on why you built the PoC in the first place. Looking through the comments here I get the impression most people are looking at it as "is this technically feasible", while in my experience a PoC / prototype is usually made for business / usability validation ("is this valuable / will people use it").

[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.