QR code

Stop Chatting, Start Coding

  • comments



The first principle of eXtremely Distributed Software Development (XDSD) states that "everyone gets paid for verified deliverables." This literally means that, in order to get paid, every programmer has to write the code, commit it to the repository, pass a code review and make sure the code is merged into the destination branch. Only then, is his result appreciated and paid for.

For most of my clients this already sounds extreme. They are used to a traditional scheme of paying per hour or per month. They immediately realize the benefits of XDSD, though, because for them this approach means that project funds are not wasted on activities that don't produce results.

But that's not all.

Barton Fink (1991) by Joel Coen
Barton Fink (1991) by Joel Coen

This principle also means that nobody is paid for anything except tasks explicitly assigned to him/her. Thus, when a programmer has a question about current design, specification, configuration, etc.—nobody will be interested in answering it. Why not? Because there is no payment attached to this. Answering questions in Skype, Slack, or HipChat, or by email is something that is not appreciated in XDSD in any way. The project simply doesn't pay for this activity. That's why none of our programmers do this.

More about this philosophy here: It's Not a School!

We don't use any (I mean it!) informal communication channels in XDSD projects. We don't do meetings or conference calls. We never discuss any technical issues on Skype or by phone.

So, how do we resolve problems and share information?

We use task tracking systems for that. When a developer has a question, he submits it as a new "ticket." The project manager then picks it up and assigns it to another developer, who is able to answer it. Then, the answer goes back through the tracking system or directly into the source code.

The "question ticket" gets closed when its author is satisfied with the answer. When the ticket is closed, those who answered it get paid.

Using this model, we significantly improve project communications, by making them clean and transparent. We also save a lot of project funds, since every hour spent by a team member is traceable to the line of code he produced.

You can see how this happens in action, for example, in this ticket (the project is open source; that's why all communications are open): jcabi/jcabi-github#731. One Java developer is having a problem with his Git repository. Apparently he did something wrong and couldn't solve the problem by himself. He asked for help by submitting a new bug to the project. He was paid for the bug report. Then, another team member was assigned to help him. He did, through a number of suggestions and instructions. In the end, the problem was solved, and he was also paid for the solution. In total, the project spent 45 minutes, and the problem was solved.

  • XDSD: management without meetings; 13 February 2016; 3629 views; 59 likes
  • Meetings-free Programming; 1 April 2016; 228 views; 7 likes
  • Meetings Help Us and Kill Our Projects; 6 April 2016; 354 views; 9 likes
  • Meetings Or Discipline; 26 April 2016; 574 views; 8 likes
  • Blame the Project; 16 April 2016; 487 views; 9 likes
  • Talk "MEETING-FREE SOFTWARE DEVELOPMENT, IN DISTRIBUTED TEAMS" by Yegor Bugayenko; 29 April 2016; 276 views; 11 likes
sixnines availability badge