To view parent comment, click here.
To read all comments associated with this story, please click here.
That would in fact be one way.
Though experience shows that once a hack is in it takes pretty long to get it removed --> look at the hacks in KDE 3.
Especially if people denied there was a bug at all in the beginning. They would simply say that the hack "fixed" the bug and the bug was in your application so no need to change anything in their code.
"As long as it 'works' there is no reason to change it." (not a quote! rather a way of thinking)
True. There are still "hacks" in code I've written from about 8 years ago in our applications. And I knew I would get that comment.
On the other hand, while I appreciate and respect the "do the right thing" attitude, I also think that the user should not suffer if something can be done about it. And I use the word "suffer" lightly as I think we have all become somewhat spoiled by advancements in UI software.





Member since:
2005-07-06
Why not meet halfway by implementing some "cheap hack" to speed it up, one that can be pulled when the underlying infrastructure improves? It could be part of the regression testing with each build/release cycle to run without the hack and with the hack to check for the performance levels.