Take the 2-minute tour ×

What's more important: To write programs fast or to write fast programs? According to: http://math.stackexchange.com/questions/17478/how-quickly-with-better-tool it is better to write fast programs, but I wanted to ask this Q here to get the general gist of what you're thinking on this subject. Of course I'm taking as a given that all programs have to be correct etc. etc.

share|improve this question

closed as not constructive by TheLQ, NickC, Mark Trapp Jul 1 '11 at 7:40


Being able to write programs fast gives you more time to experiment with algorithms, so it's not necessarily an either/or thing. –  Larry Coleman Jan 16 '11 at 14:28
This is a total misreading of the question you link to. It's not about code that executes fast, but rather about tools that take more time to write now and eat less developer time later. You can't compare a program's responsiveness with how fast it's written, since the two are 100% independent dimensions. –  Yar Jan 16 '11 at 16:15
@Yar nope, by tool I mean software which has to be made and then it is used. You just didn't really understood. –  There is nothing we can do Jan 16 '11 at 18:51
I don't understand the question. All other things equal (as you imply in your final sentence), wouldn't you always want to write a program as quickly as possible and have it perform as fast as possible? This is like asking: what's more important, building fast cars or building cars fast? –  Nick Jul 1 '11 at 2:54
Voted to close -- the only answer to your question is "for what purpose?" There is no right answer without any context. –  NickC Jul 1 '11 at 3:43

10 Answers 10

"Make it Work, Make it Right, Make it Fast" (in that order)

Both are important, but realistically, you will need to compromise between them:

  • you can't just jump directly into coding without planning (because it's a recipe for disaster otherwise: anything complex would crumble soon or later)

  • and performance of the application is required as well (because if the application runs like a slug, it's most likely useless unless it's a niche market).

share|improve this answer
I can make ANY piece of code small and lightning fast if it doesn't have to work. -- Tom Stambaugh, on c2.com/cgi/wiki?XwindowProtocolShouldBeStabbedAndBurnt –  Frank Shearar Jan 16 '11 at 16:00
This is a good rule of thumb, but any competent programmer will take into account efficiency throughout the development. Though optimizations should not usually be the focus until it is made right. Good answer though. –  Chris Jan 16 '11 at 18:05
I agree that each case is specific: for example I had one recently from a niche market where performance was not Stack Overflow important because there was little or no competition, so time was the highest factor in that case, but as you mentionned, it's indeed more like a general rule of thumb. –  wildpeaks Jan 16 '11 at 18:40
The importance of the order can not be overstated. You need to make if work to make it right to measure to make it fast. You can not make it fast before it works correctly. –  EricSchaefer Jan 16 '11 at 21:59
Well, I don't know about that. Making something fast AFTER the event might require a complete scrapping and start again. You need all the goals in mind when you start. –  quickly_now Jul 1 '11 at 1:20

Depends strongly on what your boss prefers.

Also, humans are notoriously bad at guessing where the non-fast code is, so it is better to write correct code with reasonable performance, and then have a closer look at the 5 percent then found not performing reasonably.

share|improve this answer

If you don't immediately and explicitly need high performance of your programs, don't waste time here.

That's simply another conclusion coming of the commonly known KISS and YAGNI principles.

For most situations (by numbers) the difference in a few milliseconds won't make a difference. Whether a program performs a user-invoked action in 2.64 or in 2.68 seconds is of no importance. For database-driven and web applications milliseconds matter even less since there are almost always significant delays.

Another aspect to remember, is that it is considered bad for usability if a program responds below certain threshold, the user must be able to "watch" the program as it executes.

share|improve this answer

If you're battling other companies to release the first program on a new market, I would recommend you release it as fast as possible and don't bother making it fast. In fact, you don't really need the best functionality as long as you iterate and release often.

share|improve this answer

It depends on the purpose of the program.

If you are writing a library, it's useful to write a fast program because you have no idea where your library will be used in.

For normal applications, it would be more useful to write a program that is fast enough fast.

So my answer is that it depends.

share|improve this answer

What is the cost of a CPU hour? A byte-in-RAM hour? A programmer hour? Given that (and, possibly, "byte-on-disk hour" and a couple of other measurements), you could, in theory, decide exactly where the cut-off is for various possible scenarios.

Unless you're into massively parallel computing, I'd suspect that "programmer hours" is more expensive than "machine hours".

share|improve this answer
what about 'user hours'? Once you factor the time they all spend staring at a spinning hourglass, I'd say the fast app always wins. Unless you only have 1 user, of course. –  gbjbaanb Mar 20 '12 at 16:04

The formula in the answer over there is interesting, basically it says if the job you're writing the program for takes more than 18 hours, then it's better spend more time writing the "fast" version than to writer the "slow" version.

Which is interesting in the theory. However, it makes a couple of assumptions which I think invalidates the argument in practice.

The first is that the job is something that you've never had to do before. Most software is written in order to automate an already existing process. For example, you might write software to help you manage client accounts, or to book plane tickets or something: before the software existed, you still had to "do the job" but it was a manual process.

In that case, there is still benefit to the fast-to-write, slow-to-execute code, because it's still faster than the manual process. Every time you run the slow-to-execute program, you're still saving yourself money over the manual process.

The second assumption is that there is no opportunity cost in spending time to make it run faster. That is, you might spend 1 hour writing the slow version, or 10 hours writing the fast version. That's 9 hours where you could have been doing something else. Now, we can't say what those 9 hours could have been used for: maybe you could have made 9 other things run twice as fast. So the choice is 10 hours making one thing four times faster, or 10 hours making 10 things twice as fast. Or maybe you just spend those 9 extra hours on Facebook...

Finally, it's also quite rare in practice that the trade-off is as simple as "spend longer to make it faster". You usually have to trade off other qualities in order to make your code faster. For example, it might become harder to maintain, or is not as flexible (so if the customer wants a new feature, all of a sudden you can't use your super-optimized code and have to throw it all out). Maybe the faster version is only faster under certain conditions, and if those conditions don't match up then it runs even slower. In general, there is usually much more to the equation than just "do I spend longer making my program run faster?"

share|improve this answer
but don't you think that writing a faster program would still be a better option? –  There is nothing we can do Jan 16 '11 at 20:20
@There is nothing we can do: Updated my answer to include a bit about opportunity cost. –  Dean Harding Jan 16 '11 at 20:28
and would you know about the maintaining costs for C++, Java and C#? I've tried to ask stackoverflow.com/questions/4680204/maintenance-issue but no one seems to now if there are real differences –  There is nothing we can do Jan 17 '11 at 11:43

It depends on who the user of the program is.

If it's a program with a GUI that you expect to receive user feedback on, then develop it fast so that user feedback is collected ASAP. It's difficult, if not impossible, to accurately gauge what the users of a GUI application want prior to development.

If it's a server-side program that will interface with other services (i.e. SOAP, XML-RPC, REST), then development speed it less important. It's been my experience that with server-side programs their correctness and performance matter more. Server-side programs can sometimes be difficult to debug, so getting it right the first time matters. This often means writing a lot of unit-tests to verify program correctness.

share|improve this answer

In my opinion it depends on the situation

  1. If you need it quick or have a quick deadline then go for write programs fast
  2. If you have time then plan it and go for write fast program

but ill prefer write fast program

share|improve this answer

Speed is relative to a user's perception. Improving a 5 sec process to 4 seconds isn't noticable to those who don't carry a stop watch. If I write a process that runs during off hours, why would I need to increase the speed if it is done in time.

The sooner you get a product infront of users, the faster you get feedback on their expectations. Many businesses just can't wait for faster applications and very few are in situations where speed counts.

If speed mattered, internet apps wouldn't have become so popular. We sacrificed speed for a host of conveniences to the users and developers.

To answer the question: speed matters some of the time.

share|improve this answer
