Beautiful Code vs. Deployed Code

Something funny happens between when you start a new software project and when you finish it. Before you actually get any code written, you have some preconceived notions about how the code will turn out. You plan to use clear and concise syntax. You'll follow all the design patterns. In fact, you can easily imagine how the next developer that will inherit your code will probably send you a thank you card for how easy and joyous it's been to work on your codebase. Somewhere along the way, all of your good intentions get derailed.

 

 

Project Retrospective

 

The good news is, you've got code released and running in production. The bad news is, you aren't always proud of that code that is stamped with your name on the commits. As you look back on the project and the codebase that was produced, you build a mental checklist of things you'd change or do better next time. No matter how many years you've been writing code, almost everyone from senior to junior developers has these mixed emotions at the end of a release.

Often times there's a balance between getting code deployed and crafting elegant code.

 

Beautiful Code

 

What exactly is beautiful code? Identifying code as beautiful can certainly be subjective but there are well known steps and patterns that can help determine if your code falls more on the beautiful side rather than the ugly side.

• Code is self documenting  - If you look at a method or function and can easily identify what it does either by the method or variable names and the code is short and concise, you are on your way to a more beautiful code base. Small self documenting snippets of code also tend to be easier to unit test.
• Code is simple rather than complex - Just because you can nest ternary operations within ternary operations and you can use recursion rather than a simple loop doesn't mean you should. You might think that fancy syntax and cramming as much logic in one line of code makes you a programming genius but it really just makes the next developer that looks at your code dislike you. Keeping it simple makes your code base more maintainable.
• Code is unique - Your codebase shouldn't repeat itself. If you see code that is cut and pasted around, the code is no longer unique and therefore becomes difficult to maintain.  Your code also shouldn't be re-inventing the wheel. If you can find open source projects and patterns that have already solved a problem you are working on, you should consider using that work.

 

 

Deployed Code

 

While beautiful code is more concerned with best practices and craftsmanship, deployed code just cares about two concepts.

• It works - Deployed code's main job is to work.  If you wrote a 25,000 line class that is bug free and works, you have a really horrible, ugly looking piece of valid deployed code. If it works, it works.
• Time to market - How fast can the code be written and deployed to a production environment? The faster working code can get released, the higher your velocity is. This also includes, your ability to enhance, patch and fix bugs to a previously deployed code base.

 

Can Deployed Code Also Be Beautiful Code?

 

Every piece of code you write, you grow and learn and gain a little more experience. The next time you start a project and deploy code, your code will inherently be a little better than your previous efforts. If you write code and deploy it a few hundred times, your 500th deployed code effort will be quite different than your first. As you gain more experience your deployed code will become beautiful code.

Here are some final thoughts on coding efforts:

• Write a little code often. Don't worry if the code is ugly or not up to some great standard you hold in your mind. Write some code, deploy it, tweak it, deploy it again and then start over. You'll produce more value and gain experience faster than if you refactor and refactor and refactor without ever finalizing your code.
• Write some code with a self imposed deadline. If you never have to worry about completing something (ie. deploying it), you can iterate indefinitely trying to perfect your code. Give yourself a drop dead date to have your code deployed. You will learn a lot about compromising and what's really important in deployed working code.