Software Development Hygiene: Why Do We Brush Our Teeth?

DZone 's Guide to

Software Development Hygiene: Why Do We Brush Our Teeth?

In this article, a developer gives his opinion on why testing processes are so important of the hygiene of code, and when and when not to follow them.

· Security Zone ·
Free Resource

Yes, why do ' you' brush your teeth?

Is it guaranteed that if we brush our teeth twice a day, floss once a day, gargle with an antiseptic, we will never have a toothache or bad breath? And if we did not brush our teeth say, for a week, would we be guaranteed to have a toothache? For a few months, maybe yes, we might, might just have to get some treatment done for a few teeth. So the question, why do we brush our teeth, daily?

And how did we start brushing our teeth? Were we born with a brush in one hand, toothpaste in other and with an utter, inexplicable desire to brush our teeth every morning after waking up from sleep and before going back to bed? Assuming that no one would remember how they themselves were born, all parents at least will agree with me that this is certainly not the case. So the question is, how did we start brushing our teeth daily?

And now the question you might have in your mind: "What's the point?"

Recently, a person on our team raised this question(s): Why do we have unit tests. I have been writing good code, good enough that QAs do not find any critical issues, nor has anything ever severely broken in production because of my changes, why should I write tests? If I could think of all scenarios to unit tests, why do we have dedicated QAs on our team? Why should I pass my code through a static code quality analysis tool? All these processes are slowing us down. I have worked without all these processes in the past and that has worked quite well, why do I need this overhead of processes?

I agree; I hate processes.

Yet we need to appreciate the importance of processes and acknowledge where they are required. Come to think of it, why does a process exist? Can we not work without processes and the overheads thereof? Short answer: no, we cannot. Long answer: we can, given that everyone on the team understands the core reasoning for the existence of the process being bypassed and takes the responsibility of upholding the goal of this process without strict adherence to the process itself.

Well, how did I start brushing my teeth daily? My mother would tell me to; in fact until I was a couple years old, she used to brush my teeth. When I turned three, she taught me how to do it and would ask me to show her how clean my teeth were. She would ask me: "Are they shining when you look in the mirror? I would go and check and say "Yes." When I turned four, she would just remind me to brush, and I think at five I had finally started brushing my teeth daily, without having to show her how clean they were. I do not believe your story would be very different than this. It took years of practice and perseverance for our parents to eventually get us to brush our teeth daily so that finally we could get rid of the 'overhead of process.'

Yes, many processes can be chucked as long as the goal is achieved; but are we, as a team, responsible enough to make sure they are achieved every single time? Let us say we are but are we ready to carry the burden of remembering every single code smell, every single potential bug and being mindful of it while writing code? Is that even humanly possible? If the answer to that question is yes, sure, go ahead and chuck the quality analysis tools, unit tests, pull requests and code reviews; we don't need them. But if the answer is no, wait until it becomes yes!
We can certainly bypass processes and get an apparent speed-up, but chucking a process before we are ready is sure to give us pain in the tooth (and in a few more places)!

code quality, continous integration, devops, secure coding, security, security hygiene, unit testing

Published at DZone with permission of Nikhil Wanpal , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}