3 ms·
> Typing a large legacy codebase written in a highly dynamic language is not as easy. > very few can afford it. Starting a project in a highly dynamic language
by friendzis 5y ago
> Typing a large legacy codebase written in a highly dynamic language is not as easy.
> very few can afford it.
Starting a project in a highly dynamic language is a conscious choice with well-known properties. The second part is interesting, however. Essentially you are saying that gains from development velocity do not offset losses from technical debt, which is a strange observation. I would say it sort of hints at time to MVP being irrelevant business metric (startup runway/survivability aside) at best. This is contrary to typical startup truths.
- nine_k 5y agoAt a certain scale, they do. Case in point: Twitter. They went through a painful transition but they did not have much choice. But sometimes they don't. Case in point: YouTube, Instagram. Both of them are slowly migrating more and more Python code to different languages, but the amount of Python is still large, and AFAIK neither has plans to eschew it completely. Time to MVP is a very relevant business metric. But the same thing that speeds you up in the beginning slows you down later on. If you architect your code past MVP to help replace the implementations of critical paths, it may help you down the line. (Micro)service architecture is one way to do that.