I like the article, especialy the part about saying NO. While I don't like the rigid attitudes it is a valuable instrument that usually pays off. It helps to think twice (or even three times) and do some verifying before going for a "solution".

From the angle of a developer I have to deal with such situations quite often and wihout the backing of management supported established procedures. I learned to say NO as a way so get people to think before they leap and assign myself a part of the design process as a final sanity/quality check before implementing "solutions". Often I end up with a better alternative on my own once the goal of the change is well expressed (this as I see it, is my real job too).

In practice functional oversight or sudden new requirements for a running application quickly translate in cases that need to be implemented fast. Decissions are made by people without any knowledge of application development nor full awareness of the application and existing data in particular.

If I would simply follow every request, things would turn into an unmanageable mess quite rapidly. Individuals working for customers don't check existing data, designs or the scope of their application, they just want their problems solved. Very often there are no procedures guiding this process, a problem hits one user and suddenly a new project/change request arrises affecting more then initially realised.

Few people are asking questions like:

1. Does this function really need to be in this (part of the) application (scope issue)?

2. Is it worth spending N weeks developing, for just one person while the functionallity is available somewhere else and accessible already?

3. What other effects are there on the existing design?

4. Do we need to take a step back and redesign part of the application to make it a consistent functional whole again?

One could argue that I just have to do what people tell me to, as that is my role (read the previous article). But that is what I ranted against for a reason...with deteriorating quality of design and code due to blind alterations without understanding of the data or scope of the application, my job would become impossible over time. Every additional change would take more time and increase the risk of side effects (resulting in more issues, cycle starts...).

Just because a customer doesn't manage his IT and/or organisation well, doesn't mean we have to follow in that practice every time! A requirement for this attitude is however that you gained some experience and know the relevant application and existing data very well.

For those not yet at that point, it stil pays off to ask questions and verify what people tell you before proceeding. If you do not you might end up having to repair something you did not fully comprehended in the first place and that means the problem got bigger instead of getting solved.

Realize people often only have experience with part of an application. Ask 5 people working with the same application in different roles what the application does and its purpose.

You likely get 5 different answers, so be paranoid!