One of the things I’ve personally learned and been touting it ever since, is that it’s ok not to make perfect code in a hurry or when the real target is somewhe

One of the things I’ve personally learned and been touting it ever since, is that it’s ok not to make perfect code in a hurry or when the real target is somewhere else, if the crude method solves the problem for long enough and is capsulated well enough and the intent of the crude solution is documented and it has tests. Documenting the intent is useful for the next programmer to understand, why the solution has been enough for the needs then and to quiet the DailyWtFs for the next guy poking the code. By crude solution I mean half-hardcoded or not well generalized methods as the other cases are coming in a year or so. This is also a way to limit the scope and to achieve deadlines. What this means though, is that when new needs arise we need to go ba k and make them better later. Kind of managed techincal debt.