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