Friday Facts #135 - Getting Organized

[K0nr4d]

I love the look of the new flamethrower. I wish the picture would be bigger so I could use it as my background.

[Supercheese]

IT WERFS FLAMMEN!

Jaaaa~

I might just need to make an artillery mod to enable long-range napalm shelling of biter bases.

[quinor]

About code review:

I'm currently in a team with very strict code review. We use Gerrit coupled with Jira. Each person has got his personal reviewer (other team member). If there are any issues, the commit is being fixed, fixes are ammended and pushed for the gerrit again. When this review passes, second person (one of the senior programmers) does final review. Same happens and if there are no issues code goes to master. We also use automatic style checkers (python pep8, but there should be ones for C++).

It works really well so far - code is consistent, well-written, even commented (!)

For less room-shouting I recommend splitting devs into 3-4 smaller rooms - it's easier to keep silence then and yeah, it helps alot

For procastination prevention best I know is just to move tasks people are stuck with for too long to somebody other, so they don't get frustrated and stay productive.

[Proxy]

I might just need to make an artillery mod to enable long-range napalm shelling of biter bases.

dude, i would love some Nuclear Rockets, or Rods of God... or simply a Railgun Turret.
but more Weapons are only one side of this game tho...
so Only adding Weapons would cause the Usual Biters to be Underpowered.

[Darloth]

You say that, but right now they biters do not apply themselves.

They're more of an environmental threat than a directed one, even on pretty high biter count. While biter variety would be great, different biter behaviour can also make a VAST difference

[HulkingUnicorn]

[...]I love the flame turret art, and the idea of flamethrower turrets. I hope that'll be an AOE turret.[...]

Considering the flamethrower mechanics are being changed I expect some conal action. I'm Imagining a fire control support building to prioritize nearby turret targeting (for example lasers focusing on big guys, flamers taking out the small fries).

[gallomimia]

Was wanting the flamethrower turrets for quite awhile now! I hope they are dual fuel: either thru pipes or thru flamethrower fuel canisters.

With regards to your organization and especially the messy Trello board, I do suggest you ask for Michaela's help. Don't expect her to do it for you, but get some things sorted out with regards to priority, which need more details, and which can be shelved. Then assign a few team members to do those tasks she lays out.

[roaringdragon2]

I think that the flamethrower turret should be able to use either flamethrower ammo magazines or some oil product brought in through pipes.

[ritonlajoie]

Nice blog post. I would suggest https://www.reviewboard.org/ , it's something widely used, you will find many plugins for all sort of things to connect it to. We use it at the office and it's pretty neat because it's very simple but functional.

[bk5115545]

FFF's are great but I really love the technical ones. I'm glad you guys do them though and I wish every development group would.

[Marchombre]

Could someone post a screen or the pic about the flamethrower ? can't see it cause of the main site problem.

[MrDrummer]

4 hours later and the issue is still not resolved. to reiterate what Marchombre said, could someone post a link/upload of the screenshot/gif please?

[keyboardhack]

Here it's



And the FFF text if you can't load it.

FFF 135

originally I intended to dedicate most of the post to the technical aspect of our new Multiplayer User Authorization mechanism that I have been working on in my programming time. Then I thought, hmm it would be nice to start with some project management changes that we are looking into and experimenting with. Then I pretty much ended up making a full blog post about that =) It might give you an interesting insight into issues that we are dealing with. The Multiplayer User Authorization mechanism will definitely be described in one of the future FFFs.

Slowly growing

As mentioned in the previous FFF there is a new team member here with us. Her name is Michaela (or Mishka) and one of her main responsibilities is to get us a bit more organised=)

At the moment we are 11 people in the office with 2 external collaborators. Our short/midterm goal is to grow to about 15 people in the office (we are still looking for good C++ programmers ideally from Europe!).

Our approach to "project management" so far has been very loose and organic. Somehow we feel that we have reached a boundary here and need to start working a little bit on our methods of working together, sharing the results of work, etc. This especially holds true with our (moderate=)) growing ambitions.

Defining the areas

So we spend quite some time brainstorming and figuring out what we believe is working well, what could be improved and where we want the things to go. We came up with 3 basic themes / areas for getting organised. In short these areas are: Transparency and knowledge sharing, Direction vs. management, Productivity. Let's have a look at the descriptions for all of these.

The next step was internally clarifying three aspects for every area:

What is the current situation and why we want to change it.
What is our goal.
What tools and processes can we use to achieve the goal.
We are very aware that changes like these can be sensitive. Especially when we start using words like project management, goals, processes, etc. So our main criteria for the whole set of changes is to not overdo things. This means make small changes step by step and stop when we have achieved our goals. Also we are aware that processes and tools are here to serve us and not the other way around so we will try to keep our minds open and abandon things that won't work for us.

Area 1: Transparency and knowledge sharing

Till now, often a developer would work on a task for quite some time without too much interaction with others. Hence there was a lack of feedback on how he is doing, if he is stuck or not, if what he is working on might be related to what a different dev is doing, etc. So far our main tool of communication has been talking in the office / at lunch and Trello cards. Trello has worked really well for us, but it is getting full of cards, generally messy and often there is little information for particular cards and so on.

Ideally we are after a situation when people have a general overview of what others are working on. We are still small enough to do this for the team as the whole (imho it becomes harder for teams of 20 or more people). This should also improve productivity (people can help each other in case they know how to solve an issue someone else is stuck with).

We started by having a short stand-up meeting twice a week (currently Monday and Thursday at 1 p.m.). The meeting (ideally) takes about 15 minutes, requires all the team members to be present and standing (to keep the pace going). We start by announcements if there are any (this and this person is coming for probation, we have made this and this presentation, etc.). Afterwards we go in a round and everyone gives a brief status. This means: what he is working on, if he is doing ok or is stuck, if he needs to communicate with other people, etc. This takes (ideally) less than a minute for a person. In the near future we intend to have "minutes" (short transcript) from the meeting in the written form to inform (and gather feedback) from the members not present. The main inspiration for stand-up meetings came from my pre-Factorio (so long ago ) programming job in Amsterdam, where it really helped us as a team of about 12 developers.

Another potential change we are looking into here is become more verbose in our Trello cards. This would mean giving proper description to cards, links to forums or other related cards, using checkbox lists, etc.

Area 2: Direction vs. management

So far the project direction and project management "roles" have been concentrated in the hands of the same people (kovarex, me and Albert). This makes sense for very small teams however it is also quite limiting. The basic issue here is that the direction is more like a vision (I imagine a person who knows where the ship should go) while management is more like an every day task making sure that the ship actually goes where the direction has been set.

So we want to split the direction of the project from its management. The three of us would still be giving the project direction however the part of the management would be given to Mishka and part to team members themselves. This should free up some of our time which we can dedicate to programming / art as well as allow us to be outside of the office more (summer is coming =)).

We imagine that this would be achieved partly by cleaning up the Trello a bit. We (product owners) will need to spend more dedicated time making sure that the cards, priorities and assigned devs / artists in the Trello are well defined. On the other hands this frees our hand because when a person is finished with a task he / she will know what to do next.

Another thing we intend to improve in this area (overlapping with the next area) is the code reviewing process. At the moment most of the code reviewing is done by Michal in a kind of random manner (he reads some commits but not all of them). The goal would be to have code reviewing across the team. We are still looking for a simple and efficient tool to achieve this (let us know if you have any recommendations).

Area 3: Productivity

We are not after moving forward as fast as possible at every cost. Balance is more important in our eyes - moving forward while still enjoying the work. However recently there has been quite a lot of distractions around the office and we feel it is time to start looking into this.

Haha, a good example from the real life. Just before I was about to write the next paragraph, in the room next doors there were two people programming and one shooting nerf gun bullets around (consistently hitting monitor of his college who was coding =))). This can be a good fun now and then, things like these decrease productivity not only of people involved but pretty much of all the people in the vicinity (most of the office). Again it is about finding balance.

So we are after decreasing distractions in the office a bit. We have started using Slack and encouraged people to use it to communicate to others when the face-to-face talking is not necessary. Besides that, it comes down to being mindful about whether my actions (i.e. sharing the latest news from the web by shouting them out in the room, having fun with colleague at his computer) are not disturbing others too much.

Another aspect would be the oblivious "fight against procrastination". However we don't feel this is such a big issue at the moment. Hopefully all of the people here have a strong internal motivation to work on the game and make it as good as possible which should take care of this on its own.

Back to the game

Ok so let's have a look at some progress at actually making Factorio and not only trying to get real making it. For quite some time Michal (posila) has been playing with fire and flamethrower turrets. Vaclav has been doing the art for these. This is quite a big subject which deservers a blog post (or substantial part of it) of its own and it will come in the near future. But to give you a bit of a sneak peek into the process you can checkout the hi-res render of a model of the flamethrower turret below:

[JerryLive]

Just want to share my two cents on a few shortfalls I see in you "Stand-up" plan as I have been down that road and would hate to see you fail. Love the game and hope it keeps progressing.

Fist, do stand-ups daily. If people are talking to much or long user a 2 minute timer and cut them off. People will get the picture soon enough. These are "mini" planning meetings to keep everyone aware of what others are doing and to offer help were needed. Also, you will see problems sooner.

Second, don't write it down what you talked about at scrum. First off, I now have an excuse to miss and can just get caught up by reading. Encourage people to communicate by making them ask someone what they missed. Second, it becomes a status meeting and it is not that. Again these are planning sessions for the day to keep each other informed as to what we are doing. People should want to cone and it should add value.

Lastly, you might want to think about splitting into two teams if possible. I know the difficulties and issues with this but if you are looking to 15/20 people that's 30-40 minute stand-ups at just 2 minutes a piece.

There are some other red flags in the things you said for me at least being in the software world but stand-ups daily are good for anything and any team. Not sure of your family life but a quick couple minute chat with your significant other each morning can make a life so much easier, especially once you have kids and all the extra that adds.

[jaworeq]

Hey, about handling peer review with the process - we were using svn and trac with bunch of midifications (trac is open-source, svn allows scripting in form of e.g. pre-commit-hooks) aaaand:

1. Every svn commit required a ticket in trac
2. After a commit, ticket would change owner (to previously set reviewer, but anyone could grab it and review) and status (to peer review)
3. Changes dont go further (to test env) until all the tickets are reviewed.

So that's theory, set for us by management, while in practice nobody ever had time for proper review and AT BEST it was limited to testing if code even works. But theory itself should be adaptable.

[quinor]

They use Git as CVS, but it allows some scripting too.

[Taron]

I work in a small team and we organize our work with JIRA and host the code on a private Bitbucket Server (quite cheap for small teams) JIRA and BitBucket work well together (like Ticket-Links in Commits and Branches and stuff like that).
For Code Review once a feature is done a Pullrequest is generated, then our CI (Jenkins) builds the pull request and runs all tests. Another member of the team has to review the pull request and approve it (or states that still work is to be done).
Only when all tests are green, the build was successful and a team member has approved the pull request, it can be merged into master (or any other develop branch, depending on your strategy). For coding style in c++ we use clang format which works really well once the team could agree on a style (just use it in your IDE for smart indentation and as a pre-commit hook). Included in the tests is a static code analysis by cppcheck and certain quality gates which force that the test coverage does not drop under a certain level and that new classes have tests and so on. All this looks like quite a bit of overhead, even more for a small team. First we feared we would lose productivity by reviewing every pull request and this rather strict quality gates, but in the long run it prevented so much trouble and extra work that it really paid off. One additonal great benefit of reviewing everything is more transparency and the team knows better what happens.

On a side note: Try pair programming (maybe not for every task). Its quite fun if done right and the results are often much better.

Would be nice to hear from you if any of the tips / recommendations got adopted by you folks. Keep up the great work.

[Kazaanh]

I just hope his reach is as long as the laser turret. Otherwise you wouldn't need a pipe to maintain it, also that huge barrel. I mean that barrel is huge, its gonna spit liquid for a long distance.

Speaking off flamethrower weapon could use some love too, some buff maybe.

[psychomuffin]

Thanks for the updates!

I, personally, still can't believe how much work and growth you are putting into a game that is already so great and seems so complete. I have a hard time seeing how you will make it better. I mean, I do like the things you're working on now, I just worry for you guys as a company. For each additional week of work you all do, how many more sales will that earn for you? Is there a ROI? I just want you all to still be around to make more games.

That said, Are you considering what you'll do next? Any ideas for your next game?

And lastly, when will factorio be done? Do you have a punch list? Or a rough idea or goal on when to be done? A Month? By Summer? Fall? I'm itching to binge play the game once steam achievments are in.

[Marchombre]

Here it's

Nice