Starting with this post I am moving to a new line of blogging which starts to talk about how to ensure software quality with imbedded or combined test/dev engineering. I am convinced that this is the best way to engineer software and more and more companies/development houses including Microsoft are starting to agree with me.
I think the initial set of challenges for a team moving to this paradigm is to change the value given to writing code right the first time. Most development orgs with a dedicated QA team value code velocity over code quality since there is a set of engineers waiting and ready to validate the features of that team as the code rolls off their finger tips. Sometimes this means having lower code velocity in order to get higher code quality. Developers in these orgs need help in finding and incorporating techniques to harden their code and build in the tests and telemetry to find problems early and see themselves as the last gap before their features hit the customer.
This new muscle is trained with the following 3 principles or initiatives:
- Dev management needs to support code/feature/component quality out of the gate and educate their teams that this is the new expectation. Engineers will focus and execute on the results their management values.
- Leads who were previously in test need to transition themselves into an integrated dev lead mentoring developers with the ways of customer ownership and empathy. They also need to be the voice of reason having impact and influencing on the team in well founded test practices that will equate to wins for the team.
- This can also come from Senior or Principal Developers who in more instances than not already harden their code through good standards and high pre-checkin accountability. Most of these devs I talk to say that they definitely write buggy code sometimes but they rarely/never check it in (meaning their own tests in the code find these issues so they can fix them before submitting).
- Finally, the new test specialists on the team who have transitioned to combined engineering can essentially act as Spackle for Quality Engineering before the rest of the incumbent devs come up to speed.
My expectation is that over time those new devs who are worth their weight as combined engineers (previously very technical testers) will start to float to the top of the rewards pool if they can learn to leverage that tester gene they are imbued with.
I am expecting this transition to take time as devs come up to speed on code/feature quality and test specialists learn their place in this new world not losing that special perspective they bring as protectors of the customer; all the while we have to work on shipping some amazing experiences. There will be trade-offs and longer term investments but I am sold that it will work (it is already working for our team).
Over the coming months I hope to bring specifics on learning’s we have as we navigate this new world – What goes well, what is not working, and new insights we develop as we execute a combined engineering team.
Possible future topics will include:
- Engineering processes (Agile, Kanban, Scrumerfall (what most teams at Microsoft really do that say they are doing SCRUM), and other iterative methodologies that support combined engineering paradigms.
- How to work in Vertical Initiatives such as Performance, Stress, Globalization, Localization, Policy, and Security in this new world.