I recently shared my thoughts on the foundational elements of a good software engineering team which I shared with my team. Naturally this does not imply a good fit for all teams. But my hope by sharing this with the rest of the world is that it might trigger discussion and debate within your team and organisation. Note that these pillars are sometimes referred to as engineering values.
These 6 pillars are the foundation on which we measure the quality of our engineering. These 6 pillars provide the focus required to help guide the engineering team to provide a better product and service for our users.
Pillar 1: Culture of openness and ongoing learning
Within any organisation, trust and cooperation between engineering teams is paramount. Otherwise, quality typically becomes reactive and subpar. Openness in communication is a virtue that promotes collaboration and continuous improvement between teams. No less important: ongoing training and learning. Raising developers’ fundamental engineering IQ level pays enormous dividends.
Pillar 2: Observe/Monitor everything
In a world with perfect developers, perfect testing practices, and perfect infrastructure, you would never get any issues in production. In the real world, that’s not going to be the case.
No matter how good you are, you’re going to run into problems in production. Be it unhandled exceptions, performance issues, user experience bugs, or infrastructure problems, the only thing worse than them making it to production is not knowing that they’re there.
Monitoring of your applications is essential. If there are any issues in production, you need to know that they’re happening before your users do, and you need to know why. If you’re not monitoring, you’re flying blind.
Pillar 3: Focus on the end user
To deliver software that benefits users, every team member needs to keep the user front of mind.
There are many tactics to keep everyone focused on the customer, such as:
- Immerse everyone in customer environments; observe people using the products that the team is building.
- Put every team member on the on-call roster at different times, so everyone has an idea of what happens and who is affected when things go wrong. Atlassian famously put all new engineering recruits on support for the first 2 weeks on the job.
- Have all team members respond to customer feedback.
- Get team members to use the product or feature they build on a regular basis.
These tasks are often given to a small subset of the team (who usually don’t make the key decisions about the product). Involving everyone brings the end user to the centre of everyone’s mind, and people are more likely to make decisions that deliver value to the end user.
Pillar 4: Automate everything
Humans are excellent at providing creative solutions to problems, but we are also excellent at making mistakes. When people are involved in the release of a piece of software, you’re greatly increasing your chance of something going wrong.
If you want to be successful in delivering any software, you need to invest in automating any repeatable manual task. The benefits are too good to pass up:
- Eliminate the chance of anyone making mistakes.
- Reduce the time taken to complete the tasks.
- Enable more frequent deployment of features to users.
- Boost morale by keeping people on new, creative tasks rather than repeating things they’ve already done.
- Free up your infrastructure experts to make improvements to deployment processes, security, and quality of the environment.
Automation takes a significant time investment, and you’re always going to be finding more to do, but with every task you automate things become faster and more consistent. It’s a never-ending journey, you just have to start somewhere.
Pillar 5: Collaborative culture
DevOps is founded on the idea of development and operations teams working together and helping each other out. But it goes beyond just those two teams, everyone involved in software delivery need to be talking, working together, and have a strong understanding of each other’s motives. If tensions and distrust exist among team members, the blame games start, and product quality suffers.
Team leaders need to be responsible for ensuring that teams are getting along and communicating, this could be through frequent team building events, daily status meetings, team-wide wikis, or even moving desks around so people can sit together.
But take note: DevOps is not about making everyone responsible for everything – because then nobody is responsible for anything. Instead, the idea is to create a culture that, when something goes wrong it doesn’t matter who caused it, it’s everyone’s problem.
Pillar 6: Build a culture of security
The secret, however, lies in the approach to threat modeling. The activity is to be transformed into a process of deriving security test cases (which it ought to be) rather than a disjoint effort of unearthing a “type” of security flaw. This would enable teams to actually adopt threat modeling as a part of the product development process. Another point of integration could be in tagging user stories and associated abuser stories right within the project management/functional specification management platform, such as Confluence or Google Projects.
Threat modeling is, and should be, one of the first activities that product teams come together to incorporate application security, as soon as the requirements have been made available. This activity happens during the design phase in conjunction with design/architecture review. Being a team activity, this would help in collectively visualizing the various threats an application stands to face, if and when released to market, and also how they can be mitigated, transferred, ignored, or accepted, depending on business priorities. Ideally, with every sprint, product teams should come together to review their features/user stories and come up with abuser stories that can be considered as non-functional requirements with clearly stated acceptance criteria.
