Read this post on our website. Hello, technically this post is the Pi Friday Facts, but unfortunately we can't think of anything special to do... maybe someone can make a combinator cake... that can calculate Pi?

0.17 stable

We released 0.17.69 as stable this Tuesday. It seems it all went very smoothly, no avalanche of crashes, and only a handful of technical support emails about updating video drivers.
Apart from stable, essentially no development work has happened this week; nearly everyone is on vacation (I am even writing this as I sit in the airport waiting to fly to London for a wedding). We're hoping that at the start of next week, with all the relaxation over, and the pressure of stable off our shoulders, we will get cracking on the next updates with renewed energy. In fact I might be a little optimistic in saying this, but I think we are in for some exciting times here in the team. Before now, we have always done a cycle of having the whole team on development for a few months, then the whole team bug fixing for a few months. This binary approach is what gives us the traditional 'stable' and 'experimental' labels. This is not to say that all bug-fixing would stop once stable it out, quite the contrary, but this has been the general strategy. What we are planning, if the logistics of it turn out okay, is to have significantly smaller feature releases, containing only a handful of new features. This is to have a sort of mixed cycle, and a mixed cycle in two similar ways:

• Some developers will be on bug-fixing while others are on development.
• The individual weekly/monthly work of a developer will have a more balanced mix of development and bug-fixing.

For example, while one developer works on a feature for the next feature release, another will be bug-fixing the features in the current release. This is only practically possible if the feature release frequency is relatively high. This new structure has been a long time brewing in our minds, and we think now is the right time to try it out. With the GUIs we really need to do quick iterations and receive fast feedback to the changes. The traditional release flow meant that we could add a new feature to the game, and players wouldn't get their hands on it for months. Then once it is released and we start getting feedback on it, extra time is spent just re-orienting ourselves to the code and how it was written. If the feedback is given expediently, the rework and improvement is much more efficient. Furthermore, I think it is more psychologically effective to work on a mix of bug-fixing and development. This is just theory now, but grounded in some observations I have made over time. Development work, a new feature, new GUI, etc. is generally a long-form creative process. New systems have to be created out of pure thought-matter, ideas for implementation have to be evaluated and determined, and it also involves a lot of 'background processing'. Feature development always has more room for extension, and it is very hard to say 'It is finished'. It is also quite a subjective result, so sometimes it is hard to know if you 'did a good job'. Bug-fixing on the other hand is very short form and challenge oriented. It is like investigating a murder mystery, and really feels like a complete story. Tracking down a problem inside the game engine engages a logical part of your brain, trying to piece together and backtrace where the fault is occurring. Generally the bug has a very clear 'win-condition', and you can close the game and let your mind rest peacefully. The result of a bug-fix is grounded strictly in objective measurements, so you can be reasonably sure if you 'did a good job'. So these two parts of the job are in a way, quite distinct and separate: Development is a long-form creative process; Bug-fixing is a short-term logical process. From all this, my reasoning is that focusing on only one for a long period of time leads to quicker mental fatigue, and that a balanced workload will keep us happier and more productive. In essence, doing development lets our bug-fix circuits rest, and doing bugs lets our development battery recharge. There are also some pragmatic reasons I think the smaller/quicker releases will make things move along more smoothly:

• Bug-fixes after stable will be released within a short time-frame.
• The flow of bugs coming in will be less extreme, no more massive waves with each major release.
• There will be less 'blocking', where unfinished features delay a release. They will just be scheduled for a different release.
• Feedback will be more focused, so it is easier for us to evaluate.

At the start of the year, I read a book called "Rolling Rocks Downhill" by Clarke Ching. It is a book about software project management, it was quite an enjoyable read, and gave me a lot of inspiration to try and optimize our development effort. At that time we were just wrapping up 0.17, so there wasn't a whole lot of room to make changes to the way we do things. Now that we have stabilized 0.17, and with it, completed the 'traditional' cycle, there is opportunity for a fresh approach. I guess I will give the book another read next week... Anyway, thanks to all of you for such a great year so far, thanks to all our friends on the forum and throughout the community who have helped us in the great bug war of 0.17, and as always, let us know what you think on our forum.

[ 2019-09-27 10:30:11 CET ] [ Original post ]