Sustainable pace for closed source teams

During my career as a software engineering consultant I have worked with many growth companies and open source. The key difference between private and open source development comes down to perceived pace. In this post, I will talk about some of the ways pace can wreak havoc on your development team and some ways to alleviate that pressure and increase quality of life of your team and products.

Closed Source (When's the next release?)

Leaders in private companies are always asking when they can expect the next release. They are beholden to stakeholders and under pressure themselves and often have a limited idea what it takes to produce a robust and sustainable software product.

To make matters worse these leaders will extend their lack of knowledge to the hiring process. Inadequate budgeting for core engineering, design, and product management will land them unseasoned team members with a tendency to say "yes" too often. Pressure can be a performance enhancer, but only if the incentives are in the right place. Fear is not one of the desired incentives.

Open source

The goal in open source is to democratically come up with the best solution for a specific problem. Getting results out fast is a lower order goal to be achieved only after you have installed best practices in the community, otherwise things will be out of control and the project will certainly go nowhere.

During my time working on Cloud Foundry, I found a much greater amount of time and attention was being paid to devops, testing, and communicating with the community. These had an effect of increasing quality and freshness of documentation. The goal was to implement the best solution that was vetted by the community. The best way to get community feedback was to get them to use the products and the best way to get them to use the products was to make it as easy as possible to get them up and running.

Closing the Gap (recommendations)

To contrast, private source teams rarely put these goals ahead of the deadline. And documentation and auditing of decisions and discussions is rarely done because these are thought about as lost time or boring. This is tragic, but there are simple ways to remedy this problem.

testing

Nobody wants to be disturbed in their off-hours to debug and fix problems in production. This scenario can be greatly reduced by maintaining important tests and writing more tests. I would be embarrassed if my open source contributions were not tested. But I often find closed source and novice engineers contributing completely untested and unvetted code. This makes me crazy. Often when engineers in these scenarios ask for my help solving some problem, I ask them to write a test for it and it resolves their issues and makes their code cleaner. This process allows you to focus in on the problem and classify it correctly, always resulting in better code.

README

This is often completely overlooked, but it is the first place any collaborator will go. This is going to set the tone for the team, if there is nothing there, you are setting a dangerous precedent. Start with the basics, and evolve it as the team uses it and asks questions. This pays off greatly as shared understanding of the team's methodologies begin to be discussed and documented. You must have a root level README but don't be opposed to adding more READMEs in other relevant sub-directories.

reduce the cost of on-boarding

To take your README to the next level, you will want to provide single-line commands that anyone who just cloned the repo can run to get their dev server, tests, deployments working in less than 10 mins.

I had a retrospective recently where a new team member said getting up and running was under 5 minutes and he had never experienced that before. That same conversation had the designer and PM chiming in with their experiences and endorsements and it gave me as much pride as any of the production code I had committed.

To accomplish this level of simplicity, you will need to maintain and evolve your development operations with tools like VMs, containers, and CI/CD. I typically use docker and docker-compose to achieve this level of simplicity. There are a number of bonuses including enforcing many 12 factor app requirements and getting your configuration under version control.

project wiki

System architecture should be maintained in a project wiki. Train your team to look there first when they need to figure out testing strategies, system architecture and reasoning, integrations and everything that does not seem essentially relevant in the READMEs.

backlog or issue tracker

You probably already deal with a backlog. But to take it to the next level, think about your team's backlog as a seam between the developers and the product team and stakeholders. It must contain a source of truth, track discussions and link to necessary information. If these practices are maintained your team will be able to level up to a realm where team efficiency metrics begin to be actionable and conversations with product and stakeholders becomes less mundane.

Whenever your stakeholders ask "when will feature x be ready?" you should immediately ask them "when does the backlog say it will be ready?". This will be effective only if you have a good practice of velocity tracking of your team through pointing complexity of stories. This is core to project management tools like Pivotal Tracker.

If you are diligent in your efforts, your stakeholder will eventually get the point. This is a huge win and it will encourage them to focus correctly on prioritizing the features to hit deadlines and reduce feature creep. This also allows you to cap the number of hours you work should you choose. All without difficult or potentially damaging conversations about impending deadlines.

Ultimately, as a developer, you should never have to worry about a deadline, your PM should be handling that. In the case that your stakeholder is your PM. You must push for the backlog as the source of truth and the idea of rushing to complete a set of features for a convoluted or completely arbitrary release is not sustainable.

Conclusion

Sustainable pace is a key difference between open and closed source projects. Open source gets this by default because stakeholders are all the collaborators in a democratic forum where the best ideas are king and release dates are secondary. Closed source projects usually have a limited number of stakeholders whose main goal is releasing features. For the closed source engineer, always look for ways to capture methodology and objective information in ways that are easily viewable by your team and discuss with your peers on how best to use that information.