When To Write Bad Code
Have you ever had this situation before? You have a problem to solve and no idea how to solve it. You want to sit down and do it “the right way”, but “the right way” involves writing tests, designing objects and generally working out something that’s far more complex than you need to get a working prototype. And so nothing gets done.
I’ve been there myself. I recently needed to prototype something. As I sat down to work on it, I had absolutely no idea how I was going to write the component I was working on. And so, I started working – without a plan, without writing tests, without designing an architecture, and without really knowing how the component was going to end up.
You know what? The component came out working, but when I was done it was ugly. Totally ugly. The code was bad. But I had a solution, and a solution that worked.
People who teach others how to write software too often forget that we’re responsible for showing the right way, but the right way can’t come at the expense of experimentation. Developers are paid to solve problems not to write code; our code is our expression of a solution. But most bosses who aren’t technical don’t care about coding standards and test plans. They care about problems being solved.
I advised an individual this week that it was therefore okay to write bad code if it meant getting something down in the code editor and ready for demonstration to someone else. I pointed out to him that getting something done beat getting nothing done, and that code was infinitely refactorable. He could clean it up once it was working.
Telling people they have to write perfect code from the beginning is like telling an author that they can’t have any mistakes in their rough draft. This would be absurd to most of us, yet we seem to think that writing code that can be thrown away or refactoring it after the fact is somehow a bad thing. Refactoring and rewriting code is just a part of our jobs.
This is not an excuse to release bad code. This does not absolve a developer of the need to come up with good solutions that also adhere to developer best practices. What this does is free developers from the belief that they have to be perfect from the very first line of code. It’s okay to write code not knowing where it will end up and to fix it as the next step.
This was part of my goal in writing Mastering Object Oriented PHP. Rather than espousing a particular design philosophy, I highlight the best practices that worked for me over time, in an easy to use way. These are the best practices that I use every day. If you’re struggling with object oriented PHP, Mastering Object Oriented PHP is a great resource for you to be able to understand the best practices, and also have the freedom to experiment. Pick up a copy today.
When the code is working and you’re ready to move onto the next phase, then you can work on making the code pretty, readable, well-documented and tested. While this flies in the face of concepts like test-driven development, I believe sometimes it’s necessary for developers to simply get the problem solved and worry about the details later. But this does NOT mean that developers can push bad code into a repository. Nothing lives longer than temporary code; see to it that your finished code is always good.
My prototype was rewritten, this time in the right way, with the components and architecture required to make it into good code. Nobody ever has to know that the first draft was ugly and horrible; they only care that the finished product is great. It’s our little secret.
This is a excerpt of the material that I send out each and every week to my mailing list through the Developer Weekly series. Sign up at the bottom of this post and never miss an issue!