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.

One man show

At work, we've been adopting the Scrum Methodology, and I have reluctantly become the Scrum Master on our team. I have plans to retreat back into a developer role, but that's another story.

At home, I've continued to work on the English To Korean Forum application, where I am the Product Owner, Development Team, Scrum Master and the only Client. As the Product Owner, I just decided to reduce the scope of the application significantly. As the only member of the Development Team, this lowered the the complexity of my application, which made me happy. As the client, the application is simpler to use and it just makes more sense (to me at least).

I suppose this is the ideal that scrum teams are working towards where the minds of everyone on the team are completely in sync.