Published on: May 23, 2017
11 min read
What makes a good development team? Here's what we think.
Not all development teams work the same way, but there are some values, processes and attitudes that all successful teams share.
Thereâs no substitute for the work of the human brain, but by automating some of the more time-consuming (and sometimes tedious) aspects of a developerâs job, you not only free up time that could be spent on other, more creative tasks, but you ensure that your software development process is easily repeatable, and consistent every release cycle. âWe have a big release every month,â says GitLab Platform Backend Lead, Douwe Maan, âbut we have numerous patch releases. We have tons of scripts in our release tools repository that automate that so that we donât miss little bits and so that itâs identical and reproducible every time.â Automation also means doing things like leveraging continuous integration to run scripts, so a portion of your code review is taken over, offloading work that would otherwise be done manually.
âDocumentation of processes and guidelines is a way of kind of scripting or automating your teamâs behavior,â explains Douwe. Because weâre a distributed team, itâs important that if a question comes up often, that thereâs somewhere people can find what they need without having to wait for team members in other time zones to come online and answer a question â this saves time not just for the person with the question, but for others who are spared answering the same questions over and over. âIf people on my team have a certain question or things that are blocking them repeatedly, that probably means itâs something we should either document better or invent a process around,â says Douwe.
âAs a consequence of that, for example, we have the process around getting merge requests and issues into a patch release when itâs a regression or security issue and so on. At one point we had so few people that we could just say, âHey that needs to go into the patch release,â but of course as the team grows, that doesnât scale anymore, because youâd have 20 people asking one person. To address that we invented the process around labels, where we use labels and milestones very heavily in GitLab to signal to people what has to happen with an issue.â
Having space for comments, questions or suggestions at each stage of the cycle is critical for fostering collaboration and making sure that everyone can follow the latest progress of a project. âFor us, the single source of truth is always the issue. Tools like labels, milestones, assigning to people, these all make sure that the right person knows when itâs their turn to do something, and the handoff happens through issue comments,â explains Douwe. This is another area in which weâve had to become disciplined about documenting the latest update on an issue, because as a distributed team we canât just walk over to a colleagueâs desk to check something. âWe donât have the problem where after two days people will be like, âHmm, what did we decide again?ââ says Douwe. Discussion takes place right in the same environment where weâre working â whether itâs a comment on an issue or a merge request or an inline question on the code itself â so itâs easy for everyone to see the context for it and to refer back to it later.
Having all your software development tools in one environment reduces context-switching, tiresome maintenance when APIs change, and administrative complexity. It also makes the development process smoother, as an integrated tool often offers shortcuts within the UI that would not exist if you were using two separate products.
Douwe explains: âFor a long time GitLab CI used to be a separately deployed web application: the UIs were not integrated in any way and they felt like separate products, as if they were not even made by the same company. At one point we decided to integrate it, and literally within one or two weeks we started seeing new possibilities of interlinking these applications. Weâd think, âHey, wouldnât it be neat if we added a button to the latest status of this page?â which previously is something we never would have thought about, because we really thought of the two as separate products that need to talk over an established channel, instead of just putting a link in everywhere where it would useful to have a link to CI. So with a built-in solution, the integration you get is not just tighter, itâs integrated in ways which other, separate products being developed by siloed development teams would never think of. Weâre not just approaching it as an issue tracker, a code review tool or a CI tool, weâre seeing it as a development environment.â
Using version control for source code is widely accepted as a good idea, but itâs useful for a number of other purposes too. Take documentation, for example: if you use a wiki, there is no concept of a merge request. âThereâs no way of suggesting an improvement without immediately making it,â says Douwe, âso what that means is that in a lot of places that use a wiki, changing it is kind of scary.â This creates a feeling that suggesting updates or improvements is for senior team members only, and discourages participation and collaboration on the documentation. "Using source control here means that even the most junior person whoâs like, âHmm, I spotted a typo here,â or âHey, this wasnât super clear, letâs do it like this,â wonât be hesitant to bring up that suggestion." Having time to write a merge request that clearly outlines the advantages of what they're proposing makes it less intimidating to suggest a change. "It really makes the documentation, similar to the source code, an open source and living document that everyone can contribute to." The same principle applies to things like your CI/CD configuration, tests, and infrastructure code.
Improved collaboration and learning opportunities arenât the only benefits of using version control for things beyond your source code: the ability to roll back in the event of something breaking, and to pinpoint where a bug was introduced are advantages both in that itâs easier to fix something, but also in that team members feel freer to experiment without the fear of causing irreparable damage if something breaks.
By opening up your development platform, other team members can discover, contribute to and learn from other team membersâ work. âIf you hide your CI configuration in an area that can only be accessed by the masters of the project, that means that very few developers on the team and especially very few developers on other teams will ever see that config,â says Douwe. âYou really shouldnât see your code as just a product of your team, you should also see it as a resource for everyone else in the company. If you ask a developer how they learned to code, most of them will not mention university or this book that they read, most of them will mention âcode I read that was written by people who have more experience than me.â So by giving them access to as much code as you can, that will actually make them better coders than if you have them work in a silo.â
If you ask a developer how they learned to code, most of them will not mention university or this book that they read, most of them will mention "code I read that was written by people who have more experience than me."
This isnât just about less experienced developers learning from more experienced developers. Sometimes a fresh perspective from someone who isnât as close to a project can spark solutions that arenât apparent when youâve been deep inside the code for a week. âLike if someone reads code and they ask a question like âHey, whatâs the reasoning behind this? I just found your code and I was wonderingâŠâ it enables a conversation.â Douwe explains. âIt helps us avoid Not Invented Here syndrome.â Someone from another team might have already done work you require on a previous project of theirs â why not use it on your team? âItâs working together to make all of our code better, because if we use a shared library â even if itâs just a company internal one, like innersourcing â if one person improves it or fixes a bug or increases the functionality of that application, thatâs work by one person that will immediately affect all the different teams.â
âWe donât have explicit 20 percent time,â says Douwe, âbut at GitLab, as we are working on improving the same platform we use to do all our work, our job is to make our own job easier. Which means that even if something is not scheduled for this release, if itâs something that you think you can get done in couple hours, and it would save you more than a couple hours in the future, just do it.â
Sometimes going through the formal process for approving time to work on a new feature just isnât necessary. âUnless you have something urgent you should be working on, it really helps to ask developers to feel responsible for the product, and also own the product in the sense that they can also suggest new features, and even spearhead the development of them without going through product management for example,â says Douwe.
Having your work reviewed can feel like a personal judgement on whether youâre good enough or not. When code review is about âThis is wrong, change it to this,â it can be really demotivating. Douwe explains: âA much better way, even if it seems like something is obviously wrong, would be to ask, âWhat do you think about changing to this/Did you consider X, Y, Z/I suggest changing it to this, if you think that makes sense.â The communication there really helps and it also means that people donât feel review is the time where they as person are being told if their work is good enough, if they are good enough, itâs really just talking about the actual code, the implementation, the best way to solve a problem.â Everyone on a team is free to review each otherâs code or to ask for a review, so it becomes about just improving the merge request instead of passing a judgement about that personâs work. âIf review feels like something thatâs just done by the higher-up people and itâs a time when your code is deemed perfect or not, it might feel kind of scary to review someoneâs code, especially if that someone is more experienced than you or has more experience in this area of the application. What really helps with collaboration is having everyone feel free to question each otherâs code or question, âIs this the best way to go about this?â without saying âThis is wrong.ââ
Problem solving is what developers do. So if a customer has a request for some feature that they would find useful, it can be helpful to ask the team to solve the problem the customer is experiencing, rather than presenting them with a spec which might not be the optimal solution. âIn a lot of cases developers are aware of solutions either that already exist within the codebase or that exist in other peopleâs codebases because of innersourcing, or they might even have just read about this cool, open source tool, which a product manager might not be aware of,â says Douwe. âSo allowing developers to be really critical of the proposal and having product managers not be too rigid in their specs also gives you better code and makes for happier developers.â This can also help you to build features that donât just address one particular customerâs problem and fix it the way they would like, but rather work on solutions that can be useful to everyone.
To learn more about what makes development teams successful today, watch our webcast, "Managing the DevOps Culture Shift" on demand.