In our young software industry, we are eager to compare with more mature industries. One such analogy is that of the assembly line. Each stop does its job and pushes it to the next in line to do theirs. Unfortunately, this idea went main stream with the waterfall software development methodology. Developers’ job is to write code and it is testers’ job to make sure that the code developers wrote works.
QA team exists to ensure minimum quality necessary to ship the product. But that’s not enough. Quality of a product is one of the main competitive advantages. We can’t skimp on it.
When we care about what we produce, it shows and people take notice. When we don’t care enough, that shows too. A well architected solution, a well written code, a well thought out and implemented user experience- all pay off. The payoff may not be obvious in the short term, but it definitely pays off in the long term by way of customer loyalty, retention and word of mouth advertisement (recommendation). When the users are delighted using our product, they come back for more. That’s a win for all.
We typically measure our (developers’) performance with how fast we churn out code, how fast we could check off the backlog. This is further fueled by the aggressive timelines. Quality isn’t part of the equation. When we bring in quality and robustness as KPIs (Key Performance Indicator), things will shift for better.
Quality KPIs help in multiple ways.
- It communicates the organization’s emphasis on quality.
- It creates a wall/hall of shame effect and we don’t want our names up the leaderboard in red.
These promote a quality conscious culture.
But the onus is on every developer to produce high quality software regardless of what happens at a broader organization level. It is not up to them, it is up to us to produce something that we could proudly put our names on.
“The best code is the one you didn’t have to write.”
Some of us have come to believe that there is no such thing as bug free software. But bug free softwares do exist. You just have to find the bugs before others do, and fix them.
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
– C.A.R. Hoare
Software has become an integrated part of everyday life- from traffic lights, to self-driving cars, to spaceships and everything in between. A simple software bug could be fatal. Producing high quality product and keeping it consistently good is no easy feat. But quality is not about doing what is easy, it is about doing what is right -even when nobody is watching.
Build quality into your everyday work. Move away from a typical developer’s definition of done towards clients expectation of done.1
“The long-term value of software to an organization is in direct proportion to the quality of the codebase.”
– Douglas Crockford
Quality is everybody’s concern. Every line of code you touch can take you towards or away from your quality goals. Be a conscious programmer. Write every software statement intentionally.
An aristocratic lady once asked Sir Henry (of Rolls Royce),
“What would happen if the factory at Derby produced a bad car?”
Sir Henry answered, “Madam. The man on the gate would not let it out of the works”.
More quotes from Sir Henry Royce, as parting thoughts:
“Small things make perfection, but perfection is no small thing.”
“Whatever is rightly done – however humble – is noble”
“The quality will remain long after the price is forgotten”
1 DEFINITION OF DONE
Typical developers’ definition of done:
I just barely got it working with some really clever hacks.
Typical stakeholders definition of done:
The work is complete in every sense- development complete, tested and fine-tuned. The work/product is robust and ready to ship. If this is not the case, then the work is incomplete.