Open any downloaded internet black & white image of personal interest using Photoshop, activate the smudge tool and, using your mouse make swirling motions through the picture. Increase the rate at which you swirl until the CPU is no longer able to keep up with the motions of your swirl technique and, to your eye, the smudge cursor appears to be lagging. And finally when you've had enough of this, stop smudge swirling and save the document as a .psd. In a folder you will be able to find at a later time.
Do this in hopes of diminishing real value of returns in the "reputation" standings here at CP in case you feel you're over compensating somehow by checking it periodically.
Having said that, its really difficult (politically) to be as simple as it could... As it seems software development, for the business run by other people (some of whom have never developed any software), is a dependent process... Honestly many times it becomes a matter of daily bread too for many.
I have felt it several times ... The spearheads are mostly dictating this is what they want... without any consideration for simplicity, maintainability, testability and productivity .. Sadly people are mostly jumping with 'Get it done, FAST, with what little we have' ... I have also warned them to stay close of the KISS model .. and they got convinced that the more complex it gets the more better it is .. and then see such projects fall on the face (sometimes breaking all teeth)
Sorry for being a little lengthy .. but the word actually brought in a lot of feelings
Not the people I'm around (including me) Also when I learned the acronym, KISS was a bit more insulting than just calling me silly. I don't have a goal to make things simple, my goals are to make it easy to understand, meet the requirement and my changes don't break anything. A lot of times my goal is to make something more performant. All of that sometimes also leads to making the query simpler to understand as well.
Sometimes Simple just ain't possible. I had this bug on a stored procedure, traced the performance problem to a view, since I didn't have a bug on the view and the logic was gawd-awful, created my own logic in the sproc that transformed the performance from minutes to seconds. My results exactly matched the original result without using the view. Suddenly the performance of old and new sproc matched, but I was getting more results than the original sproc was now getting.
Traced the unchanged sproc back to the now changed view. Someone had used a similar technique I used but their where clause didn't include all the extra data the other included. So did he fix the view to meet new requirements, or screw it up when going to the new process and not matching up the original selection which I had done? I certainly didn't know the real business requirements to say which (or neither) was doing things correctly.
Last Visit: 31-Dec-99 18:00 Last Update: 13-Jul-14 12:10