Wednesday, December 10, 2008

Resolution by Accident

I develop internal software applications for a mid-sized company. For the most part our applications help to streamline day to day processes and are really just data entry front ends. I was once asked in an interview: "How do you know when you are finished?"

I know the anser was not: "Once every requirement has been fulfilled". I would assume the answer should include something on Performance, Reliability, Usability, Scalability. But even those areas themselves do not have a definitive end point. If I am ever asked this question again I think my response would be: "When the customer is satisfied over a determined period of time."

While that might mark completion, is that success? I guess to even a more abstract problem, "Can an application be successful even if the project is a failure?"

"Resolution be accident" seems to be common method of software development. By this method success is measured by the random forces of the universe colliding at a point where the application can be pushed out. But the underlying project is a failure. Why?

Such a project is a failure because it is unable to be reproduced. If you stumble upon a solution without understanding, there is a good change that you will run into the same issue down the road. Havign a 'fix' for the issue is an inadequate way to program since the underlying issue is never being dealt with.

No comments: