|
in reply to The Rules of Optimization Club
Dear Mr petdance,
We are sorry to inform you that your application to join Optimization Club has been declined.
In accordance with the spirit of openness enshrined in our charter, the following is a list of reasons for which membership may be declined. All or some maybe be applicable to your application. No further correspondence with regard to the reasoning will be considered.
- The range and or depth of your fields of practical experience is too narrow.
- Your answers to our questionnaire show signs of plagiarism.
- Your answers to our questionnaire show a lack of understanding of our charters primary aims.
- You may seem to fail to realise, that the opposite of 'optimised' is 'inefficient'.
That inefficient means resources are being wasted. And wasted resources are wasted money.
- You may seem not have realised that being IO-bound is not an excuse for not tuning the CPU-costs of your processing.
Even if those wasted cycles can not be readily utilised by other processes within the system; they do at the very least consume power unnecessarily; this generating excess heat; which in turn requires more power to dissipate.
And energy costs are becoming a major proportion of IT costs.
- You may have ascribed to the view that programmer's time is more valuable than processor time.
This viewpoint completely neglects that the programmer's time is paid for once; but the time user's and customer's spend waiting for code to complete, is repeated over and over. And they pay the bills.
Favouring programmer time over customer time is an intellectually, morally and financially bankrupt ideology.
- You may have shown a tendency to assume that your priorities have priority over those of the business you are writing code for.
Whilst testing is important; suggesting that it takes priority over business needs and market deadlines is the tail wagging the dog.
There is not reason for the development role without there being a business justification for its product.
There is no point in delivering the perfectly tested product, if by the time it reaches the marketplace, the demand has gone elsewhere.
Nor will a bloated or slow product sustain itself in the market place in thge face of better optimised competition.
- You may have misunderstood the role of testing.
Testing is a means to an end, not and end in its own right. Testing is a cost centre not a profit centre.
When the processes of testing incur costs greater than the aggregate costs of an in-the-field failures it might prevent, it becomes an irrecoverable drain on resource.
- You may have demonstrated a narrow field of view with respect to development methodology and or testing tools.
Mandated monocultures preclude deriving benefits from alternative approaches and mechanisms.
For and on behalf of The Optimization Club.
Mostly humour. But as with all the best humour, there is a strong foundation of reality. |
Re^2: The Rules of Optimization Club
by petdance (Parson) on Mar 30, 2012 at 23:58 UTC
|
You're inferring a lot that I didn't say or imply.
You want to optimize for energy consumption and heat output? Go ahead. Just measure before and after so you know that it was worth your time.
While I didn't say anything about programmer vs. processor time, the rules about measuring apply there as well. Depends on if you're building a compiler or a one-time data conversion script. And how much does your programmer cost? Again, measure.
Measure measure measure so you know for sure.
| [reply] |
|
|
one-time data conversion script.
I would not write tests for a one-time data conversion script. There's only one test for a one-time script: its run.
| [reply] |
|
|
Arguably, feeding the head of the 25GB input file to your one-liner and checking the output displayed looks right, is a different one-time script to the feeding it the whole thing and redirecting the output to the results file.
But it's definitely a test worth doing :)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply]
[d/l] |
|
|
|
|
|
|
I don't think anyone is advocating writing tests for one-time data conversion scripts. Certainly I am not.
I think you've confused all the things that you think I said into newer meta-things that I haven't said.
Rule 6, "Testing will go on as long as it has to." only matters if you're optimizing. If you're not optimizing (or any sort of refactoring) that data conversion script, then no testing need take place.
| [reply] |
Re^2: The Rules of Optimization Club
by tobyink (Canon) on Mar 30, 2012 at 21:48 UTC
|
This viewpoint completely neglects that the programmer's time is paid for once; but the time user's and customer's spend waiting for code to complete, is repeated over and over. And they pay the bills.
That very much depends on the task at hand. Consider this: on a database there are 10,000 or so payment schedules recorded for £3 every 4 months, but it turns out this was a systematic data import error, and it should be £4 every 3 months.
Given a choice between:
- Programmer spends 2 hours writing a script that fixes problem at a rate of one payment schedule per second; and
- Programmer spends 4 hours writing a script that fixes problem at a rate five payment schedules per second.
Then chances are that the first solution would be preferred. OK, so the script is going to take close to three hours to run, but it's a one-off fix, and nobody has to stand over it while it's running.
There are cases where the developer's time is more precious than the performance of the program. And there are cases where the performance of the program is everything. Most, of course, are somewhere in between.
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply] |
|
|
but it's a one-off fix, and nobody has to stand over it while it's running.
Exactly! One off and no user waiting. Unimportant, and beyond the scope of the remit.
Contrast with millions of people every hour of every day, waiting a couple of extra seconds for their ging/gang/boogle/yoohoo/facespace/mybook/tweedle/amabay/tescutters interactions.
Excess cycles consumed by one customer are lost to others waiting. IO-bound doesn't mean either non-urgent or non-critical.
Even for far smaller scale businesses, the loss of individual customers to impatience with sluggish backends and overindulgent, pretty frontends can be critical to your bottom line.As the world gets smaller and the choices of places to shop get ever wider, efficiency is critical to first establishing and then keeping a customer base.
Web pages that fail to respond within 10 seconds; or that aren't ready to accept input with 3; just don't get a chance to sell me anything, much less advertise to me -- by then I've moved on to the next hit on the search engine list.
Leaving optimisation as an after thought, rather than building it in and measuring it as you design and develop your code is like building a shop with narrow, difficult to open doors and not switching the lights on.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
|
|
