the three mutually exclusive goals of programming

This is a discussion on the three mutually exclusive goals of programming within the General Discussions forums, part of the Community Boards category; Long ago I used to hear often that you can accomplish three things in programming:
small code size
fast code
...

These are just soundbites meant to impress and give some sort of romantic notion to programming. They are hardly verifiable, do not under any circumstance constitute a universal truth to such a complex and heterogenous task as programming, and can in fact, under most circumstances, be easily proven wrong. Because they are usually given in the shape of some sort of unquestionable truth, they tend to restrain critical thinking.

You can always accomplish all three simultaneously by changing your notion of "small", "fast" and "short". However, if you ignore these relative notions and understand the saying as just being about trade-off, then it becomes obvious that some trade-off between time and improvements of different kinds will always be present, and not only in programming.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

But assuming there was no hardware to handle the speed problem, Would it still be true?

I don't understand what you mean by "no hardware". But does it matter if I don't? What can possibly exist in every software development project ever written that makes it true that no code can be both simple, fast and quick to write? If we are ready to accept this, we need to identify the causes. Otherwise we are dealing with an unproven statement.

Laserlight makes an interesting point about trade-offs. It's a well known problem in programming. But these don't exist everywhere, or are always relevant if they do (in which case the terms "fast", "simple" and "quick" assume different meanings). So the simple matter of fact is that the way the saying on your OP is constructed makes it very easy to write it off as being false.

Originally Posted by whiteflags

Being defeatist in many areas of my life, I refuse to accept further notions of failure in programming.

It does seem difficult to achieve all three at once, though. I remember writing a graphics library for the
Commodore 64, which had none. The computer was so slow, that assembler was only way to do it.
I came up with a very small code size of very fast graphics functions, callable from BASIC. But I really
can't say if it could have been done in less time. I couldn't. And I don't know if some else could have
either. That graphics library was not an easy project.

The time I was referring to had very little hardware to perform things like video or even
audio.

Speed was needed in the code itself. So that has definitely changed and may not be
a factor, at least for certain applications.

But assuming there was no hardware to handle the speed problem, Would it still be true?

How far back in history did you have to go to dig that up... 25 years? maybe more...
Back to days when MS-DOS was king, I'm betting...
Heck, even a 386 machine could play videos at TV resolution with full stereo sound.