Interview questions: What practices in software teams lead to better quality products?

Background: I’ve been asked in a few applications for new roles to do written interviews. I thought it might be worth while to release some of my answers as posts as it was fun to reflect a bit on these things.

One question was what practices I think help software teams build better quality products. And this is what I wrote:

There are a few things that helped a lot making my current team deliver quality products. The first parts are processes and technical setup.

• A development environment that involves linting, error and issue reporting while you develop using static code analysis in the editor. Any bug that isn’t written means less work for the QA department and less waiting for results.
• A version control system workflow that involves checks like tests, documentation, peer review, and automated security and data analysis.
• A code standard that is automatically applied on commit to the version control system. People can write any way they want to, but code coming from the repository needs to be in a predictable format.
• End-to-end tests. Code without any tests will not be allowed in the repository.

The other part is the team/human factors that ensure that we all follow best practices and learn from another.

• Peer reviews / team reviews of code with detection of best practices. Once these practices are discovered, they should be documented in and shared amongst the team.
• Presentations to the group of new and exciting tools and processes. I mentored and coached my team on those which also helped them with their communication in their own reviews.
• Learning days that allow developers to try something new or share information with others.
• Documentation days to catch up on missing write-ups.
• Bug bashes – we take a list of long-standing bugs and dedicate a day to fixing those instead of continuously working around them.
• Leaving ample time at the end of the daily stand-up for questions and answers when people are stuck.
• End of sprint reviews and sharing of learnings.
• Including engineers in design reviews and user testing. The former to ensure we can build what the UX team dreams of and the latter to give engineers a feeling of who we work for and that what is obvious to a technical person may not be understandable to others at all.

Another concept I’ve seen work extremely well in two companies so far is a developer rotation. Products get cut up into “work pods” and developers get assigned as needed to the pod depending on how soon that product needs to be finished or new features released. Engineers get assigned to pods on a rotation basis, which means that everybody in the team knows about the different work going on.

This means:

• People can get sick or take time off without the product being stalled.
• If people leave the company, they don’t take all their knowledge with them.
• Documentation and handover are a must as you are not the only person working on the product.
• Engineers learn from each other how their counterpart worked on the last iteration of the product.

Photo by Annie Spratt on Unsplash