But if your program actually gets run on several thousand of different boxes, it become a different matter

Sure, but 90% of software development is done as some for of in-house customization work. Less than 10% is coding software as an industry commodity. Very, very, very few apps will ever make it onto hundreds, let alone thousands, of different boxes. Of those, the hardware upgrade benefits will in some cases be justified. Your point attacks a straw man; the common case is so far removed from your argument as to be entirely inapplicable.

And if you produce a program once a month, and each time you're investing in faster hardware

Almost no one produces a program "once a month", nor invests in faster hardware "once a month". It takes at least three months just for the average department to decide upon what it wants, let alone document those wishes clearly enough for them to be written into a program of noticable complexity. Again, you're vigourously assaulting a non-issue.

Upgrading 2,000 boxes for $500 each means spending a million dollars. That's a few programmer years

Well, at my company, we wasted several programmers years trying to do an in-house optimization as part of a code cleanup. It didn't work; the designer of the new system was incompetant. The new code is as ugly as the old; and the "optimizations" slowed things down so badly that we bought new hardware to solve the problem. How did we eventually triple the throughput of our program? We ran four copies in parallel on a quad-CPU machine. ;-)

In many places, putting just two contract programmers on a project for three weeks costs the company about $10,000. Buying $10,000 worth of hardware is probably going to give you a faster running program, sooner, for the same cost to the company. If the program gets scrapped by upper management, the company can still make use of the hardware; it's a generally valuable asset. Not so for the optimized code; it's a strictly limited use asset. Unlike the optimization effort, the hardware optimization is very unlikely to introduce bugs into the software. Unless you're buying a lot of hardware, (and most companies aren't) it's just no contest.

So, unless you work for Microsoft, or some other software vendor, you don't need to optimize code as badly as you need it to be bug free. Fast hardware is cheap. Fast software is expensive.

In reply to Re^3: Optimisation isn't a dirty word. by Anonymous Monk
in thread Optimisation isn't a dirty word. by BrowserUk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.