Programmers learn to deny

How to get this important project back on the road-a few weeks ago, we were scheduled to finish. Are you familiar with these scenes? What I want to say is that the project is a common thing in any industry. But the software industry seems to be doing so often.

Why do we come to this? This should start with the place where our dreams began. At the beginning, everyone is the most powerful. A beautiful idea, this time we vowed never to repeat the mistakes we made last time, not to make the last mistake. This time we told ourselves that the plan would be "right" and that it would not be easy and would not change in the middle. Sometimes we feel that our dreams are moving in the right direction, the design is very successful, everyone is optimistic and the outside comments are good. Then the nightmare began to come, as all kinds of blows began to appear.

The easiest part of the system consumes everyone's time. A small omission could mean that a series of simple assumptions were no longer tenable. False assumptions produce cascading effects, causing system design to fall into doomed. The design needs to be modified to correct these problems. Hopefully, we can still get the project back on track with enough sleepless nights and weekend overtime.

The landmark prototype was finally born, and everyone was confident because the prototype was performing very well. Outsiders do not know how many all-night efforts in exchange for this. Soon, "small demand" began to appear. The usual rhetoric is "what's so hard about this?" Or "It's really simple!" In the beginning, the more classic words are "if we can ... That would be amazing. " By exchanging views, these new small feature features not only look "simple", but are actually available. Of course, you won't say no, but the tragedy of history is about to repeat itself.

Now that you and your team are finally back in the real world, look at these new requirements again. After a close look at these seemingly "very simple features", it suddenly dawned on them that they were not as simple as they initially sounded. But it's too late, you've promised these new changes.

Bang！ "Your email informs you that you have a new email, which is really adding insult to the sale. Sales talk to customers about these "simple" new features, and customers come up with more "simpler" features they want. Sales photos are all in order because these new requirements sound simpler than those at first.

Programmers, please dare to say no

Stop it.

During the 80 and 90 there was a very popular campaign slogan: "Ethically Dour No", which is used to promote children to stay away from drugs. Whether you remember the campaign or not, the message it conveys is very powerful. Similarly, we should use the same tone to confront the problems we encounter.

I am not, of course, tempted to resist any change in demand. From my point of view, any additions that need to be coded for development will be separated by a red line. However, modifications such as interface or front-end content are not included.

Any additional requirements must be determined by a sufficient amount of additional time before acceptance. The default response to new requirements in the heart should be "ethically dour no". Of course, there is no need to expose the reaction on the surface, and the effect can be achieved with appropriate diplomatic means. At the start of the project, any "requirements change" that was initially not planned should be carefully weighed. Adhere to this principle for any new feature features that are added later. With this principle you can easily say "no". Because this is a ruler, everyone understands that the new features will take extra time to add. Put this pressure on the client and the boss, either delaying the completion date or giving up another function to replace it.

Conclusion

There are various reasons why a software project cannot be completed on time. Projects are progressing slowly, and programmers continue to work under high pressure, making it more difficult to anticipate project development time. Programmers should be prepared, and the new demand will certainly arise. Put "ethically dour no" in mind, how much can prevent your mouth to say "line" habit. It's dangerous to play with a gun and a safety device for the gun, at least to prevent hurting your feet.

[Original English: ethically dour No]