After Hours

How Networking Affects Release Cycles


A few years ago, I was talking to a friend of mine about the merits of console video games as opposed to PC games. One of the points that came up was that console games generally had to uphold a higher level of quality, simply because once a game shipped, there was no way to make corrections. A few days ago, he and I were chewing the fat, and the fact that the Xbox 360 has had to have its firmware patched via Xbox Live, as well as a few games needed to be patched, smashed that advantage that console systems had. What changed? Someone noticed that most Xbox’s had access to a network to easily patch the system. My old school Nintendo never once crashed, except for in the cases where the contact were dirty or the spring loaded system did not “set

About

Justin James is the Lead Architect for Conigent.

3 comments
Wayne M.
Wayne M.

The make or break aspect of agile development is the ability to generate high quality software. One can choose to have short release cycles without quality, but this results in the "ship now, patch later" syndrome. This is the usual result of trying to get short iterations out of a standard waterfall approach. In an agile approach, the order of addressing items becomes reversed from the traditional waterfall and this is what brings higher quality into play. In agile development, one of the first issues to be addressed is how to deploy. One can start with software that does no more than display a version number and take it through the deployment process. Would you actually put this in production or ship it? Of course not, but the excercise of getting the software to a shippable state is worth the effort. Testing is heavily emphasized in agile development and there is typically much more extensive testing done than in a typical waterfall approach. Furthermore, testing has a clear purpose; it is no longer some variable length activity done at the end and often cut in a crunch. Tests are used to precisely define what the software is to do. We eliminate fuzzy definitions because to code an automated test we need to precisely define what is to happen. Then it is a matter of writing code to pass the test. Scope is highly constrained in an agile approach. The valued skill is the ability to decompose complex operations or functions into a set of simpler items. This is quite the reverse of the typical waterfall approach where someone tries to combine disparate functions into more generalized, but more complex operations. Quality is increased, because the development team can focus on a small number of simple operations for each iteration. The development team can get the details right before trying to expand the scope in following iterations. The bottom line is that if a developer or a development team is producing low quality software in an agile environment, he or they would be producing equally low quality software in a waterfall environment. Although, there is some comfort in having an indefinite length test cycle to try and cover up the poor quality, this approach leads to months or years of slippage before management pulls the trigger and ships the software and schedules the required update to follow.

Justin James
Justin James

Do you think that the ease of updating software in networked situations or thin client/Web apps promotes sloppy code? Or was the "old way" just as sloppy, but not as exploitable due to the lack of connectivity? J.Ja

rhoward
rhoward

Regardless of network connectivity, there has always been sloppy coding work and bug riddled applications released to the market (Do I need to mention MS-DOS 4.0?) With the availability of the Internet it has allowed companies to get away with sloppy coding with a lot less pain than the would have in the past, meaning that standards are not needed to be as rigorously enforced. Code writers should take pride in their work, and development managers need to understand that writing quality code is more important than the current "she'll be right, lets fix it in the service pack" attitude. The goal should be to relase code that works, not code that works "Most of the time".