The question of 'what is elegance?' has been asked before, and rather than arguing about that, I think we could probably all agree we know it when we see it.
But I'd like to know is elegance a goal of programming (an essential aim), or merely a desirable side-effect? (or technique)
If we create code which isn't elegant, have we failed?
For me, the goal of programming is to produce maintainable code that works.
Now, maintainable means that the code should be easy to change over time (hence should be easily understandable) and should be easily testable.
If this goal is achieved, i believe that the code will be elegant and beautiful.
Jeff Atwood thinks that
"Ideas are beautiful. Algorithms are beautiful. Well executed ideas and algorithms are even more beautiful. But the code itself is not beautiful."
Perhaps those who have answered before me work in the arena of academia, but in my opinion the purpose of code is to provide your users with useful software that makes their lives better or easier in some way. Beyond that, yes, elegant code is great, and it is something to strive for, but it is not the end goal and you have not failed if you wrote a tangle mess of code that solves a problem in its domain and provides its users with a good experience doing so.
Obviously code quality is important for may reasons that others have touched on. You can't claim competence in your field if no one can understand or modify the fragile code that you have glued together. However, it is not the single most important aspect of our jobs, and anyone who thinks that it is the end-game in the real world is mistaken.
If we create code which isn't elegant, have we failed?
Mostly yes, and partly no.
Most of the times, code becomes ugly once we start peeking into the internals of the framework/language (which is occasionally necessary to build additional functionalities into a language or to build libraries that provide such low level functions). Hence, code that is not entirely elegant does not constitute a failure, when compared to its importance.
If the code is not elegant but works, have you failed: No
The answer is No.
Its just a question that will start an argument. Like if you paint a picture, if its not a work of art, have you failed?
Elegant code is a "nice to have".
It shouldn't be a goal in of itself. The most elegant code on the planet isn't really worth much if the application never gets released because you went out of business building it. Or if you created a product that looks amazing under the covers but doesn't provide anything that anyone wants to use. Or if your clients walk out on you because you keep refactoring instead of giving them the features they want/need.
Obviously, we'd all rather have elegant code. But success is measured by totally different metrics in my opinion.
In answer to your question "No, but ..."
If we leave the non-elegance as done, I think we have failed.
If each time we visit the code after it is "in" in its non-elegant manner, we make it a little better (Refactoring whilst backed up by a good suite of unit tests) then the elegance will come.
Kindness,
Dan
From my (limited) experience, the two primary and easy-to-remember goals should be (Borrowing copious amounts of knowledge from Alistair Cockburn):
Elegance is a desired attribute of code not a mandatory one. e.g. if TeamA produced an app that met the desired market need and made millions while TeamB labored to produce an "elegant" app that missed the bus and came out 6months to a year after TeamA, Guess who won?
But I'd like to know is elegance a goal of programming (an essential aim), or merely a desirable side-effect? (or technique)
I think that striving for elegancy is a trick to produce tolerable code. So, even if the end result isn't quite as elegant as you tried to make it, you haven't failed; instead, you've succeeded in creating good enough code.
The end result will usually be somewhat worse than what you planned, so your best bet to get something good is to strive for excellency.
If it works, but isn't elegant, it probably just means you are not finished yet. Refactoring is your friend now. In my experience, elegance is hardly ever reached on the first try.
The aim should always be to write elegant code. Any deviation from this aim is a failure, even if the code works, a failure that can be remedied but a failure no less.
And of course It depends on what you mean by saying elegant. It depends on how you define elegant code in your dictionary.
We should always remember that the process of writing code that solves a problem is nothing else than a kind of business value generation. The code you write then becomes one of the assets your company has, similarly to how an assembly line person puts together a computer that becomes the property of their employer and which gets sold afterward.
If you do not write your code in a maintainable way, then you are providing your company with a lower business value. Invariably this code will need to be tweaked, fixed, etc, and your company will have to spend more resources on this than if you had written it nicely from the beginning. In some cases (notably when the initial codebase originated in South Asia), the investment to perform this maintenance hugely outweighs the savings gained early on from producing quick and dirty code.
This is of course only one part of the equation, it fits in next to many other sources of business value. You may sometimes need to sacrifice on the value of your code to be able to reach out and grab a lot more value in other ways (e.g. if your video game hits stores on December 27th, the value of your clean code is practically null next to the amount of money you lost).
Unfortunately, many managers are not well equipped to properly weigh the value of code vs. the more traditional business value sources like customer acquisition. They view their codebase as some kind of ephemeral magic they had to pay for in order to satisfy their customers' whims, instead of true business value they own. With managers like this you will often be pushed to produce code faster while ignoring it's elegance. The other edge of this sword is that they also won't understand why you need to take so much time to fix something in last month's release. Hopefully you'll be able to educate them on the value of code elegance :)
I think elegance is overrated.
Code should:
None of those things require elegance. In the database world, elegance is often the enemy of efficient. Efficiency should trump elegance, the users care about efficiency, they don't see or care about elegance.
Like so many other things in life, (drumroll please)........ It Depends.
The first thing you should be writing code for is to solve the problem. After that, you should write elegant, maintainable code, then finally, specialize for the situation. Sometimes there's no other choice but to write some ugly hunk of trickery to speed up your code execution, and that's not a failure.
Unless elegance per se is rarely a requirement. Maintainability ... which is often related to elegance ... is often a requirement. However, unless maintainability is overriding requirement, then code that is inelegant/unmaintainable is definitely not a failure.
So this boils down to the question as to whether elegance / maintainability is an overriding requirement. And that depends on various factors:
Maintainability is a requirement for code that has to last a long time, even if this is not explicitly stated ... or even recognized by management.
Maintainability is generally not a requirement for a prototype / proof of concept.
Maintainability may be overridden by a requirement for performance.
Maintainability may be overridden by a requirement to get something implemented / fixed quickly.
Elegance and maintainability are not always the same thing. Consider for example, that the most elegant solution to a program may be to code the application in (say) Haskell. However, you are working in a C or Java shop, and nobody but you understands Haskell. Your elegant solution won't be maintainable by the rest of the team if you are hit by the proverbial green bus.
Finally, the (hypothetical) notion that elegance per se is an overriding requirement is IMO, just plain daft. Programming is an engineering discipline, not a fine arts discipline.