Thought of the Day

[Mario F.]

The best time to start optimizing your code is when you no longer plan to use it.

Make no mistake. And I'm getting ready for a very harsh week because of that. There's really no level of optimization that we should apply beyond that which we do at the Design phase. After that, upgrading processors or increasing RAM will always become a cheaper alternatives to compromising your code maintainability. Don't do it. Remember, code maintainability is your only goal in computer programming. It's the only thing that makes it possible for you to code for reusability, or scalability, or easy of use, or whatever else are your requirements at the time.

If this bothers you... next time, Design better.

[CornedBee]

That works only if you consider algorithms with the wrong complexity to be bugs. You can't upgrade computers enough to make up for a quadratic algorithm where something better is possible. If the data grows, it won't scale.

[Mario F.]

I don't. On the other hand I probably would... if I was in the presence of a quadratic algorithm that could have been instead a linear or logarithmic one. Hard not to see a bug in that when, as you say, the algorithm needs to scale well.

In any case, fixing mistakes or bugs is not what I had in mind.

[brewbuck]

I've wondered whether your quotation of me in your sig was meant to be sarcastic. I think the answer is pretty clear now

[Mario F.]

Hehe. Nice way to put me against the wall. But I can assure you I'm not all about hiding deficiencies with processor power and memory. Just some.

To be clear, the real problem comes when one starts to try to outsmart themselves and think that by optimizing stuff that affects early design decisions, they can predict the outcome of those changes better than when they were dedicating all their brain cells to the design of their system. Sometimes -- as was the case -- all for a mere milliseconds gain (**), one ends up sacrificing not only things like memory or bandwidth (that may or may not be important), but also a lot of their time either fixing early design decisions to come to grips with the new code, or the new code maintainability issues that were just created. I think this is a mistake once your project enters production. No optimization of this magnitude is worth that work and the risks that may come with it.

In contrast, optimizing a large system purely for performance reasons by actually implementing it in another language is, for the lack of a better word, insane. I like that quote because a) it should give people (particularly the eager and energetic, and thus deluded) pause to think more carefully about their preconceptions, and b) it is actually how it works in the world out there. Say my bank Cobol subsystems.

(**) it's more like a bit over half a second that was gained.

[CornedBee]

Here's some food for thought, without qualification: I just was at BoostCon, where I talked to someone about software optimization vs machine upgrade. He gave me some interesting numbers about the costs of data centers (computer power and AC power, space rent, technician wages, ...). The bottom line was that making the program 5% faster could save thousands of pounds per year.
It's easy to overlook some of the costs of additional hardware.

[Salem]

Also consider how many instances of "the hardware" there are.

If you're doing bespoke software in-house for example, then your time is valuable. Spending money on the best hardware makes sense if you can be working on something far more critical (that can't be solved just by getting faster hardware).

But if you're writing s/w for mass consumer electronics (say a phone), then if the company can choose a $1 component as opposed to a $2 component, for the want of a bit of programming effort (and still sell the result at the same price), then that's a cool $1M in the bank. The company can afford you to spend quite a bit of time on this, and still be sitting pretty.

[Mario F.]

Yup. I can no doubt agree hardware and hardware related costs should factor in. I wouldn't think being stubborn about code if the consequence involved upgrading a whole data center. That's a prime example where code exerts the most influence at the least cost. And thinking about mass consumer electronics, I can also also see the advantages here of leveraging your performance through code.

[brewbuck]

CornedBee's and Salem's comments are on the mark. I should point out that my comment (as seen in Mario's signature) was specifically said in response to someone who was proposing to reimplement a rather large piece of software from the ground up, in a different language, to achieve some speculative performance increase. Software which is deployed externally has a very different set of conditions.

[Mario F.]

I wasn't speaking of data center software or telecommunications software, or any mission/performance critical software for that matter. Maybe I made it look like I was?

I don't develop for those areas. But anyways... if the necessary disclaimers about performance critical systems needed to be made, they have been made. (Good grief!)

Edit:
- The sky is blue!
- Well no. It isn't at night.
- Right.... (smartass)
- What did you say?
- Let's dance