You say “re: Is a piece of code considered high quality because it’s elegant, follows best practices, and so on? Or is it high quality because it does what it was written to do and does not have to be altered in the future.”

I agree with two caveats:

I don’t believe in “once and for all” for any project people are going to use and maintain going forward. “Easy to understand and change” trumps any “once and for all” in my opinion.

“Does what it is written to do” is a platitude, really. All code operates as it was written. If the code does something really useful (value to end user) it can be elegant, but of course 60% of all features are never used, so code could be internally elegant and not particularly useful.

So “it does something people need it to do”, “does a good job” (performant, etc), and “is easy to change without breaking anything” would be pretty high on my list of qualities for elegant code.

My take was to try to reach past the practices and approaches and pick out the virtues they’re reaching for. It helps me understand different approaches better. http://agileinaflash.blogspot.com/2010/02/seven-code-virtues.html

I’m not the first to do that, and I may not have done it best, but knowing why people make these statements always helps me to make decisions. I think we all want good product, delivered on a timely basis, and which does not create problems in the future but options instead.

I hope this helps.

These are worrying questions of yours:

“Is a piece of code considered high quality because it’s elegant, follows best practices, and so on? Or is it high quality because it does what it was written to do and does not have to be altered in the future?”

This seems to be an expression of a common meme:

“Just make the code work as soon as you can. It doesn’t matter if it’s rubbish code because the customer doesn’t care about code”

That POV is wrong. The quickest way to get anything beyond the most trivial software in the hands of customers is to write the code well. Crufty code slows you down, sometimes within hours. Write crappy code and that release date will slip. The customer tends to care about that.

Most code also has a long life. You pay dearly when you need to change poor, “quick” code. The customer cares that you can’t make changes in a timely fashion and that the software keeps breaking when you try.

Also, I’d like to see how you guarantee code will “not have to be altered in the future”. That sort of predictive power would be better used to pick lottery numbers, surely!

By definition, best practices are not things that slow down delivery. If they do, they clearly aren’t best practices! (At least not the way they’re being done.)

For example. how do you tell your code “does what it was written to do”? Maybe unit testing would help? Or do you think that that is going to slow you down? (If it does, you aren’t doing it right.)

All my 20+ years of professional experience in this business tell me that the way to write code the fastest, is to write good quality code.

Customers may not care what the code looks like, but they certainly care about the effects bad code has on them.

Code should always be well commented… one way to do this is to instead have unit tests and well named methods .
Seemingly random class explosion is to be avoided at all costs, but many small simple well named classes are the key to well organized code.
Unit tests really don’t test anything useful unless they have a clear purpose are easily understandable and are written in a way to not be brittle.
Using dependency injection everywhere leads to an unusable mess, but Dependency Injection is a very useful tool for making your code extensible and easily reused.
Inheritance leads to solid code reuse, but inheritance is also the strongest coupling of your code you can have, so only use it when composition doesn’t make sense.
Functional programming simplifies and minimizes the complexity of your code, but Functional programing can make your eyes bleed, so try to use good naming and simple constructs over doing things “clever”.
Static global references are ‘just programming’ and something you have to learn how to manage to make simple easy to understand code, but Static global spiderwebs are crippling to maintenance and program lifetime so only use them where they make the code much simpler.

@Gregory Agree about beliefs, people (myself included) carry it too far. However, I still struggle with what you say about “equally acceptable solutions”, Who is it acceptable too? From my perspective I’m struggling to understand where the line is to be drawn from “you’re going to reap terrible results from this in the future” to “this is acceptable for the way the organization works”. There are cases where both are true, does that make it an acceptable way to approach things? Especially when what someone else would call “terrible results” to someone else is “just the way software development works”

I won’t even touch the definition of professional software development, but this statement hits what I think may be one of the biggest enemies to improvement in our profession. People have too many beliefs in our business. Beliefs are a crutch, a way to halt our learning process, declare we have found The Truth, and hide our heads in the sand.
It would be better to realize we all just have ideas. Those ideas only have merit if they help us solve the problem at hand. If two different ideas result in two equally acceptable solutions – what’s the fuss?

good questions for thought and I do not have an immediate answer. I’ve tended to view high quality software as something that behaves as expected. But obviously more often that not software ages out of use. the problem it was solving was no longer as important, or the technology it was written in was “deprecated” so how much engineering is needed is contextual and not really known at the time.

I respect how you’re viewing that particular list as a toolkit for a particular project. In reality though most of us get very dogmatic about a particular style we’ve stumbled onto and hold it for dear life. This makes teamwork and craftsmanship difficult, and occasionally impossible. Now I agree it shouldn’t be that way and people should be willing to adapt and adjust, but it’s not always the case.

There is just so much more potential for conflict among those that are otherwise capable in their own right than I’m entirely happy about.

A Rant on Professionalism
http://www.lostechies.com/blogs/chad_myers/archive/2009/01/11/a-rant-on-professionalism.aspx

Good Design is Not Subjective
http://www.lostechies.com/blogs/chad_myers/archive/2008/08/18/good-design-is-not-subjective.aspx

Minimum requirements for “Good” software
http://www.lostechies.com/blogs/chad_myers/archive/2008/03/16/time-to-login-screen-and-the-absolute-basic-requirements-for-good-software.aspx

Taken out of context, these phrases don’t make any sense when they’re all put together like this, since half of them contradict the other half. However, I believe that it takes a good software craftsman to be able to decide which idioms to follow for the project at hand. If someone were to strike up a conversation with one of the above phrases, I would want some good follow-up on why one would say something like that, not simply take it to mean that one would think that it’s the end-all be-all mantra to go by.

At the end of the day, what matters is the software produced. Consumers are not going to care how elegantly code was written, if it’s under test, etc. They just want they paid for. That’s not saying that some of the phrases used above aren’t a means to that end. It’s simply the fact that the only people that will see the code (barring open source projects, naturally) are the developers. Beyond that, the world merely witnesses the product. Is a piece of code considered high quality because it’s elegant, follows best practices, and so on? Or is it high quality because it does what it was written to do and does not have to be altered in the future?