In my admittedly young career I've found myself writing code to support quirky business rules and processes. Inevitably these changes were always in some massively difficult code base and caused many issues. My question has a couple of parts:
While software is a tool for businesses to make their lives easier, at what point do we as developers suggest a change in business process rather than in the software as the "magic bullet" to solve a particular problem.
How do we as developers evangelize a certain level of reverence for the software as well as the difficulty involved in making changes simply to support the quirks of the business?
I understand that these changes in business processes promote our industry, but in an analogy my father would understand: Which is easier, to melt down a hammer to forge a screwdriver to drive screws or to simply use nails since your hammer is already awesome...?
You can look at
Seven Habits of Highly Effective People
, as there is the sense that you need to develop a sphere of influence large enough to try to change business processes.
Your best bet is to show that you are very competent at your job, and work on developing relationships with people on the business side, so that you can feel comfortable sitting down outside of work to discuss the business process in question.
This is a slow process, but if you try to rush too fast the business will push back, and squash you like a bug. If you read
The Age of Heretics
for example, you will see examples of companies that were too successful in making changes, and the corporation destroyed them.
At the moment your best bet is to make changes, as you can, to have the software be more adaptable, so that if the process changes you can easily adapt to the new rules.