A minimum bar for professional software engineering practices

I was reading a discussion on social media recently where one commentator stated “If someone isn’t testing they aren’t a professional”. As a strong proponent of automated testing, I have a lot of sympathy for this outlook.

Initially I thought that questioning someone’s professionalism was a bit too strong – I know a few great developers who have shipped successful solo products with little or no automated tests. But I fully agree with this statement if I define “professional” in the context of a team project that has at least two developers working on it and which is intended to have real users instead of being just a pet learning project for the developers.

This got me thinking about other software engineering practices which fall into the must-have list for any such professional software development team context. The following list is my minimum bar of practices that I will simply not compromise on for any such project I’m involved in:

• Using a version control system. I shouldn’t have to state this in 2022.
• Documentation for developers on how to set up their dev environment
• Automated tests which at the very least cover the most mission critical features of the system. You need regression checks to make sure nothing gets broken and can’t afford to do this manually every release.
• Continuous Integration pipeline which runs these tests along with other checks (linting, etc) when code is pushed to repo. “Works on my machine” is not good enough in a team environment.
• Fully automated deployment script which builds from source and deploys to a target environment. Manual deployments are error-prone and greatly decrease your release cadence.
• Define all cloud resources with Infrastructure-as-Code (for AWS serverless apps). This is related to the previous item, and since the deployment frameworks make this much easier to do than with server-hosted applications, not doing it is a red flag.

I haven’t included many other ideal practices that I strongly advocate for in this list (e.g. trunk-based development, ungated Continuous Deployment), as these can be more context-specific requiring the occasional “it depends”. This is just the “you must be at least this tall to ride” list.

If your team isn’t yet practising all of these fundamentals but instead you’re spending time thinking about how to integrate some new framework, service or architectural pattern into your system, maybe it’s time to re-consider your priorities.

What would be your minimum bar of software engineering practices for teams you work on? Have I missed anything off my list, or do you disagree with any of my inclusions? Hit reply and let me know what you think.

Related reading:

• Moving from 1 to 2 developers on an AWS serverless project

— Paul