Development Practices

Why

In order to build awesome tailor-made software solutions, you need great software developers who approach their work as a craftsman, applying best practices to deliver the highest quality.

Prepare for success

  • At Kabisa we explicitly recruit software developers who are passionate craftsmen, and/or who choose for Kabisa because they want to be a craftsman.
  • In the team composition, we make sure that experience with these best practices of craftsmanship are well-represented in the team.
  • Using a standardized setup for code repositories, automated testing, continuous integration and continuous delivery (CI/CD), ensures a jump start for any new project. Having the Managed Services department involved in this, makes sure the transfer to them on the first release to production will go smoothly.
  • The Product Owner must be aware that applying these best practices is not optional.

How

  • Collective Code Ownership - In a Kabisa project, there are no one-man-armies. All team members are allowed to change any part of the code, and everyone is responsible for all the code.
  • Test Driven Development - The implementation of each user story[1] (or part of it), starts with writing one or more tests (a.k.a. “specs”), or the modification of existing tests. These tests then fail, of course. Next, the code is written, and all tests (existing and new) must pass. Then refactor, while keeping all lights on green.
  • Pair programming - Pair programming (a.k.a. pairing) is a way of working that is used within Kabisa teams frequently. Two developers work together at one computer. One of them writes the code, the other one observes, reviews and gives immediate feedback. The two developers will switch roles frequently. Pairing increases both knowledge sharing and quality. Teams are free to choose for pairing when they feel it is useful.
  • Code reviews - All code must be reviewed by a different developer. This unit of work here is usually a pull request (PR). The review involves all aspects of the work: the functionality, the tests, the architectural solution and the code quality.
  • Clean code - Great software developers approach their work as a craftsman, and you can tell by looking at their code. The code will have a clear intention, be easy to reason about and be exemplary for others.
  • Refactoring - Refactoring is about restructuring existing code, without changing its behavior. Continuous refactoring is a responsibility of any Kabisa development team in order to keep the architectural choices up-to-date with the growing functionality. For new development refactoring can be the pre-condition and is seen as risk mitigation.
  • CI/CD - Continuous integration (CI) is the practice of merging all individual developer work to a shared code repository several times per day, in order to expose (and fix) possible integration problems as soon as possible. Continuous delivery (CD) is the practice of automatically building, testing, and releasing the merged codeline to a shared environment several times per day, in order to get the earliest feedback possible on it.

Definition of Done[2]

  • All PRs reviewed
  • All CI-lights on green
  • Awesome software that makes the developers proud and the customers happy.

Real Life Example

Two developers are sitting by one monitor, having both a keyboard wired to the same machine.

One developer is usually the one that starts writing code right away. The other one likes to see the overview of things and usually starts with documentation and schematics. Now they both work on the same problem.

Before they can write any code, they have to explain to each other what they want to achieve, and why they think their particular solution is the best one.

They reason, they discuss, they even start drawing schematics on whiteboards. One writes tests, the other one does implementation. Then they switch roles. While the other types, the other one thinks about next steps, if their plan is solid, if they are not forgetting edgecases and if they stay within scope of the story.

Not only did they made a more future-proof rock-solid solution than they would on their own, they also both have knowledge about the issues and solutions they tried and ended up with.


Notes

  1. User Story - A user story describes a functional goal from the perspective of an end-user. Who wants to do what with the product, and why?
  2. Definition of Done - A shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team.