The Business of Beautiful Code

A little while back I had a technology director tell me it doesn’t matter how well code is written as long as it works without breaking and gets the job done on time. Why sweat it using complicated techniques that not everyone understands when there are more simple ways to do the work. After all, things can look the same on the surface regardless of it being well engineered or put together with duct tape and glue.

This guy liked the intellectually lazy, brute force approach. Don’t think. Just start coding now and get it done. Copy and Paste are now your two best friends. Well, mankind did build the pyramids with Stone Age technology. So I suppose there’s a lot you can accomplish with brute force, but I prefer to use my brain.

Writing software is a very creative discipline that requires a lot of abstract thinking about organization and performance. There are thousands of ways an application could be engineered. It first involves thoughtful planning at the beginning before a single line of code is ever considered.

Writing beautiful code is not just some nerdy game programmers engage in to see who can sit atop nerd mountain with their 4x scepter of insight. It’s about pure design that solves a problem. And there’s a real benefit to business. Beautiful code saves money. Beautiful code makes money. Ugly code gets work done quicker, but it’s like winning the battle, and losing the war. In time, bugs pop up and clients make changes that are impossible to accommodate. Sounds like time for an analogy.

Web sites and applications have a lot in common with cars; they both have a purpose and a personality. Just as we judge a car as being good or bad for a multitude of reasons, we can draw our analogy from these similar evaluations.

A car is designed around the driver, but for many it’s what’s under the hood that counts. Engines can be a mystery though. Sure, people get the basics, but it takes a mechanic to be able to take it apart and put it back together and an engineer to create one from scratch.

When we run a piece of software we look at obvious performance issues. Does it run? How often does it break? Most people you work with will get it up to this point. And from what I have seen, they only care about it up to this point. But, what about real performance?

In the automotive world, performance is well marketed to consumers. They take a certain feature, give it a name, and tell the consumer to want it. Traction control, dual overhead cams, and fuel injection are sold to the public regardless if they have a clue about what it means. The car nerds understand dual overhead cams makes for a more powerful engine. The general public just knows it goes faster.

Beautiful code is high performance. And everyone wants that because it’s faster. Google markets their speed. Type in any topic and you will see at the top of each page a list of how many things were returned and how fast you got them. It’s really impressive when you stop to consider how much data is being sorted to return relevant information. It doesn’t matter if you are writing code or building an engine, you can’t get good performance from a lack of engineering. Speed is good, but maintenance is even more import.

Cars are expensive to maintain and so is software. A study conducted by Human Factors International found that 80% of software life-cycle costs occur during the maintenance phase. Okay, cars aren’t as expensive to maintain as software, but you get the point. Well written software is designed to be updated, changed, bitch-slapped or whatever. It should take it like a man. There are real financial consequences when code takes a long time to update. It can even cancel a project. What I have noticed over the years is regardless of what I am told; I always end up having to go back into something to make edits. As important as this is, there is one more reason why the quality matters.

If an engine is well built, you can put it in several other cars. Good reusable code works the same way. If it’s done well, it can be placed in many applications. There is a business law that states the cost of products and services go down over time. It’s called the experience curve. Businesses find cheaper and quicker ways of getting the work done. When a cheaper way to do business is found, a company charges less to increase volume, or operates with higher profit margins. Either way competitors are adversely affected. Beautiful code can become that competitive advantage to manage the curve.

It’s all about money. It usually is. Ugly code may look like the practical choice. It’s an easy solution when you become defined by deadlines. Some programmers work that way, but surviving isn’t thriving. For businesses to grow and stay competitive they have to have a culture that prizes beautiful code.



  1. I see two barriers to beautiful code. The first you mentioned: money. It takes time to design, and developer time is expensive.

    Don’t mistake what I’m saying with advocating a SDLC style “design it all and then code” philosophy. The person who wrote the SDLC methodology stated himself that it was meant for repeatable processes, such as manufacturing, not specialized, customized endeavors such as software development.

    Even if you are doing an agile methodology you will be doing software design work, just not as a once-and-done task. Beautiful code is, in my experience an evolutionary process. You try things, you may start with the simple approach, realize that there are bad performance issues, and then re-engineer. When you are done you have something that works well and can be changed with minimal effort. Think of painting, you start with a pencil sketch and then start to work in the details.

    The second is lack of experience. Most people out there calling themselves programmers have little or no computer science background. I’m not saying you have to go to university for this, but you have to be willing to learn how to do things in a more efficient manner. Sometimes this comes from schooling, sometimes from self-learning, sometimes from experience.

    Here is an example: Jobs doesn’t want Flash on his iThings. Why? For one, he says performance is bad. Is this Flash’s fault. Not really. Most of is that the vast majority of Flash developers have no idea how to use proper OOP (object-oriented programming) principals. They write inefficient procedure based junk relying on the user having good hardware to take up the slack. They don’t know about design patters, loosely coupled objects, and efficient algorithms. They know the basics, and that’s it.

    Is this the developers’ fault. As before, not really. It comes back to money (it always does). Companies should be paying to keep their developers’ skills up. They should be paying to train them. But, every second they are on skill building is a second they aren’t on a project making money for the company. I’ve been at some companies that did this, but for the most part companies keep themselves short staffed to keep costs down which means they can’t afford to keep their developers skills up. These companies are, in effect, starving themselves, and I have seen companies die because of it.

  2. Interesting post – you provide some good justifications for spending the time to write beautiful code.

    I agree the brute force method of just getting something to work is short-sighted, but sometimes the developers themselves don’t know how to write beautiful code or even recognize beautiful code. After all the term “beautiful code” is subjective and a matter of taste.

    In fact this particular aspect – the problem of how to write beautiful code led me to write a blog post awhile back on how a software developer would go about learning to write beautiful code 🙂

  3. You make the contention that “beautiful code is high performance”, however you offer nothing to back up such a bold statement. In my experience, there is no direct correlation between how well organized or maintainable a code base is and how that code base performs in real world conditions. There is such a thing as over-engineering. For example, I could write a program using OOP and flavor of the week web frameworks to perform a simple task, but in reality that same task could be accomplished more efficiently by using a simple procedural program or some “ugly” assembly code.

    1. To clarify, I feel that performance is more a matter of optimization. Optimization requires an iterative approach. If better coding practices allow for easy modification then beautiful code more easily becomes high performance.

    1. Did you read the article? It’s about justifying the effort it takes to produce better code. There is a real problem that exists in many organizations who have misplaced values.

  4. I like producing beautiful code as much as the next developer. So I build the time needed to do so into my estimates. As long as I meet my estimates, the management folks usually don’t bother me.

    Now from the business side, users really don’t care how beautiful the code is. They don’t want me spending time making code beautiful. They would rather I code some more stuff for them using brute force tactics.

    So there will need to be some business advantage to justify the time required to make code beautiful. Will this make the product more error free? Will this make future changes easier and thus quicker? How can we quanitfy such efforts?

    1. @Maintenance Man, there is business advantage to beautiful code. Most of it has to do with speed and scalability. There are also advantages in the maintenance phase.

      I’ll start with maintenance time first. If you create beautiful, well organized, well commented code, when it comes time to update the program (and you will be updating the program). It will take less time to find where the change needs to be made. If you followed good OO design practices, good design patterns, and did you best to make sure everything is loosely coupled you should be able to make the change with the minimum amount of disruption to any other modules. Most project work is done in the maintenance phase, so if you make the program easy to maintain you are saving the company time and money, even if they have to spend a little more up front.

      Here’s the problem, it takes time and experience to learn how to create applications that follow good OO design, use design patterns, and are loosely coupled. You are not going to learn this in a degree program (in my experience). Real world projects are the only way to properly learn this. So, you’re not going to have it all down at first, but if you work at constant improvement you’ll get better each time. I’ve been programming for 28 years, 15 professionally, and I still find new things to learn.

      Okay onto speed and performance. Here’s an example of brute force vs. beauty. If you have a sorted array, vector, data structure, whatever, with 1000 elements and you want to find something in it. You could do a for loop and just loop through until you find what you want. This means you could loop 1000 times before you find the right thing. The average number of loops will be around 500. Instead you could use a binary search, dividing the list in halves until you find what you want. You will loop at most 10 times using this method. There is a little more framework code behind this as compared to the for loop, but you can see the difference in execution time. This will make a huge difference if you are talking about a back end being hit by hundreds of customers simultaneously. It even makes a difference on the front end since it makes you UI more responsive.

      Hopefully that’s answers your question.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s