“Release early, release often” has been the mantra of the open source community for years and refers to the idea of getting something out to users quickly so that they can feedback, help find bugs (yeah, like my code has bugs!) and shape future development of the software, and it seems to work. Mature open source software is generally stable and secure, taking advantage of many iterations of the development cycle. New software often has features not found in established packages because they’re able to adapt quicker.
So what can we as web developers learn from this model? There’s sometimes the tendency to hold off launching until everything is perfect but do we need to do that? Sometimes yes – incorrect information or security problems are show stoppers and there’s no excuse for releasing bad software but does it matter if a few features from the “desirable” list are missing? Probably not, and the benefits of getting the system out there and used outweigh that.
So that’s “release early” sorted out, but that on it’s own isn’t enough. We must be prepared and able to back that up by “release often” and we’ve got plans here too. On the software side of things, developments of certain applications has moved to PHP running on the symfony framework allowing for faster application development. We’re starting to use some code management tools such as subversion and Trac to keep track of bugs and feature requests and more easily allow several people to work on the same project. The department are investing in new server infrastructure which will allow better testing prior to roll out of changes as well as faster and more reliable access to the sites. Finally, we’re committed to pushing the kinds of services we offer; adopting new technologies early when there is a benefit to our users and not being afraid of the odd bug if it means we’re doing something good.
If you follow blogs in the web/HE community then yes, I did borrow the title from OSS Watch’s recent post, but I was thinking about it before they posted!