Hacker News new | comments | show | ask | jobs | submit login

Thanks for the thoughts.

We're at a very greenfield stage of development, so part of the problem is that we are yet to feel much technical debt pain from everything that is going on. And a lot of it is invisible. Eg: in the example above, I needed to put aside time to review the code that was created for component X. Because it was written in Python, this review was quite a lot harder than if it was well written code in a more structured language. Most arguments to most functions have no obvious data type documented or constraints around nullability set etc., so figuring out what everything is involves a tremendous amount of reading code and navigating up and down the code hierarchy. Multiply this by every team member who has to understand and ultimately maintain this code and you have a tremendous cost. So in a real way it is definitely costing us already, but its very hard to measure. But as you say, my real worry is about the longer term. It's easy to figure out what a data type is when a function and its caller are right next to each other in the same file. But as things grow and they get split apart, maybe even into different modules or projects altogether it gets massively harder to do. We could go all in on type annotations but I see it as a bandaid compared to the team actually investing in using a core structured language where the typing is a first class citizen.




MyPy and tests.

Do E2E testing, test the API. If you later find out that the implementation is lacking, yoi can swap it out with confidence, if you have 100% coverage of your API spec.

Also, as a sort of management recommendation, you need to set the bounds and find the people that can work with you, not the other way around. (Yes, of course, you work with what you have, but this doesn't mean anything implemented in spare time must become the next cornerstone of the company/product.)

And you must spend a lot of time growing your teammates. Because with a great team a rewrite/refactor will lead to better results, with the same quality team, even in a "better" language you will only get similar low quality results.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: