Making quality software fast.
Trust one another to do the right thing for the right reason. At your company, you are part of a talented tech team. Ideas cannot go to waste, so share and try them out. Feel confident that you have the power to innovate. Encourage others to grow and become better developers.
That probably means remote-first, but remote-first is by no means a manadate.
Contracts in our codebase are important because it helps us understand our code better. We can test and validate against contracts too which increases quality. Contracts can also be extracted into documentation.
A function can have a contract with static types and/or docblock comments and we can run static analysis against our code to check for correctness. An API can have a contract using the Open Api Spec and we can use that to validate our own APIs. A database schema can have a contract using migrations or duck schema.
Tools:
- Open API Spec 3.0
- DocBlock/Static Types
- Migrations/Schemas
The psychology changes when there is no staging. We might be happy to release code without 100% confidence where we know the environment isn’t production and someone else will do the testing for us. Whereas, with no staging, we will only feel confident when there are automated tests and monitoring in place first. This is to encourage the highest quality code.
Also, a tip I learned is to run code through tests. So instead of testing an API works via the browser, we can test via Guzzle/Axios in a test instead. That’ll give us more confidence.
Tools
- Cloudwatch
- Testing frameworks (Jest, PHP Unit, Feature Files)
If something can wrong, it will. So given the choice, we can either have things go wrong in a small way or a large way. By releasing fast and often, we keep bad deployments small.
An example is with how we deploy. We should strive for continuous deployments. Anyone should be able to deploy their software with a push or merge to master as it’s part of the software development cycle.
It also means consistency. If there’s a better way to do something, that way should be applied everywhere.
Git flow releases code only when we merge into master. Trunk based development releases code behind a flag. It means we are incrementally developing a feature that lives in production but is not available to production until that flag is turned on.
Knowing which version of our product is in production is important, but usually, it requires a developer to manage versions. Automating it means using a standard commit system without the need for manual administration. The CI build will tag for us.
Tools:
- Commitlint and Conventional Change Log
Becoming great software developers is one thing, but becoming domain experts is an entirely separate issue.
With property compliance, we may never be as clued up as lawyers, but feel free to take some time to understand the business. Don’t be afraid to ask questions. It will the development team to come up with solutions autonomously or at least suggest them. And we'll be able to solve problems easier because of a shared understanding.
Simon Wardley highlights four stages of innovation.
Genesis > Custom build > product (service/self-managed) > commodity (utility)
Commodities are better to use if they are fast, simple and won’t cause issues in future eg pricing, scalability. It’ll then free up developer time to focus on innovation unique to the company.
100% code coverage isn’t a great indicator of code quality but will highlight what parts of the code aren’t tested. 80-90% code coverage is a good marker.
Write as many tests as you need to feel confident your code works. Otherwise continuous deployments will be scary.
Using Gherkin feature files to define the business use cases makes for great documentation. It doesn’t replace normal PHPUnit or Jest tests.
“Pioneers, Settlers, Town Planners [Wardley]” by Itamar Goldminz https://medium.com/org-hacking/pioneers-settlers-town-planners-wardley-9dcd3709cde7
“Trunk-based Development vs. Git Flow” by Konrad GADZINOWSKI
https://www.toptal.com/software/trunk-based-development-git-flow
Commitlint and Conventional Changelog