4 ms·

If you only use good practices at the end it is too late - you have the anchor of the old, unmaintained and untested code around your neck. Additionally, engine

If you only use good practices at the end it is too late - you have the anchor of the old, unmaintained and untested code around your neck. Additionally, engineers who know they are doing crap work are generally less motivated. I'd argue that the difference in time of writing tests is balanced by less time debugging, and the moment you want to re-use the code you know it already works in all the contexts the tests use it in, in fact it was already designed for re-use because the tests and the application use it, so you avoid major refactoring and instead just assemble your Lego blocks in a different shape.

Retric 6y ago
It’s never too late, in the absolute worst case you bin some or all existing code and start over with very clear goals, and an understanding of any needed external API’s etc. Even better you can almost always extract plenty of useful bits here and there. On the other hand if you start every project thinking I need test cases, separation of concerns, continuous integration, scaling etc you’re working without a clear understanding of the end goal or how you’re getting there. Find out some tool your depending on is insufficient and you may need to toss most of what you’ve been working on down the drain with nothing to show for it. Jumping right into whatever is the most difficult problem also means your model of the best architecture is likely to evolve as your working on the problem. Granted this should all be on a sliding scale depending on how novel the project is.