The balance between deploying and not deploying site updates
Updates are exciting in any web game, because they are a tangible demonstration to users that the devs are still actively maintaining and improving the site. Bugs get fixed, the user interface becomes easier to use, and every so often, new features see the light of day.
However, to some users, it may seem that site updates on Button Men Online are few and far between. For a while, we were successful in maintaining a monthly release cycle, but that's proven to be impractical over the long term. So, why does it take so long to bring you new features?
The most important consideration here is that the devs are busy people. One of the overriding considerations that we have always tried to honour is that Real Life comes first. So, while we might have nominal deadlines, these will always give way in the face of illness, work commitments and social events. We develop Button Men Online because we love both the game and the community, and we don't want the task of developing to become an onerous obligation.
The other important consideration is that we want our roll-out of new code to be as seamless as possible for users of the site. That means that we want to avoid user-visible bugs and regressions as much as possible, while maintaining a high standard for new user-visible functionality. To achieve such lofty goals, we have a number of layers of quality assurance. At the lowest level, we have a huge suite of back-end and front-end unit tests. Chaos has also developed a dumb computer player called RandomAI that attempts to play random moves, which she uses to find regressions and site errors introduced by new code. Finally, we have a group of testers who are asked to try to break things, but also to give their opinions on look-and-feel questions. The different types of quality assurance should eventually give us a warm fuzzy feeling that the code is well-behaved, but this may take a while, especially for a new feature that touches a lot of the code base.
One important corollary here is that we will enter "drop everything" mode if there is a bug that significantly impacts many users on the site. In fact, we intentionally have a one-week merge freeze after each new site deployment to work out any problems with the newly deployed code. Normally, this will be unnecessary, but occasionally, it's been necessary to apply small fixes to both the code and the database when we've missed something in our testing.
So, that's why things take so long from woe to go. We think that we have found a workable compromise between stability and new functionality, although we also wish sometimes that we were able to do more, sooner.
However, to some users, it may seem that site updates on Button Men Online are few and far between. For a while, we were successful in maintaining a monthly release cycle, but that's proven to be impractical over the long term. So, why does it take so long to bring you new features?
The most important consideration here is that the devs are busy people. One of the overriding considerations that we have always tried to honour is that Real Life comes first. So, while we might have nominal deadlines, these will always give way in the face of illness, work commitments and social events. We develop Button Men Online because we love both the game and the community, and we don't want the task of developing to become an onerous obligation.
The other important consideration is that we want our roll-out of new code to be as seamless as possible for users of the site. That means that we want to avoid user-visible bugs and regressions as much as possible, while maintaining a high standard for new user-visible functionality. To achieve such lofty goals, we have a number of layers of quality assurance. At the lowest level, we have a huge suite of back-end and front-end unit tests. Chaos has also developed a dumb computer player called RandomAI that attempts to play random moves, which she uses to find regressions and site errors introduced by new code. Finally, we have a group of testers who are asked to try to break things, but also to give their opinions on look-and-feel questions. The different types of quality assurance should eventually give us a warm fuzzy feeling that the code is well-behaved, but this may take a while, especially for a new feature that touches a lot of the code base.
One important corollary here is that we will enter "drop everything" mode if there is a bug that significantly impacts many users on the site. In fact, we intentionally have a one-week merge freeze after each new site deployment to work out any problems with the newly deployed code. Normally, this will be unnecessary, but occasionally, it's been necessary to apply small fixes to both the code and the database when we've missed something in our testing.
So, that's why things take so long from woe to go. We think that we have found a workable compromise between stability and new functionality, although we also wish sometimes that we were able to do more, sooner.
Comments
Post a Comment