|
One thing we software developers are notoriously bad at is reporting progress. When someone asks how far we are with a certain task or project, our response is usually "it's about 80% done".
Every task seems to be about 80% done for about 80% of the task's lifetime. The other 20% of the task's lifetime, it hasn't really started yet. And at the end, the progress jumps from 80% directly to 100% completion without a step in between.
I can see you smiling while reading this! How is it that we software developers can identify so well with this situation?
A big part of the reason is that we often don't consider quality as part of the "real work". We're creating some code to solve a problem (80% progress) and then we have to test it (the other 20% of progress that take 80% of the time). And with "testing" I don't mean writing unit tests, but:
- testing our changes in the live system,
- presenting our changes to interested parties to collect their feedback,
- implementing change requests,
- discussing potential code improvements with the team,
- ...
But we usually focus on the coding part of the job first, and only once this is "done", we think about the quality of our work (apart from unit tests, perhaps, because they are thankfully considered part of the coding job, nowadays).
What if we think about quality earlier? Next time you start on a new feature, think about the things you need to do make this feature really good. What input will you need from others to get feedback on the quality? What would a user think about this feature? What metrics should we measure to learn if the feature will be used?
Answering questions like these before writing a single line of code will help us to:
- get done faster because we now have an idea of things that might have to be discussed with a designer / product manager or other stakeholder and we can schedule these discussions right away
- give a more accurate progress estimate because we now have a list of things that we might have to do to assure quality
- to build better quality because quality is no longer an afterthought but a core feature of our work
On a team and company scale, this is often called "left-shifting" quality, because we're shifting quality from the end of the timeline to the left by thinking about it earlier. This is a core tenet of the Agile and DevOps culture where we want to think about quality continuously instead of just at the end of a project.
It's proven that left-shifting quality makes companies perform better (see the "Accelerate" book). Left-shifting quality in our own work will make us perform better, as well.
|
