If this blog post was helpful to you, please consider donating to keep this blog alive, thank you!
To me, writing software is more than a job or a hobby. I take great pride in my work, as it is not just a reflection of myself, but also an example for those that hope to learn and understand from me. I was given the opportunity to speak at the MacTech Conference, and helped teach one of the openjailbreak classes on reverse engineering. Reverse engineering is a significant part of my development work on OS X, and what it has taught me more than anything is the importance of creating a quality product.
I am an iOS developer, and have worked at a number of places where the mentality appeared to be "do the best work possible". Until we started to knock into our deadline, where that attitude of delivering a quality product quickly disappears and turns into the infamous "fuck it, ship it". To most developers, when you hit crunch time it might be relatively ok to let a number of quick or ugly code hacks slip through into the release build. But do most of us go back afterwards and remove these and fix the flaws? Or are we quick to dive into the next new feature to implement?
Code rot, or the state of code over time as more and more hacks are added to it. I work on a project with over a half a million lines of C code. As far as code goes, this is one of the more elegant projects I have ever seen. The more I look at it the more I understand of the design patterns used. As with any source code, it has some pretty horrible hacks in it. Namely, it doesn't use inline statements anywhere, it uses #define macros in substitute for static and inline functions. Functional? Yes. Maintainable? No. I had the task of porting all of these over to compile properly with llvm (originally using gcc) and preserve the original functionally of these macro functions for not only OS X, but also Mac OS 9 and Win32 platforms. This was an exercise in much testing to ensure that this seemingly simple code didn't have any complexities or happen-stance hacks in it that made it work as "intended".
Why should you care about code rot in your own projects? Well beyond that you should take the utmost pride in your work, it is also a reflection on you by anyone that will see it. You don't want your name cursed up and down the halls of your place of employment in the years to come because your name resides in a header file of a bunch of code that has to be rewritten. Whatever the circumstance of it, hacks are horrible and extremely obvious in not only source code, but also reverse engineered code. In Apple's MobileDevice framework, there is not one, but FOUR ways to send data over the socket used with the iOS device. This is redundant code, and it will cause more complications in development than it can help. As a result of the need to be stable and compatible, this code cannot be removed at any point. We are stuck with this code for the next 5-10 years.
We all have examples of this same exact behavior in our own code. Where we said "I'll fix that after I submit this to the store", then never got to it. Sometimes it is unavoidable, but at the end of the day it will happen in some way. Eventually we do reach a point of no return, where we either throw our hands up in disgust at what our once good code has become or we perform a Refactor. The type of refactoring that not only involves rewriting the code, but also the code logic in an attempt to remove all traces of patchwork code fixes. This is a healthy thing to do, even on already good code. It means you re-evaluate and re-assess your thought process with the code, and build it anew with knowing all the edge-cases you were not aware of when you began.
Crafting software isn't a skill, it is a passion. It is when you pour yourself into your creation in the hopes that can live up to your dream of what it can do. Sometimes we have to fight when we let these things go. Be it a public release or letting it pass onto another developer, we can only do so much when creating software. Once it is let go, everything we have done is going to be the example for any future work on it. Everything from syntax styling to code elegance will be a lesson that is going to be consumed by anyone that looks at that code. From this we grow as developers, we see our mistakes as well as our triumphs. The best of us have no shame in flaunting where we erred so other might learn.
As a developer, I find the most important part of my profession is pride in the work you do. Beyond any skill with APIs and languages X, Y and Z; being able to create the most quality and polished product can set you so far ahead of the pack there is no comparison. If there is one thing I wish to pass onto others in my field, it is pride in your own craft.