Project Lifecycle in Zerocracy

In addition to being a hands-on programmer, I’m also co-founder and CTO of Zerocracy, a custom software development company. I play the role of a technical and management leader in all projects we work with.

I wrote this article for those who’re interested in hiring me and/or my team. This article will demonstrate what happens from day one until the end of the project, when you choose to work with us.

You will see below that our methods of software development seriously differ from what many other teams are using. I personally pay a lot of attention to quality of code and quality of the internal processes that connect our team.

There are four phases in every project I work with in Zerocracy:

Thinking. Here we’re trying to understand: What is the problem that the product is going to solve? We’re also investigating the product’s boundaries—who will work with the software (actors) and how will they work with it (user stories). Deliverables: specification. Duration: from 2 days up to 3 weeks. Participants: product owner, analyst(s), architect, project manager.
Building. Here the software architect is creating a proof-of-concept (aka an MVP or prototype or a skeleton). It is a one-man job that is done almost without any interaction with anyone else. The architect builds the product according to the specification in a very limited time frame. The result will have multiple bugs and open ends, but it will implement the main user story. The architect also configures continuous integration and delivery pipelines. Deliverables: working software. Duration: 2-5 days. Participants: architect.
Fixing. At this phase we are adding all the meat to the skeleton. This phase takes most of the time and budget and involves many participants. In some projects we invite up to 50 people to work, at the same time. Since we treat all inconsistencies as bugs, this phase is mostly about finding, reporting and fixing bugs, in order to stabilize the product and get it ready for market launch. We increment and release the software multiple times a day, preferably to its user champions. Deliverables: bug fixes via pull requests. Duration: from weeks to months. Participants: programmer(s), designer(s), tester(s), code reviewer(s), architect, project manager.
Using. At this final phase we are launching the product to its end-users, and collecting their feedback (both positive and negative). Everything they are reporting back to us is being registered as a bug. Then, we categorize the bugs and fix them. This phase may take years, but it never involves active implementation of new features. Deliverables: bug fixes via pull requests. Duration: months. Participants: programmer(s), code reviewer(s), project manager.

The biggest (i.e., longest and most expensive) phase is, of course, Fixing. It usually takes the majority of time (over 70%). However, the most important and risky phase is the first one—Thinking. A mistake made during Thinking will cost much more than a mistake made later.

Thinking

Thinking is the first and the most important phase.

First, we give a name to the project and create a GitHub repository. We try to keep all our projects (both open source and commercial) in GitHub. Mostly because the platform is very popular, very powerful, and really cheap ($7/mo for a set of 5 private projects). We also keep all communication in the GitHub issue tracker.

Then, we create a simple half-page SRS document (Software Requirements Specification). Usually this is done right inside the source code, but sometimes in the GitHub README.md file. What’s important is that the document should be under version control. We will modify it during the course of the project, very intensively. The README.md should briefly identify main “actors” of the system and define the product scope.

Even though it is only half a page, the creation of this initial SRS document is the most important and the most expensive task in the entire project. We pay a lot of attention to this step. Usually this document is written by one of our system analysts in direct communication with the project sponsor. We can’t afford a mistake at this step.

Then, we invite a few new system analysts to the project. These guys are responsible for turning our initial README into a more complete and detailed specification. They start by asking questions, submitting them one by one as GitHub issues. Every question is addressed to the product owner. Using his/her answers, system analysts modify the README document. Sometimes we’re using Requs.

At the end of the Thinking phase we estimate the size of the project, in Hits of Code. Using this HoC metric, we can roughly estimate a budget.

Building

This is a one-man job for an architect. Every project we work on has an architect who is personally responsible for the quality and technical decisions. We have a few brilliant engineers for this role.

The Building phase is rather straight forward. The architect has to implement the solution according to the README, in a few working days. No matter how big the idea and how massive the planning development, the architect still has to create (build from scratch!) the product in, say, three days.

Besides building the software itself, the architect has to configure all basic DevOps processes, including: 1) automated testing and quality control, 2) deploying and releasing pipelines, 3) repository of artifacts, 4) continuous integration service, etc.

The result of this phase is a working software package, deployable to its destination and available for testers. Technical quality requirements are also defined at this phase.

More about the Building phase here: Nine Steps to Start a Software Project

Fixing

Now it’s time to build a distributed team of programmers. First, we invite those who’ve worked on other projects and have already have proven their quality. Very often we invite new people, finding them through Stack Overflow, GitHub, Upwork, and other sources. An average team size of an average project is 15-25 programmers.

At this phase, we understand any inconsistency as a bug. If something is not clear in the documentation, or if something can be refactored for better readability, or if a function can be improved for higher performance—it is a bug to us. And bugs are welcome in our projects. We encourage everybody to report as many bugs as possible. This is how we achieve high quality.

That is why the phase is called Fixing, after all. We are reporting bugs and fixing them. Hundreds of bugs. Sometimes thousands. The product grows in front of our very eyes, because after every bug fix we re-deploy the entire product to the production platform.

Every bug is reported, classified, discussed, and fixed in its own GitHub ticket and its own Git branch. We never allow anyone to just commit to the master branch—all changes must pass through our quality controls and be merged into master by rultor.com, our merging bot.

Also important to mention is that all communications with the product owner and between programmers happen only through GitHub issues. We never use any chats, Skype, emails or conferencing software. We communicate only through tickets and comments in GitHub.

Using

This is the final phase and it can take quite a long time. By now, the product is ready and is launched to the market. But we still receive bug reports and feature request from the product owner, and we still fix them through the same process flow as in the Fixing phase.

We try to keep this phase as quiet as possible, in terms of the amount of bugs reported and fixed. Thanks to our intensive and pro-active bug finding and fixing in the previous phase, we usually have very few problems at the Using phase.

And big feature requests? At this phase, we usually try to convert them into new projects and develop them separately, starting again from Thinking.

BTW, the illustrations you see above are made by Bárbara Lopes.