If you ask any software developer whether or not their code is good, you’re going to get the same answer. We wouldn’t ship the code if we didn’t think it was good, and the fact is, functional software that accomplishes its purpose for the client is “good”, by definition.
But if you take the question a step further and ask the same developer the title question above, you’re likely to get a host of different responses, from a second immediate “yes” to a puzzled stare. In reality, many developers are unaware of coding best practices, especially if they work on their own most of the time. There’s no need – as far as they’re concerned – for their code to meet a certain standard for organization, clarity, and elegance, as long as it works.
At CS Preston, we take a different stance, and I think it’s important to understand why.
How custom software code crumbles.
When a single developer takes on a custom software project and handles the code from beginning to end, as long as it functions properly, the client and end user are both happy. If the developer was freelance, the client may never have reason to deal with that individual again, or at least not immediately.
In that circumstance, there’s no reason for anyone to dig into the code itself. The software works, so who cares what’s under the hood?
But let’s assume that, two years down the road, the company has grown and is in need of some significant enhancements on the custom application that the freelance developer provided. At this point, they’ve hired a full timer who’s tasked with taking the project on.
When he opens up the code for the first time, he finds herself completely baffled by the mess before her eyes. The code is so disorganized and poorly constructed, it’s just a hair’s breadth from total collapse!
At this point, the true cost of poorly-written code becomes evident. Rather than simply reviewing the code against standard practices and making the necessary tweaks to accomplish her task, the new developer (and her employer) is stuck either spending countless hours trying to decipher what the first developer did, or scrapping it completely and starting fresh with a brand new application, both of which are going to cost a lot more time and money than a simple upgrade should.
Now, let’s take it further and assume that this new developer – talented and intelligent as she is – also fails to appreciate the value of coding standards. The same company now pays her far more than they’d like to completely develop a brand new application, and another year down the road – after she’s moved on to another company – they find they need further upgrades and their newest developer opens up the code to find yet another indecipherable disaster.
This could go on and on indefinitely, but it doesn’t have to be like that.
Coding standards in custom software: it’s an investment, not an expense.
Most developers – especially those that work independently – naively approach every project as if they can’t and won’t be replaced. They rarely need to work closely with other developers on the same project, and so they understandably consider taking the extra time and effort needed to properly organize and document their code to be a waste of time.
And it’s true: maintaining a set standard for coding that allows for multiple developers to instantly pick up where the last left off does take more time and effort – especially initially as everyone is learning the system. To a developer who doesn’t need to work with others or justify his method as well as his results, that extra time and effort is considered an expense.
After all, they understand how the whole thing works, and if there’s a bug, they can find it instantly. Once they finish the project and move on to the next, what happens to that code is none of their concern.
But here at CS Preston, we view that extra time and effort as an investment rather than an expense. And, like any good investment, it pays dividends that we wouldn’t be able to enjoy otherwise:
- Consistently higher quality – Our normal practice on every custom software project is for one developer to handle coding for a sprint, then for a different developer to review that code and make suggestions for improvement during the following sprint. This leads to a consistently higher quality product and more creative solutions to customer problems.
- Faster overall development – Even though establishing and meeting high standards for code can take extra time and effort in the beginning, once an entire team of developers have become experienced doing so, it actually speeds the process because collaboration is simplified, resource allocation becomes more predictable, and inconveniences like unexpected absences don’t have to bring a project to a halt.
- Easier handoffs – While we do all we can to foster a strong, lasting relationship with every customer, we understand that other studios and development teams may enter the picture down the road. By sticking to a high standard of coding that includes detailed documentation and elegant organization, we make it easy (and far less expensive) for other developers down the road to dig into our code and hit the ground running with enhancements or upgrades.
- Pride in our work – While this aspect may not have a direct impact on the client or the bottom line, I can say from my own experience that making the extra effort to establish and stick to these standards has allowed our developers – myself included – to create some truly beautiful and elegant code that we’re all extremely proud of. And there’s no way to put a value on that.
If you’ve ever run into a situation where a previous developer has left you with a mess “under the hood,” of your custom software application and you’d like to see things handled differently this time around, contact us to discuss your options and we’d love to help you out.
