Simply put, deploying code on a set schedule is not practical or effective. Unless you are a bank or medical facility, you just do not have to adhere to such a strict release and deployment schedule. I have had the luxury of working on sites where we do not employ deployment schedules. There are times over the last 10 years where not having a schedule has burned us slightly. At those times, we tried to be more rigid, but inevitably we would go back to our old ways with looser deployment procedures. Now that I am running the development team, I consider the ‘old ways’ the correct way. Over the past 10 years there have been many more times where having an agile style of development and deployment has helped. The benefits far outweigh the few negative experiences we have had.

I have worked with outside groups on projects where the other development team had to wait a full week to fix a bug. Not a critical bug, but a bug nonetheless. Any bug is major to the user that it affects them adversely. If you are a user and you see an issue, even a minor one, do you care that management has deemed the bug minor and the development team is not able to fix it until next Tuesday @ 7:30 PM? No you don’t care. All your users know is that something is broken, or looks wrong, and has stayed that way for 7 days. By that time, you may have turned off users to your site, or at least given them the impression you are incompetent or uninterested in the quality of your site.

Many times management does not like a loose deployment schedule because their sites are complex. Its safer to only deploy code once a week, and in large batches. But this too has its downfall. Many times so many changes queue up that the deploy now becomes very complex. Deploying, testing and monitoring 10 distinct feature/code changes is not an easy task. Other times minor changes get pushed off the deploy sheet, and end up waiting yet another week (or more) before they are pushed live.

Trust me, the site I work on on is extremely complex. There is content, data from third parties, and full featured tools for research. These are only a few pieces of the large puzzle that is our site. If we are able to keep this all running with a lean team of developers and with a loose deployment schedule, your site can too. I’m not condoning a gunslinger attitude or setting code loose into the world at will. You need to test, and trust your developers. You need to monitor changes, and test after its been deployed. You need to check your web and error logs and continue to use software to share information, and discuss changes. Basically, you need to be very diligent about what you put on your live website. But you do not need to wait until a Wednesday night to send code live. Send code live when it is ready. Your users will appreciate it, and you will be a lot more effective in your work.

Related posts:

1. Iterative Development is Effective Here at SmartMoney, we have been using iterative development techniques...
2. Web Development: Because We Care As a web developer you make a product (the website...
3. Find the Right Blend of Ideal and Practical Web Development A few weeks ago I wrote that good design is...
4. good development teams share information Sometimes its hard to effectively share everything among all members...
5. Knowing your users will help make effective decisions If you are reading my blog, there is a very...

Related posts brought to you by Yet Another Related Posts Plugin.

Filed under:
dev team, experiences by bill breen