|
Not always, sometimes you have to convince the client to do the right thing.
For example, i had a client that had a existing web application and my task was it to add features for which the original code never was designed for. I.e. it would have take me longer to implement the new code, than rewrite the whole application from scratch.
So i had to convince my client to do "the right thing", and let me rework the whole thing for the same price.
|
|
|
|
|
Hi there, I have an application in the need of a new feature... 
|
|
|
|
|
How about, NO? 
Done it once, and will never again. 
|
|
|
|
|
Fair enough.
|
|
|
|
|
Daniel Lieberwirth (BrainInBlack) wrote: Not always, sometimes you have to convince the client to do the right thing.
In this case the client is doing the right thing. They wart accuracy over performance. How can you argue with that? 
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
I didn't argue, i just challenged your somewhat general statement that the client is alway right. He isn't and that's the point i wanted to make clear with my statement.
|
|
|
|
|
Whenever in doubt the customer is always right.
The only exception to that is if you do not want to be paid for your efforts. 
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
1- The client is right about WHAT they want. Client is usually never right about HOW to do it or how much it will cost.
2- Accuracy over performance. Accuracy is usually a black or white determination (not always, but usually). Performance can be tweaked and dialed up in degrees over time and iterations. To paraphrase...first make it work, then make it work fast, then make it elegant.
|
|
|
|
|
jeffreystacks wrote: first make it work
The 3 biggest lies:
1 - I love you.
2 - I will respect you in the morning.
3 - Just make it work so we can release it and we will go back and refactor it later. 
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Depends. If numerical calculations are involved, there are technical limits to the accuracy you can achieve, and trying to push down the tolerance limits below that won't achieve anything but provide a false sense of accuracy that simply isn't there.
|
|
|
|
|
Ravi Khoda wrote: we have some work on the database side where batch files data is insert (row count is several thousand per operations )/ some text files generated by windows services / flag status maintain based on the data insert in the database per operation and many other small operations happen during this process. obviously correctness of the operation is must but at the same time performance of the operation came in to the picture. some teammates says that as there are lot of process happens during per operations it will take time to complete things while some believe that there can be something done to reduce the time. Client is okay even if that takes time as for him accuracy is more important rather than time taken. How to manage such scenarios ? after some level we can not think of optimization on query as all the things which is written is necessary. does anyone face such things ? how do you manage things to improve the performance?
Let's not lose track of the task at hand. It is database update, not calculations to put a space probe on Uranus.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
A valid point. Then again, the only meanings of accuracy I am aware of don't relate to the only alternatives being data is there or not there! If during a transaction data is lost, then the transaction is not inaccurate, it is erraneous!
P.S.: I've just found that "free from errors" is actually one of the possible meanings of accurate[^].
modified 8-May-14 2:25am.
|
|
|
|
|
Stefan_Lang wrote: If during a transaction data is lost, then the transaction is not inaccurate, it is erraneous!
The normal procedure when part of a transaction fails is a roll back of the previous parts of the transaction so there is no vestiges of a partially completed transaction corrupting the database.
A transaction should only be committed when all updates complete successfully.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
That is a very good point, actually: a database transaction should either work without errors, or not at all. That said, the OP implies that the 'performant' solution he has in mind would not be 'accurate', i. e. contain errors, i. e. needs to be rolled back, achieving nothing at all! Why again did he ask?
|
|
|
|
|
Stefan_Lang wrote: i. e. needs to be rolled back, achieving nothing at all!
Maybe he is thinking about running seperate updates on individual tables rather than using proper transaction processing. That is only speculation on my part. He may have something totally different in mind.
Stefan_Lang wrote: Why again did he ask?
I don't know. He seems to not like taking the time to insure accuracy of the process. 
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
I call bullshit, I don't know how his job is done, why should I expect him to know mine. The client has the privilege of pay the bill and requesting the solution, the detail are not his concern.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I run into performance issues all the time. These are not easy to fix and sometimes it means looking at your design critically and throw it overboard. That's not something you can sell to customers. When you're lucky it's a matter of adding some indexes to your database, but sometimes you just have to face the fact that further performance optimization is not possible unless you spend days, or even weeks, working on a single issue. For our customers the costs that come with such tasks far outweigh the benefits that come with it (a form might load a few seconds faster).
Accuracy should always be your most important objective. If your results are inaccurate they are useless and if the data is useless performance is not an issue either. Inaccurate data is still inaccurate at the speed of light.
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
1st law of optimization: Don't do it!
2nd law of optimization: If you HAVE TO do, it don't do it yet!
(To me, it sounds as if the 2nd law is not appliccable in your case)
|
|
|
|
|
Accuracy is the only thing that matters until the client starts worrying about performance. In your case that seems to be clearly not the case so why are you worrying about it?
For any algorithm there is a minimum time that it will take, and while you never know what that time is or manage to get particularly close to it, optimisation attempts do often hit a wall where any further increase in performance is not worth the effort. If you've done the quick wins (batching data at an appropriate size, indexing your tables on the right columns, using fast text writing) then you are almost certainly against that wall.
|
|
|
|
|
Probably something you already considered but which can have an enormous impact in loading your data: transactions. Grouping as much data together before committing can increase loading performance to a factor 100 (as usual, experiment with size of transaction for best result in your situation).
Timing of the process is also extremely important: you might experience slow performance due to locking issues.
To me, accuracy seems the most important criterium (inaccurate = wrong).
|
|
|
|
|
You can have it
- Correctly Done
- Quickly Done
- Cheaply Done
Pick no more than 2
I think your client understands this.
To err is human to really mess up you need a computer
|
|
|
|
|
No CP icon for the Revenge of the 5th!?
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Perhaps because we are not in the month of "Revenge" . It actually feels feels more like "Helluary"  .
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
|
Where? I didn't see it!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
