I've worked in environments in which programmers essentially develop on production, fixing things as they cropped up. It wasn't pretty.
I've also worked in environments in which any changes required a CRF, which would then be passed by the engineers for a quote, approved by management, fixed on development, tested on test by QA, released to stage by technical services using a form submitted by the developer, and then scheduled for release to production by technical services.
The latter system always seems great in theory, but it can be mindbogglingly bad in terms of fixing small issues or getting anything done in a reasonable period of time. One issue with it is that it makes everything expensive: time that could be spent by developers, testers, system administrators, etc, on getting things done is spent instead on meetings and bureaucracy. And all groups end up resenting one another because their procedures are preventing progress.
So what happens if you try to fix a spelling mistake in the above environment? Well, unless it's prominent, nothing. You can't. It's too expensive. The only way it's going to be done is if a developer decides to fix it while doing a lot of other scheduled work.
What's the happy medium? It all really depends on the application you're developing. If you're talking about an application that's going to be deployed by a third party, who'll expect "releases" and "bug patches" - essentially, the type of application that, once upon a time, was distributed on CDs and sold in stores - then the above isn't actually a bad model to use.
Internal projects, be they tools used by your colleagues, or the code that supports your public websites, need a somewhat different approach. Your business needs to ask itself to what extent temporary downtimes are acceptable. You need to make heavy use of backups and SCM. And you need to design a rational development process against your specific requirements.
No comments:
Post a Comment