|Sometimes as developers we have to make a stand for quality. Whilst we need to understand the pressures that the business is facing and be sympathetic to its objectives, we also need to ensure that we don't unwittingly hamper those objectives. What I mean by that, is that we can inadvertently do more harm by simply doing what we are told without question, than by making a stand for quality and saying no to something we have been asked to do.
I can remember having a very frank exchange of views with a project manager. I was asked to make a change to an application because it was showing incorrect results on the screen (it was an Android app I was working on at the time). After some investigation, I discovered that the problem lay with the underlying data, and not the application itself. Basically, all the business logic was performed by the back-end system, and the tablet device would just display whatever data it was given. The application contained no business logic whatsoever.
I mentioned to the project manager that the underlying issue was in fact the back-end system sending the wrong information to the device, and that it was this that required fixing. Garbage in, garbage out.
The project manager was adamant that I needed to fix this quickly on the device. I made it clear that the data would be wrong everywhere else this data was used including other applications within the organisation. The project manager refused to budge and the debate could be heard by everyone in the office. Eventually, the IT Director intervened, and thankfully backed me up. A ticket was raised to get the issue fixed by the team responsible for the back-end system.
Had I just rolled over and done what I was told, the defective data that was the cause of the problem would have been fixed in one application, but would have required fixing in all the other applications too. A time consuming and expensive solution to the problem. Fixing it in the one place is clearly quicker and cheaper than fixing it in many different places.
Bear in mind that when I had this discussion, I was still on probation. I won a lot of respect that day, and people knew that I was not a "yes" man and would challenge authority if necessary.
We've all put in those quick fixes when necessary, and that's perfectly fine (within reason). But that quick fix shouldn't negatively impact other applications or areas of the business.
Making a stand for quality is about doing what is right for the business as a whole.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare