[ianamartin]

One technique I've used as a team lead to limit tech debt that makes it into production is to have devs write prototypes in a different language than what we actually support in prod. This has a few really nice advantages.

1. Devs enjoy getting to use new languages in the real world, and helps keep us learning.

2. The better you know a language, the more tempting it is to take shortcuts. When you don't know a language well enough to write really gross things that work "for now", you have to think carefully about the simplest possible solution to a problem that you can express clearly in an unfamiliar language.

3. You learn tons the first time you solve a particular problem. At the end of the solution, when all of your hacks and tradeoffs are fresh in your mind, you are the best possible person to tackle all the shortcomings and immediately do a rewrite in a language you are expert in.

3. Management really can't twist your arm to just go ahead and transition the prototype to MVP. All you can really do is throw it out there as a public beta with no guarantees while you build the MVP properly using everything you just learned from doing it the first.

4. You can start collecting feedback on what users want included in v1 and get an idea of where the user base is heading with their desires and plan some of that into your design, again reducing long-term tech debt.

If your prototype sticks the landing well enough for management to decide to move forward to MVP, then it's good enough to mark your territory in the problem space while you do the rewrite. You won't lose competitive advantage while it's sitting out there in a separate VPC collecting users and activity.

In a healthy company, this isn't a difficult sell to management. They'll understand the short and long-term value to the company. In more toxic environments, it will look more like you're throwing a poison pill into your dev process—which you kind of are. So, you know, tread carefully. But when people buy in to this process, it works really nicely and has far better long-term outcomes.

[aeternum]

> The better you know a language, the more tempting it is to take shortcuts. When you don't know a language well enough to write really gross things that work "for now", you have to think carefully about the simplest possible solution to a problem that you can express clearly in an unfamiliar language.

This has not been my experience. Much of the worst code I've run into was written by engineers that were new to a language or framework (including myself).

[ianamartin]

To be clear, I am not suggesting that the resulting code will be good. But it tends to be more basic and not rely on weird tricks that deeper knowledge of the language will allow you to do.

My larger point is that the first attempt to solve any problem in code is going to suck, so you might as well suck in a different language that won't ever have a chance of being deployed into prod. You learn some things, you get some exp with a new language, and a better frame of mind for solving the problem in a better way.

[shaicoleman]

Moreover, what's idiomatic in one language isn't in others. Non-idiomatic code is one type of technical debt, and you can get that when translating code from one language to another.

[danjac]

That's because developers see early-stage startups in the same way musicians see dingy pubs: a badly-paid and generally unpleasant venue to learn your craft and make all your beginner mistakes with minimum responsibility and damage to reputation. You don't want to be playing in dingy pubs all your career, though.

[suc_syn]

> The better you know a language, the more tempting it is to take shortcuts. When you don't know a language well enough to write really gross things that work "for now", you have to think carefully about the simplest possible solution to a problem that you can express clearly in an unfamiliar language.

I have the opposite experience, the worst performance bottle necks I have had to trouble shoot are from principal engineers (and tech leads) that use medium to high level abstractions in a ruby on rails that don't actually understand what how many sql commands they are triggering by writing clever one liners that taco my db, from a rails 2.4 method that has a much better rails 5 system they don't know about.

[ianamartin]

I'm confused by your example. Sounds like someone who knows (or thinks they know) a language well writing code that is "good enough for now" and causing problems down the road?

[passerby1]

Maybe I'm purely wrong but this sounds like a "CV-oriented development". (Which is motivated by add as much languages and stacks as possible to CV).

[playing_colours]

> The better you know a language, the more tempting it is to take shortcuts.

I used to work with experienced and passionate Scala developers. On the one hand, their expertise helped them to avoid common language and runtime pitfalls.

On the other hand, the desire to produce elegant, pure functional code, experiment with and utilise powerful abstractions slowed the development down, led to the code that was hard to understand and jump on for new team members.

[kyawzazaw]

How is the runaway to allow such practices?

[ianamartin]

The time consuming aspects of new product dev are normally not around the time it takes to write the code. It's translating product requirements into solvable problems, logic flows that solve those problems, bumping into unseen edge cases in the product concept, and coming to consensus about what compromises are acceptable in the prototype, bumping into sharp edges while you flesh solutions out because you didn't anticipate a thing when you started your base design or didn't understand the relationships between objects and functionality when you kicked the project off.

These problems that take the most time in any project are mostly human, conceptual, product, and communication problems. Not code problems.

Once you have sorted out all of these problems and solved them, a rewrite in a different language with a better design moves very quickly. You don't have to double the runway or the time to MVP. Time estimations are always wrong anyway. But in my experience when I've gotten buy-in for this approach I would guess it adds 25-30% of actual time overhead to a roadmap. Prototypes always take longer than expected, and an immediate redesign/rewrite takes less time than expected.

Selling this approach to leadership really boils down to clearly identifying the value of developer time. It's not code; it's solving business problems. Once those are conceptually identified and solved, the design and code tend to fall into place without a ton of trouble. The problem is that no one really knows what the business problems are until you try to solve them and really dig into the details.

Prototypes should be understood as the process of defining the problem space and uncovering all the hidden issues that people haven't really thought through just yet. MVPs should be an actual product based on that exploration and problem definition and solving. What I'm suggesting here is really just a process boundary that reflects the difference between the two things.

"Can runway handle that?" is really a lot like asking if you can afford to build a product at all.

[ajoseps]

It really does depend on the management and environment of the company as you’ve stated. I might be more cynical about this, but I see it more likely that management would just leave the project at the prototype stage, release it, and move dev resources to other things.

[ianamartin]

This is a definite risk if you haven't planned for it and got buy-in. But it's a risk that's also fine with me: I don't want to support and develop shitty prototypes that I've whipped up and know to be awful from a maintenance perspective. So if my garbage gets sidelined and I go work on something else, that's also a win and also not my problem anymore.