3 Problems with Quality Code
I have been thinking a lot about software quality lately. I’m passionate about building software that does what it is supposed to do, is extensible, is readable by future people (including me), and leaves me with a sense of achievement (a bit selfish, I know). While I love building great software, I freely admit that creating quality software can be a pain. Below are the three main things that suck about writing robust code.
Good code takes time
Creating working software can be shockingly quick. Want to build software to detect some bad words in English text? It is easy to have something working in a few hours or less that accomplishes this. Voila, we have a naughty word detector. It won’t be pretty, and it will, probably, be missing a few things, but you have just created a small logic machine that does something relatively miraculous.
Heck, you could probably build one for each language you need at a day apiece, and you would have something that would meet most or all of your needs. Just string the programs together. It works for any language you need.
Notice a bug? Change a bit of code. Have multiple languages? Change it in multiple places. Sure this can get a bit out of hand as you keep adding languages or features, but this a problem for future you (or ideally future someone else.)
Good code takes experience
The first time you do anything, you do it poorly. Software is no different. It is hard to know what quality looks like when you start. And as everyone knows, anyone can write code once. It takes experience to create maintainable software.
Unfortunately, experienced software developers are expensive. As anyone with kids knows, inexperienced workers are cheaper and still get work done. Sure, it’s not pretty (maybe even unpleasant to look at), but experience is expensive.
Good code takes testing
Testing is unpleasant. It takes time and produces no direct customer value. Testing is the exercise of the programming world. Of course, it is important, but the results take time and energy that could be spent on other things today. Even worse, testing is not easy. Running the application a few times is easy.
Thinking of how to automate testing to ensure quality as the application changes is hard. Keeping the tests up to date as the application changes is tedious. User’s testing your software is free (for you.) Testing isn’t something your users see. They see features, and automated tests are not features.
Why is quality code hard?
Building quality into software is hard because software takes time and experience to do well. These are costs that directly affect projects and can end up as trade-offs in the end product. In this way, it is not much different than building something physical: time, materials, and expertise affect the cost and final product.
Even with the trade-offs there is one aspect of building quality software that is the most difficult to justify. It is invisible work. No end-user or product manager sees a great test suite or extensible code — all they see are the features. A great looking application that does what they need but is built poorly still “feels” like a great application. It is our job as software professionals to help others understand why quality matters.
Originally published at http://blog.codeminimus.com.