Search Unity

Short Cycle Development

We are very close to releasing version 4.1 and I’d like to give you a bit of insight into the changes we have been doing internally for this release. I’ll also give you a bit numbers to chew on.

The Problem

In the previous 2 releases, 4.0 and 3.5, we had a very, very long release cycle. 4.0 work was started in January 2012 for some people and everyone in the department shifted to it in early March. We released it in November, giving us 11 months of coding and grinding without actually giving the world any value in that period.

The second part of the problem was the way we were dealing with making features and stabilizing them. Developers would frantically make features ready for “Feature Complete”, at which time QA would dive in and find a bazillion bugs. This then quickly diverged into a war of bugs, where developers would be trenched in bug fixing for months. Literally from July to November, bugs were the primary thing everyone looked at, which turns a release into a death march.

We wanted to get out of this vicious cycle and at the same time improve the quality of the product.

Enter Short Cycles

Our solution to the problem was to push our entire cycle down to 2 months. 2 months from the first alpha to the final release. In reality the cycle is longer, since the features are obviously being built before the first alpha, but those 2 months is the rough timeframe we have between releases. There’s a whole range of consequences of this approach:

We don’t know what is in each release. If stuff is ready for an alpha, it comes in, otherwise it goes to next release.

We have overlapping cycles. Development of 4.2 has been ongoing for a long time while we are stabilizing 4.1.

We get features out to users much more frequently than before. This gives us better feedback on the individual feature, thus better test coverage.

Our betas are 100% feature complete. It is absolutely out of the question to introduce feature once in beta. This was not the case before when a release could be 4 months away.

Another benefit we reaped from this is that QA are now having their hands on features ahead of the alpha release. Previously we simply weren’t staffed for it, but this has changed and we are now having time to weed out the worst bugs before the alpha crew gets them. Our internal demands for getting stuff into trunk is simply higher than previously.

Numbers

First I’d like to show you a “burnup” chart of the effort on 4.1. As you see the work started a long time ago and the bug fixing naturally takes off for real when we start the alpha cycle and slows down when we reach release candidates and raise the bar massively for what can enter. About 330 bugs have been fixed during 4.1

A lot of our test coverage comes from our fabulous community and we take them very seriously. As you see in the below chart, we have handled 97% of all reported incidents, this number will be 100 very soon. We have recieved 231 incidents in total, converted 181 to be reproducible bugs and 69.4% of those are either still active or have been resolved as fixed. As a bonus info I can say that our communities account for 36% of all the active/fixed bugs found in 4.1, thank you very much for that!

Enter the burnup for 4.2. This cycle is more representative of how it will go in the future, since 4.1 was our very first and lots of changes had to happen.

It’s interesting to notice that we released 4.2 alpha 1 a few days ago and we already have 200(!) bugs fixed in this release. Before even getting the first user on it, we have shaved a massive pile of technical debt away. This is exactly what we wanted to achieve!

More to come…

As you can tell from the above, we’re full speed ahead on version 4.2, which will include more good features for everyone and the astute reader will probably figure out that we are also having lots going on already for 4.3 and 4.4. This is going to be an exciting year. My personal goal is that we deliver the highest quality game engine you will find on the market and the quest for that continues ever onwards.

19 Comments

This sounds pretty awesome. Smaller release cycles seem a very very reasonable approach and it’s really great to see that you’re aiming for solid-releases, too! :-)

I’m still waiting impatiently for the new GUI and the sooner I can get my hands on that, the better.

Honestly, this really is the one feature that matters most to me and it’s very sad that it’s not here after the promising announcement at Unite 2012 (not in terms of “you promised, now deliver”; I can totally relate to “it’s ready when it’s ready” … but “wow, this already looked very very cool to me, so when can I finally use it in production”?)

Thanks and congratulations of the process improvement in UT.
I think even better than have features in our hand sooner it has the great of more tested and more stable software as you said as well and more importantly, hopefully developers will have a much easier time and less presure so will focus much better on their tasks and will be much more creative and productive.

I’m pretty excited about the shorter release cycles… it’s always exciting to hear that a new version of Unity is available with new features and stuff to play with, so if that can happen 5-6 times per year instead of 1-2 that’s a lot more fun.

@Stephane: We are very, very cautious about announcing any features and timelines anywhere, unless it actually hits a beta version. However many caveats and disclaimers we ever put on anything, people take it as a promise and we will not have that misunderstanding hanging over our heads. Things are ready when they are ready.

Hi this is great to have such short release cycles. However, what is the proper way to have some visibility on the upcoming features? Since we are regularly launching new projects that use Unity, I’d like to know far in advance what will be coming. Think the new GUI: When should we expect to have it?
Also, since we are developing some tools for the asset store, is there a way to get an early access into the Beta process?
Thanks

@Fernandes: your feedback would probably be best directed at the Playmaker/uScript/Antares teams – tell them the ways in which their products are ‘very limited’ and see what they can do about that. Having them fix the limitations in their existing packages is probably going to be a lot more efficient than trying to get Unity to write their own visual scripting solution from the ground up.

Anyway, shorter release cycles are definitely a good thing. Though Thomas, you said “It is absolutely out of the question to introduce feature once in beta” – might be worth making sure that the beta testers know that ;-)

@IAN, I know, like i said I’ve been using playmaker and uscript and i do end up with graph spaghetti.
Visual tools are always limited but they are EXTREMELY useful as well. As much i would like to start programming, i cant simple leave everything and learning. As you know, good programming skills take years to develop. I don’t have that time.

I do hope Unity team realize that a Visual coding tool is absolutely needed. ASAP :)

However, at some point, you should really learn how to write code since you’ll inevitably wind up with “graph spaghetti”. Ultimately, code can be made more modular, reused and shared. Not to mention there are far better ecosystem of tools (version control, linting tools, libraries, frameworks, etc.).

Hi Thomas!
Great post, although like Mike i was expecting to see some features.

Can you tell me if you guys are working in some sort of Kismet/Flowgraph? It is most likely the important feature in a game engine. Especially for Artist with no coding skills like myself.
I am aware of assets like Antares, Playmaker and uScript, they are good but they are also very limited. A feature like Unreal or Cryengine would be a must.

Studio investing for example in 10 Unity Pro licenses with mobile AddOns (45 000 $!) should be sure that for next X years they will have access to the new versions of Unity what allows them to publish to new version of operating systems (I don’t have new functionality in mind).