"The input data doesnt matter..." Absolutely untrue. In the business world, software developers primary reason for existence is to improve the bottom line. Sur

"The input data doesnt matter..." Absolutely untrue. In the business world, software developers primary reason for existence is to improve the bottom line. Sure, writing good code for existing business processes is the primary route. But due to our nature of not being encased in the traditions of the departments we are creating applications for, and having knowledge and workings with various parts of the organization as a whole, we get to see a lot more of the big picture in minuet detail than almost anyone else in the company. Numerous times have I been in situations where no one stopped to break down the problem before jumping to a solution. I've seen people so fixated on a solution that they cost the company hundreds of thousands of dollars for a problem that upon minimal scrutiny became apparent that it did not apply to our organization (hurray for tax codes.) Users come to us describing a solution to the problem that they are experiencing. We can take their word for it, and hop to on making the solution. But it also presents an opportune moment to get people to wait a second, to look at the business process, and possibly to solve the problem through a minimal change in process as opposed to the creation of a whole new software application. Pushing the issue in such a way takes a fair bit of self confidence and even a touch of ego. Maybe the original poster was a bit over zealous in his questioning of the problem, maybe he could have questioned the problem in a more constructive way. But the fact that he was questioning the problem, IMO, is the sign of a good developer. It is a fine line though. And putting up too much resistance or negativity will quickly get your resume round filed. -Rick