Is 10>2?

By Ashterothi

Fanfest is over, and now it is time to sit down and attempt to digest the torrent of information we received. One point that was unexpected was the announcement that CCP was moving to a ten cycle year instead of a two cycle year. 

First of all, what this likely is not

• This is not a speedup of production. Having six week cycles does not allow more code to be written in a block of time. We may see more content per year, but that should mostly stem from CCP's growing personnel. Releasing more often does not equate to higher throughput.
• This will not slow down production. Conversely, some have said that this could lead to less things being done (or less big things being done). Both of these are false. Again, throughput of software development is not inherently tied to release schedules (as much as some managers would like to expect). 

So what is really going on here?

From what I can see there are two big reasons that this change is being made. People have zeroed in on the fact that this will allow Eve to receive more timely updates to simple systems in the game, but this blog discusses an implication that is much more important to the health of the game.

CCP development follows Agile methodology. Agile breaks development into small chunks called “sprints” the goal of a sprint is to complete a series of components or “user stories” within the preset time and have a fairly stable product by the end of each sprint. It is important to note that stable is not feature complete. Many times a sprint may end with stand in graphics, “this button is not yet implemented” stand in messages, or other such oddity, which are features to be created by other stories in the next sprint cycle. CCP operates on a two week sprint cycle, which means there will be three sprint cycles per release. 

If a feature can be completed in three cycles, great! Ship it out and get working on the next one. However, I would guess that in practice this is highly uncommon. Most of the time polishing and testing a feature could take a large percent of that time, so the chances of a feature going through its entire development cycle in one release cycle is fairly low. 

What this does allow them to do is make tweaks and changes that do not require much dev time (read: module rebalance) and push them out with minimal fuss. 

So, if we aren’t developing a feature in three cycles, why even have a release every six weeks? Simple, they are decoupling the release cycle from the development cycle. In the old system they would release a product, go on vacation, come back and start planning the next cycle (I am sure they had some inklings but nothing was really hammered down until they started into it properly). Features are based on the theme of the expansions and components or goals are drafted for the feature. Once feature goals are created they are “scoped” or given priority. These are broken down into: Must, Should, Could, and Wont.

If a feature component is given a must status, and that component is not feasible given the six month release schedule, the entire feature must be scrapped, or put on hold. This is because release schedules were tightly coupled with development schedules. Expansions were based mostly around what could be achieved in each six month window.

Fixing Bigger Things

By decoupling the development from any given release, a feature is allowed to take as long as it is worth. If POSs can’t be fixed in six months, they couldn’t be addressed under the old system. However, with the new system a team could be spun off and work on it for eight months, or however long is necessary. When it is ready, post your blog and know that it should be on the server in less than 2 months. 

And this is where this change becomes extremely important for the health of EVE online. 

Many facets of EVE’s code base are archaic, and this is no secret. In the past many features have been dismissed as simply too complex to address given their cycle times. However, it is clear that CCP is starting to understand that in order to actually last another decade, these issues must be addressed at some point. 

As EVE matures, the process has to change. If we ever hope to see changes to some of the more daunting systems in EVE such as POSs and Alliance Management, CCP have to change how they plan for development. This new paradigm allows features to be released as they are ready, regardless of how long or short that journey is for that feature.

What we will likely see, and to some extent have been seeing, is rapid fire tweaks and balances as the new development cycle allows for a much more ambitious strategy for these things. They no longer have to wait months to finalize the results. At the same time more long term teams will be spun up to work on the scariest portions of the EVE codebase. The agile methodology gives them the freedom to adapt and evolve as they work through their changes, while the stream of small tweaks and features released over time keeps the public happy and engaged. 

I wish them luck and am happy to see this change.

I hope this clears stuff up for many of you! See you on the next Hydrostatic Podcast!

Game Design Live Session from Fanfest 2014: https://www.youtube.com/watch?v=RJgQOmp29gM

Wikipedia article on Agile Software Development: http://en.wikipedia.org/wiki/Agile_software_development