When it comes to software development as a business (at least in the U.S.), the landscape is often rather shitty. People are in a big damn hurry to make their money, nobody is quite sure how thing <x> should work or does work, and finger pointing is significantly more common than understanding problems and finding solutions. There is always too much to do and feature <y> needed to be out the door yesterday. The problems are numerous (much more than what I mentioned) and the users end up paying to play the role of beta testers. Ain’t late stage capitalism just the best?
What people don’t seem to understand or accept is that creating software is an inherently risky beast. Sure, you can slap together some application that does <x>, <y>, and <z>. But what happens when <x> needs to be changed? What happens when <a> is added? Now <z> needs to be removed because we’re replacing it with a brand new <z>. How do these changes affect the rest of your application? Are these changes going to go smoothly or turn your application into a bug-infested wreck? Chances are, you don’t have answers to any of these types questions. You write your code and hope that things work out. Anyways, isn’t that what the testers are for (assuming you actually have a dedicated testing department)?
What frustrates me to no end is that it doesn’t have to be this way. You can have code that is reliable, deterministic, scalable, reusable, etc. You don’t have to code and hope for the best. Adding to/changing code does not have to be a scary endeavor, and you can have users that are actually happy to use your software. And no, I’m not trying to sell you a bottle of snake oil. It takes work, commitment, and most importantly, you have to give a shit. People depend on your work, so give them something that solves problems without causing more problems.
If you want a reliable and predictable codebase, the solution is surprisingly simple; you need to prove that your code works. Stop debating it and accept it. There is no way to honestly claim thing <x> works and does <a>, <b>, and <c>, unless you can prove that it does. So, at a bare minimum, you need to be writing unit tests. And I don’t mean writing a few unit tests and hoping to one day have 100% code coverage. 100% code coverage is a baseline; it is not an end goal (since ‘code coverage’ is generally assumed to be statement coverage). If you don’t understand why I’m making that claim, go then check out Wikipedia’s description of code coverage. 100% statement coverage does not necessarily mean that the unit testing is done and all is good.
If any of the above is rubbing you the wrong way, then you might be in the wrong line of work. The world doesn’t need more glitchy code; there’s plenty of that to go around. So stop adding to that problem and start proving that your work is indeed the gem you want it to be.
Categories: dev notes
Outstanding Underground 
Leave a Reply