When you know what you're doing is a quick (and dirty hack). That self-awareness is a core ingredient for taking hack-aware measures, such as documenting your code, planning for technical debt, and knowing exactly when things will come to a head.
A quick and dirty hack is never justified where security risks are concerned, in my opinion. With that said, I've launched a product in the past that had a glaring security hole. It wasn't oversight on my part - I just didn't have the time to fix it before launch. Mercifully, post-launch I got volunteer devs who joined me in working on it (it was an open source project).
A quick and dirty hack may be a go-to method when the thing you're embarking on has so much schlep that doing it right the first time almost certainly means you won't do it at all. In such a situation, it may be easier to fix a hacky solution than to start from no solution at all. I guess that's the point of all MVP philosophies.
When you know what you're doing is a quick (and dirty hack). That self-awareness is a core ingredient for taking hack-aware measures, such as documenting your code, planning for technical debt, and knowing exactly when things will come to a head.
A quick and dirty hack is never justified where security risks are concerned, in my opinion. With that said, I've launched a product in the past that had a glaring security hole. It wasn't oversight on my part - I just didn't have the time to fix it before launch. Mercifully, post-launch I got volunteer devs who joined me in working on it (it was an open source project).
A quick and dirty hack may be a go-to method when the thing you're embarking on has so much schlep that doing it right the first time almost certainly means you won't do it at all. In such a situation, it may be easier to fix a hacky solution than to start from no solution at all. I guess that's the point of all MVP philosophies.
Very well said.