You are worrying about the wrong problem. Speed of code is the *LAST*
thing to consider.
If you actually meant this, I would not hire you for my project. Speed
is an important consideration when making any kind of software.
\However\, what you probably meant is what you typed right after.
First, come up with a clean design.
Then get it functioning correctly.
Then, *and only then*, should you benchmark to see if you have speed
issues. If you do, then you should profile to see where the
bottlenecks
are, and worry about those places only.
Let me quote (myself) from here:
Quoting
http://c2.com/cgi/wiki?YouArentGonnaNeedItSeveral people on this page have mentioned something I believe to be
key to understanding YAGNI. Every programmer makes judgment calls all
the time about whether to invest now for the future, or delay work to
the future. The programmer must evaluate the costs of implementing
more general and reusable code vs the cost of doing that more powerful
implementation. It's the simple standard question of investment, which
every programmer does on a daily basis. These things play out when
deciding if you should invest in code:
1- What's the cost of the investment, of writing the "better" code
now?
2- What's the cost of delaying? AKA How much harder would it be to
write later vs now?
3- What's the likelihood of the investment being used, and how much
value would having this investment be?
4- What is your time horizon? Do we need something now, and the future
is less important? This is a very normative question which depends on
the company, share holders, etc.
5- Opportunity cost. Could your time be better spent elsewhere?
YAGNI is simply an observation that many people do not base their
designs on cost benefit analysis. They program for fun, for academic
reasons, etc., and not for the company's bottom line, and this is a
very bad kind of programmer to have in a company.
For example: the aforementioned case of using Java built-in array vs
Java Vector. It's a simple decision. There is no cost to invest in the
better implementation, the implementation using Java Vector, thus you
should invest. You may or may not use the more powerful aspects of a
dynamically resizing container, but you lose nothing by using Vector
over an array.
However, you might have a case where you need to decide between single
threaded, multi threaded, or distributed. There are definite costs in
implementing the "better" system over the simpler system, so you need
to do the proper cost benefit analysis as outlined above in order to
reach a reasonable conclusion.
As a vague claim unsupported by facts, I tend to believe that a little
investment up front for a cleaner design almost always pays off in the
end. Not very YAGNI I know. However, in my current company, I see many
many places where I wish people did practice YAGNI, instead of
producing overcomplicated designs that are a pain to debug, enhance,
and maintain.
<<<<
Instead of generality, the question here is of speed. However, the
moral is still the same for much the same reasons. You cannot ignore
speed and then apply it as an afterthought. Speed considerations must
be present every step of the way if you want to make useful software.
However, I think your position, red floyd, is not literal. Instead,
it's the standard reactionary tale which cautions people to not do
small efficiency hacks in the name of speed; the observation that
speed comes from good high level design, reusable components, de-
coupling, etc. Only once you have your code in a good de-coupled
state, then you run profiling to see if there are efficiency hotspots
to which to apply the efficiency hacks. Attempting to do the
efficiency hacks from the start result in more confused code, and
actually slower code as you're unable to refactor problem spots, all
for higher cost in writing the code.
However, I cannot stress enough there is a difference between good
design up front with speed as a concern, and little bit-twiddling
spread throughout almost as if obfuscating the code.
