How to handle the new

When a new required to a project, or an unknown bug is discovered, you have a few ways to address it.

Option 1: Hack a fix.

Warp the existing code to just make things work. Maybe you add an extra hard-coded if/else check, or you make a database column mean two different things depending on what piece of code is reading it. Get the code to compile, build it and ship it.

Option 2: Do it right.

Think about what solution you would've built had you knew about the 'new' requirement or possible bug beforehand. Maybe you would've designed your database tables differently, or separated your code into two separate services. Whatever that ideal solution is, build it and migrate your old system to the new one.

Option 3: There is no spoon.

Build something that renders your client's previous wants moot. Since you're building something that is two steps ahead of what the client (and your competitors) are even dreaming about, you don't have to worry about what the client thinks they want.

So what's the best option? It depends. If you find yourself only doing one of the options, you are probably missing out on something.