Coding Priorities: Performance, Maintainability, Reusability?

Question

This came about mainly due to answers to SQL questions. UDF's and Sub Queries are intentionally omitted because of performance. I didn't include reliability not that it should be taken for granted, but the code has to work.

Does performance always come first? So many answers are provided with performance as the main priority. My users seem to be more concerned with how quickly the code can be modified. So a report takes 15 seconds instead of 12 to run. They can live with that as long as I'm not making excuses for not providing solutions.

Obviously if the 15 seconds turns into 15 minutes, there is an issue, but users want the functionality. They want the application to adapt with the business rule changes and enhancement requests. I want to be able to look at the code 6 months from now and be able to make the change in one easily identified spot and not chase down all those places soneone copied and pasted code because they thought calling another function or sub routine or Udf would hinder performance.

All that being said, I would order: Maintainability (Change is a fact of life.), Performance (No one likes to stare at the hourglass.), Reusability (Difficult to determine what code should be used again.).

Answer 1

Edited 2010-03-02: The question originally started:

Does everyone work for NASA? Does performance always come first? So many answers ...

No-most of us do not work for NASA.

No: reliability and maintainability come ahead of performance. Reusability is good too.

Within broad limits, performance is not important.

Answer 2

The sucker answer is of course, "it depends".

In the case of line-of-business applications the response time for the activity involved needs to be inversely proportionate to the frequency with which it's run. If it's a function that the users need to access 4 or 5 times an hour it had better be snappier than pulling that month-end report.

I think, to some degree, you've answered your own question and provided some pretty valid reasons for it. The only one you've missed is Reliability -- and this is where tha NASA analogy comes in. If you're writing code for NASA, or for a financial institution, it had bloody-well better be robust and reliable... and I think that'd be the first priority.

Answer 3

they thought calling another function or sub routine or Udf would hinder performance

That's wrong thinking.

I would order: Maintainability, Performance , Reusability.

Sometimes (usually IMO) reusability is maintainability: it's because you reused something that you are "able to make the change in one easily identified spot and not chase down all those places soneone copied and pasted code".

Answer 4

1. Maintainability: If the code is un-readable it's useless, no matter how fast it is. And it definitely won't be be re-used.

2. Reusability: Not all code is reusable, but a lot of it is. If you can, by all means make your code simpler. The easiest is divide and conquer. For example, create simple components you'll use over and over and over. UI widgets are the most common. But it's the same with utilities. As well, creating a structure/framework to your code helps. Error validation code, etc.

3. Performance: Generally most code is performant enough. And if not, use a code profiler. More often than the bottleneck will far outweigh any small code optimizations you could have made at the cost of either readability or re-useability.

Answer 5

I do work at NASA. However, I do not (currently anyway) maintain or develop real time code or any thing that is all that performance critical. Most of the software done at NASA probably isn't. Having seen some horrific code in my day, I'll also go with Jonathan's answer of reliability and maintainability followed by performance and then reusability for most applications.

Answer 6

I am a NASA contractor and develop and maintain software primarily for administration purposes such as running reports and tracking projects.

I have been working there for about 1.5 years and I believe their main concern is maintainability and how fast can you get that new feature or module deployed.

Like Guiness stated in the question as long as the software does not take an exceptional amount of time, they don't seem to mind.

The other main concern they seem to have is usability. The application must be easy and straight forward to use.

In conclusion, Maintainability, Usability, then Performance seems to NASA's main concerns for internal reporting and tracking tools.

Answer 7

You have to be able to rearrange these priorities depending on the project, and the hard thing can be changing behaviour quickly as you switch between projects or even different sections of code. I work on three applications with very different profiles.

1. One is real-time and a lot of work goes into making sure its performance is predictable, (not necessarily lightening fast) but change isn't a major issue, it only changes significantly when the IETF changes/obsoletes the RFC and there's little sign of that. (That said, I'm quite proud of its level of maintainability).

2. Another app has at times taken 16hrs to process 1 day's data. Needless to say absolute performance quickly became the top priority. But even within this app the emphasise of performance varies dramatically, from 'not important' in the per-batch-code through per-client-code, per-task-code, per-file-code, per-record-code, per-field-code to 'extremely important' in the per-byte-code.

3. The final app contains much of the business logic, performance is never an issue, maintainability and agility are key are and this app benefits most from all the fashionable methodologies, however, when I've just spent weeks or months refactoring for performance it's very hard to write "string1 + string2 + string3 + string4" even if that is the most readable and performance is irrelevant.

Answer 8

Performance doesnt't come first, even at NASA! At NASA, if the code isn't correct and reliable, people die.

Moreover, in my experience, even when performance is valuable, it's up to a point; there's usually a performance level that there is little or no additional value in surpassing. In contrast, there is additional value in improving correctness no matter how reliable a piece of code is; a piece of code can't really operate as expected too often.

To me the order would be:

• Maintainability: if it's not easy to change, it won't stay correct for long, even if it is correct now.
• Reuseability: reuse improves productivity, and less code is generally more reliable than more code.
• Performance: sometimes performance matters, but you'd be surprised just how much code isn't performance critical, even in a performance critical application. Performance optimization matters for bottlenecks only.

Answer 9

One of my favourite quotes is from SICP ...

"Computer programs are designed to be read by humans and incidently ran by computers."

I rate all of these ascpects of my work; but readability (some use the term expressiveness) of my code and those I work with tops my list of importance.

Just my 2c, have a lovely weekend!

Answer 10

I think you missed one from the list: reliability;

so my order is

• Reliability and accuracy
• Maintainability
• Reusability
• Performance

It doesn't matter how fast code is when it isn't right, firstly the code has to be reliable.

Performance is at the bottom of the list. Never optimise too early, and only improve performance when performance is a problem.

I've worked on real-time systems including flight simulation, and even in that environment performance is taken into consideration but is not an overriding primary concern ¹.

I would say that in my experience I've only ever had to optimise less than 1% of the code that I've written.

---

¹ sometimes something isn't quick enough, and of course performance is taken into consideration when designing and coding, it's just not at the top of the list.

Answer 11

In an isolated answer, Performance will virtually always come first.

We don't know if you are going to hit this piece of code a million times in a row, so performance is a concern by default. We don't know if our precious code snippet will become the bottleneck of your application, since we don't know how it interacts. (The same happens when writing library code: I don't know how this is being used. One reason IMO code reuse isn't simply "moving similar code to a shared entity".)

Maintainability is even more affected by how the code interacts with the code unknown to us. The answer will solve the problem in the scope you set: You can ask for or tag as SQL, or SQL Server or MySQL. The rest, we just don't know: How many similar code paths you have? How often this piece of code will be changing during the life of the project? Will you stick to that particular database server version for ten years, or will you be updating frequently?

Solving Maintainability is largely your job: Is the question you ask an entity that should be isolated?

Readability is mostly done, the rest is your job. When answering we are usually interested in you understandign the answer, so it needs to be readable at least for you. If you copypaste that snippet into your code and slap a // That weird query comment on it, not my problem anymore.

Add to this the fact that performance is easier understood: From two functionally equivalent answers you will always pick the one that says "like Joes answer, but a bit faster", unless it makes huge mistakes in the M+R department.

---

Writing this now it looks like there's a reason that premature optimization is tempting. This is the wrong priority for a couple of reasons.

The low priority for optimizations has two major reasons, though:

Answer 12

Correctness is more important than maintainability, reusability, or performance. If you aim at correctness, you're likely to get the other three in the bargain.

• Write no more code than necessary.
• Leverage standard libraries.
• Prefer transparency to cleverness.
• Write small, testable functions.

Answer 13

This is an intersting question and the answers are quite intresting enough. The priority depends on the implementation. I would like to present one of the example where users would not sacrifice performance for maintainability or reusability. Yes there is a factor of reliability - there should be any bug/error. So when we compare maintainability, performance and reusability.

One of our client had online trading site. Under peak loads an average transaction would take some where around 14 ms to complete at middleware level. Some time latter the performance of application degraded (due to some reasons) and the transactions average time increased to 24 ms. Now as a normal developer we would think 10 ms is not so alarmingly critical. But if we think from business perspective then it is alarming. How? let us analyze:

Lets assume that under peak loads, the resources are fully utilized and with 14ms we were able to do 100 transactions. Now with degradation in performance the transactions take 10ms extra that is 71.42% extra time. Now this would mean we will only be able to serve 28.58 transactions instead of 100 transactions. This means serious loss to business.

Infact there is lot of literature on importance of application performance. There is a very nice book "Quantitative Approach to Computer Architecture" that explains how the factors of performance, maintability, reliability, avaliability can be quantified in business/user terms.

I will not specify the order of importance as the same is context specific.

Answer 14

Here are the results based on Tag Count:

• Performance - 952
• Reusability (several related tags) - 43
• Maintainability - 14

What does this mean: Performance must be important? Performance is harder, so more questions are asked. Performance questions are more specific/approprate to ask on this site?