This post will try and outline our (Westfield Labs Engineering) general philosophy toward product development. The focus on Ownership and Quality is paramount – all other items flow from this. The following are merely guidelines and principles: you may feel the need to change or bend these rules, that’s fine, that’s part of ownership and responsibility.
You will often hear people ask ‘who owns this?’. While to the outside world a team or department may own something, internally each component needs to have a single individual ultimately responsible for it. This doesn’t mean you have dictatorial control or don’t need to listen to others opinions but it means that person is ultimately responsible for the quality, maintainability and stability of a component.
If you own a component it doesn’t mean you have to check every line of code that’s merged but you have to be satisfied that you trust the person merging code. If their work is not of a sufficient standard you are ultimately responsible for it.
If you ‘own’ a component but feel you don’t have sufficient time and resources available to perform this task effectively, you must raise that issue – at Stand Up or at Retro or with your manager or Team Lead.
Component owners should be known.
If you have been given a problem to solve, follow it through. You own the problem, not just code. If you are blocked by someone else confirm with them explicitly that they now own the problem and let necessary stakeholders know.
Nothing is considered ‘done’ until it is in production.
Work in small increments delivered through to production.
DO NOT BATCH. See above, if there is unreleased code in Master speak to the owner of that code, try and get that pushed through before you merge.
Spike if uncertain.
Work on one component at a time – only release code that has all dependencies already working in production.
Upon release, monitor production logs to ensure Release was successful and no regressions occurred.
Know the business
Understand and question requirements. If something doesn’t seem right, query it. If you know a better way, suggest it.
Remember you are focused on solving problems, not performing tasks.
Know what value you are creating.
Our philosophy is to continuously improve and refine our products but also the process: scoping, solving, delivering.
Call a retro if you think we need one.
All retro issues must have an action. If it can’t be solved within the team, then the action must be on the Scrum Master or Team Lead to raise the issue outside the team.
Sometimes we have to accept there are constraints or obstacles that cannot be removed immediately. Plan to route around these obstacles in the short-term while working on removing them over the longer-term.
Everyone in the team is responsible for quality.
Testing is used to add value, you can over-test just like you can under-test. It’s your judgment call.
Engineers share responsibility for quality along with the rest of the team. Engineers are responsible for the functional testing of their own code.
Ask for help if necessary but ultimately you, as an engineer, are responsible for the functional quality and stability of that code.
Automated testing is still expensive – to write, to maintain and to run. Consider this when you write tests.
Consider impact to business when writing tests – obviously we require a greater level of test automation for a Credit Card payment form than we do for a static brochure page.
Let the tests guide your implementation. If you cannot test logic at the unit or service level you probably need to refactor.