Category: How we work

We have decided to use Travis for continuous integration builds of our open source repositories. Travis is automatically building the code on all branches and pull requests, which gives all developers that wants to contribute to the project, the possibility to see that their code passes the build. The current status of the latest build on the main branch, is visible through the icon in the readme in github, or on the Bitcraze page at travis.

travis-ci

The projects we have added so far to travis are written in C or python. The C projects for instance, must be compiled with special compilers for the processors used in the crazyflie which adds some extra complexity. We have created a docker image (bitcraze/builder) with the tools needed, to make life easier for developers. If you use the image when developing, there is no need to install tools locally, and the same image is used in travis builds, so you know you will get the same results as the CI-server. This also removes the problem of tools with different versions (and results) in the development- and build environment.

To use the image you can for instance type

docker run --rm -v ${PWD}:/module bitcraze/builder make

Event though it is awesome to be able to create a well known build environment through a docker container, we feel that too much typing is needed to execute a simple make.  To solve that problem we are looking at the possibility of creating a toolbelt that will handle that for you. More information on that later on, for now developers will have to find their own solutions through scripting, aliasing or other means.

Obviously you need Docker to use this image. If you have not tried it out yet, take a look at www.docker.com.

We are aiming for automated testing of our code, and even though we have a lot of work to do, we have taken the first baby step. For the moment, firmware projects are simply compiled and linked to ensure that the code is coherent. Projects that support both crazyflie 1 and 2 are built in both flavours to avoid problems for developers that might only use one of the platforms.  The python client project is only checked for PEP8 compliance, but we are looking at how to unit test. Any input from the community is welcome!

Happy hacking!

For a background on the “How we work” category, see Self organizing

We have done a session in the company on group development. We based our discussions on the IMGD model by Susan Wheelan (https://en.wikipedia.org/wiki/Group_development#Wheelan.E2.80.99s_Integrated_Model_of_Group_Development).

We wanted to understand more about the structures and forces in the team, what to expect and gain a better understanding of our everyday experiences.

According to the IMGD model a team evolves through a number of phases as it achieve maturity when it works together. The phases are

  1. Dependency and Inclusion
  2. Counterdependency and Fight
  3. Trust / Structure
  4. Work / Productivity
  5. Final (if there is a distinct final point)

We had some good discussions that we think will help us in the future.

This is the first post in the new category “How we work”. The intention is to write about how we work and evolve our company, as opposed to most of our other posts that are about the cool stuff we build.

First we need to take a look at the the history. Bitcraze was started by Arnaud, Marcus and Tobias in 2011 when they created the first Crazyflie. They all had day time jobs at the time and were working on the project on their spare time. Forming the company and taking the step to work full time with Bitcraze was the logical continuation of the success of the first Crazyflie.

They are all passionate about technology, innovation and creating cool things, but the possibility of working with interesting stuff was not the only reason to leave the safety of employment, an important driver to form the company was that none of them really felt comfortable in the companies were they were employed. They all have worked in multiple companies where they had more or less the same bad experiences and they wanted something else, something better. To understand the problem, take a look at Dilbert about shipping and managers :-)

During the years there have been interns in the company from time to time. One of founders donned the role of the “boss” to manage the intern and tell him what to do and to make sure the expected result was achieved. The problem was that they did not felt very comfortable with this, after all they were becoming the type of boss they disliked in their previous jobs, they were moving in the direction they had been running away from.

What to do? The three of them had equal relationships, no one was managing anyone else, so maybe one solution was to not employ any more people and continue the way it was? No, more people can do more fun stuff and they wanted to expand. During this spring Kristoffer started to hangout on Minc (the incubator where we are located) and we stared to talked about this problem. We talked about values, drivers, what we want to get out of work and life. Kristoffer has a similar background with similar experiences from the companies he has worked at and they all realised they were looking for the same thing.

I (Kristoffer) became the first employee in Bitcraze, in June, and we have taken an important step in building the company we want want to work in. We don’t really know where we will end up, but know that it is a continuous journey and that we will change over time.

There is a book full of inspiration and clever insights that everyone, interested in this type of problems, should read,  it is called “Reinventing organizations” and is written by Frederic Laloux, read it!

We have taken one super-important decision that will be the basis for all future work:

No one in the company can decide what someone else should do

Yes, that’s right, no one is the boss and no one is a manger – we are self organising. We’re in this together and will evolve together.