Question

My project invovles me to make a lot of changes on the production code. The requirement keeps coming up and I need to make changes and deploy it as soon as possible. I sometimes end up creating patch work sort of code because some of the requirement would not fit into the overall design of the software. How can this be handled effectively? Any design pattern to handle this?

Answer 1

I’ve seen this happen many times and it always ends in tears. The last time the customer lost millions of dollars before they improved their process.

Users always want new requirements to be made available ‘as soon as possible,’ but they do not understand the risks of making the changes in the same way that you do. They see the cost of not having the feature but they don’t anticipate what would happen and how much money would be lost if the change breaks something. (I don’t mean to suggest that you’re not a good developer, just that in any non-trivial software there will be bugs and that uncontrolled changes are likely to expose them more quickly.)

So, I think you need to take a step back and try to instigate a regular release schedule. There will be resistance but you can be more effective that way. Of course sometimes there will be a change that needs to be made immediately, but if there’s a schedule then the onus will be on the user to justify why breaking the release cycle makes sense.

Oh, and as everyone else suggests, you need technical infrastructure like a staging/testing system, one-click release procedure, etc. (See The Joel Test.)