You Should Write Ugly Code

Yes yes, "True artists ship". In general though I would say that you can and should strive both for end-user value and overall systems quality.

I agree to a point - the pattern du-jour has little to do with good code. I also agree - to a point - that prototyping should produce results as fast as possible. It's very hard to create something new and novel without rambling prototypes. You need those to feed your intuition on what aspects are critical and what are not.

As a general guideline, though, this is horrible advice. Although it depends on the definition of "ugly". I would pragmatically define beautiful code as something that is as simple as it can be to implement a useful set of end-user functionality, contains only acyclic dependencies, obeys the key-rule of DNRY (do not repeat yourself), is buildable using a single developer action, is preferably automatically deployed ... and so on and so on.

The key metric to beautiful code in my opinion is that the code and it's host system is in every way as simple as it can be. Sometimes you need a few abstraction layers to simplify the total complexity, often you don't.

It's not just the code. It's how it integrates with the rest of the world that matters. The integration points can be productivity multipliers for the organization.

And, as a developer, you can learn all the time. The better systems you build, the better the next system will be (unless it happens to be the second system where you traditionally must try to implement something horribly baroque). You have to be learning constantly to grow as a developer. You have to consciously strive towards simplicity and elegance, because otherwise you will get stuck. If you accept bad code as "good enough" always, I fear you will not grow up to your full potential.

This article is attacking a very narrow and superfluous definition of beauty, that I would instead call fashionable. The beauty of a piece of code should depend not so much on how well statements are aligned and consistency of formatting, and more on how easy it is to understand; the complexity of the task in contrast with the simplicity of the program.

That said, I still take issue with criticizing his narrow definition of code beauty. We should be allowed to dote on our code and make it pretty. Even if it doesn't provide tangible value to the customer, it lets us take pleasure in our craft.

Why shouldn't I take pride in my work?

>When facing an implementation choice, should a developer opt for solution A, which uses ugly code, or for solution B, which is beautiful? That's not the right question: from the end user's perspective, the alternative doesn't make any sense. The user won't look at the code, especially if the product is not good enough to be even tried.

"Let us do our work as well, Both the unseen and the seen;" - Henry Wadsworth Longfellow, The Builders

You can write ugly code that works or you can write beautiful code that works. You can't write beautiful code that doesn't work.

"Complexity will happen on its own, so don't go looking for more."

Best aphorism of the week.

I feel like functional and non-OOP languages are probably unpopular in the corporate world because when you're using one, there is not really any need to have a business analyst design the application in UML diagrams or Microsoft Visio. Java, on the other hand, is perfect for that, if that's what you're looking for. Java and enterprise software were made for each other.