Breaking Out of the Rut of Habit Driven Development

Recently the Atlantic published an article called The Coming Software Apocalypse with the subtitle “A small group of programmers wants to change how we code — before catastrophe strikes.” Wow that sounds scary!

Most headlines like that are full of crap, so I totally ignored it. However, others in the software profession took it more seriously and started a discussion about how to improve the practice of software development. That is definitely a discussion I think we should have. I always strive for continuous improvement, but also, software, in general, is a young industry that is not done evolving.

I like to boil down the “better programming discipline” argument to a new process I call Habit Driven Development. HDD says if we just practice all the right habits we’ll produce great software. One hundred percent test coverage, check! Strict typing, check! Agile development processes, check! Code style and linting enforced, check! Proper logging techniques, check! If we just follow all that and more, we will get great software.

While a lot of these techniques are great, this leads to making software development a religion where you have to follow the right rituals to magically get bug-free code. Real life is a lot more complex and nuanced than this.

Now don’t take me the wrong way, Habit Driven Development can be very useful. In very complex situations when things go wrong and we don’t understand the problem, our habits are our first defense in tackling the unknown.

I like to think of it as good habits and programming discipline increase our luck of building great software. But at the end of the of the day, its just that, luck. HDD doesn’t guarantee anything.

Gaining the right habits and disciplines is definitely where you should start your learning, but if you never grow past them, you’ll be a beginner software developer your whole life.

And, what's more, if we make these disciplines to be so lofty, we almost guarantee that we will be headed to a software apocalypse. The rules and disciplines of the trade will become so highly revered that many will follow them blindly, which most certainly will cause disaster.

Lastly, in my experience, those who most often push high standards are the greatest offenders of those standards. Humans are fallible and therefore, even if you have high standards, they will often fail. So, we need software systems that are robust and have architectures that will handle failures gracefully. Trying to write perfect software by chasing after better disciplines or better tools will most certainly cause the software apocalypse.

Paul Bailey is a Full Stack Immersive instructor in our Houston campus. Interested in how you can jump-start your career as a new developer? Download our course packet for more information about our programs!