Optimistic programmers

We, programmers, are optimists. This is manifested in the entire software development cycle from estimating terms to writing code and implementation. As my practice shows, in software development, Murphy's laws work in 100% of cases. Despite this, I repeatedly encounter "optimistic programmers."

Top "optimistic" assumptions:

We can still release this week on Friday at 5:48 pm, although there are bugs in the code

No you can not. In addition to correcting errors, you need:

1. Use / run this code (you do not develop in the branch from which you are published in production, right?)
2. Publish code on a test bench and test, including regression
3. Check configuration, database migration
4. Save production
5. Post changes
6. Test production
7. Roll back if something went wrong

Even if everything happens in automatic mode, you can barely have enough 12 minutes before the end of the working day to finish. Typically, such calculations are made in a hurry and end with stupid blunders on production, reworking at night and / or on weekends, rollbacks to the previous release and transfer calculations, or a combination of these items.

The decision on the release / calculation can be made only after the code is written and tested. Know exactly how long it takes display, backup and rollback to the previous version in case of epic file. Always lay the most pessimistic option: you give out and you, for one reason or another, will have to roll back. On the current project, we have automated all calculations and backups. It takes 10 minutes to lay out, to recover from backup: 10 minutes, to a minimum smook-testing: 2 hours. So, for production calculations, I’m laying 3 hours of time.
')

It will take three days. And in a day you can? Well, maybe I can

Do not go on about the managers. The manager, even with the technical background, does not know all the ins and outs. What may seem simple and fast manager, in fact, may take much more time. The manager always evaluates only the complexity of the implementation of a new feature. Your task is to insist on the fact that you need time to refactor, test, display. Going over the management, time after time you will postpone the technical debt until it has accumulated so much that you will not know which side to approach to refactoring. Requirements change, no one can immediately write the perfect code, no more and no less than required. If you feel that the crutches in this place come back around for days and weeks in the future, it is better to spend the extra few hours now and pass the feature a little later. Explain it to the manager in his language: now this refactoring will cost us 8 hours. And if we insert crutches, then in a month our technical debt will cost 56 hours. Managers usually count well, and easily multiply the number of hours for your rate. Remember that no one except you knows the code better, so you know better how to do better from the technical side. Details about the pressure of management can be found in the article “ How two weeks ?! ".

Oh, this is a very stupid bug, now I will quickly fix it and it will work. Test write to anything

No, a bug is a reason to write a unit test. If it appeared, it means that you missed this behavior and you have a hole in the "code cover". Found a bug? Add a unit test / integration test / test case to the test plan. This will relieve from "boomerangs" - bugs, returning again and again.

This is a very simple feature, you can not even add it to the task tracker. I will do so, the requirements are clear

No, the requirements are certainly more complicated than it seems at first glance. It is possible that the new requirements will conflict with the existing behavior of the system. If you do not add a task to the tracker, then in any disputable situation prove to be extreme. The worst option is a verbal agreement. People have a very short memory. All tasks should be set only in writing. I wrote about requirements management in detail in the article “ Specification By Example - BDD for Pragmatists ”.

It is possible and not to publish this change on the test stand, it works great on my local machine. Running tests is also a waste of time, but everything is so simple

No, always test, primarily on the "target" environment / gland. Any emulation is just a model. In real conditions, unforeseen circumstances may emerge: another OS version, other rights, another processor power, RAM size, other open ports. Anything.

This check here is useless. No one would ever think to use the program in this way.

There are no extra checks. It is for such cases that exceptions have been invented. You do not support any behavior / script? Throw NotSupportedException . Everything will be very clear. But worse than a NullReferenceException is difficult to imagine something. It does not give any information to the person supporting your code. He does not have to rummage through stack-tracing and look for low-level errors. Always handle low-level errors and use your own clear exceptions. In .NET, an exception has an InnerException property that will help to keep information about a lower level problem. Not bad about exception handling in .NET is written in the article " Safe work with exceptions in C # ".

This error can be processed and pretend that nothing has happened.

Empty try-catch blocks usually appear when reliability and fault tolerance appear in software requirements. This behavior is equivalent to sweeping debris under the carpet, so that no one sees. If you need fault tolerance - provide emergency system restart. The first thing you need to do is to log the exception and notify the developers. You can send letters to developers in case of errors, you can use instant messengers, mass options. The worst thing you can do is ignore the error, because you don’t know what the consequences are. The word "exception" was chosen for a reason. This emphasizes that the behavior is not planned and is not normal.

This is not a bug, this is a feature, on the database test is empty, on production everything will be fine

No and no again. If the data must be in the database, then include them in the calculation. Changed the configuration? Add transformation of the config. If a case is not verified, there is an error in 9 out of 10 cases. At such a booth it is impossible to hold a demonstration. “There is a mistake here, but it won't be in the battle” - it sounds awful. If for some reason it is impossible to set up a test stand that is identical to the production (financial operations, paid accounts, security settings, etc.), use stubs, emulators and similar test accounts. Bring your test bench to production as far as possible.

I fixed / updated, it seems to work

No "like". If there was an error of any kind on the stand, check that after your fix / update nothing else broke. Get the minimum check-list of the application performance check after the update, for example: login, buy something to see a couple of pages. This will save testers and your fellow developers from repeated appeals to you: “listen, in the goods, and in the news, the old error disappeared, but a new one appeared.” Take this test as a matter of course, as an element of personal hygiene. You do not think why brush your teeth and wash your face every day.

Dunno what the problem was, I restarted, it worked.

No “dunno. You must accurately understand and prevent any possibility of a program crash. If you solve the problem by restarting, you are not dealing with a cause, but with a consequence. This problem is guaranteed to be repeated at the most inopportune moment. You will be awakened in the middle of the night, so that you once again restart the application, because it has “collapsed”. Always solve the problem completely. Does the application need a regular reboot? Set up an automatic restart, localize the problem, add a task and fix it. Very good about the dangers of "shuffling" is written in the article " What's wrong with the work on the result ."

The implementation of the above recommendations requires self-discipline. Observe them damn difficult, but the laws of Murphy did not let me down even once. Every time I make an exception, something unforeseen, extraordinary and unplanned happens. Every time when it is impossible to hand over the work qualitatively and on time, I get upset, so I try to never deviate from these rules. As a result, I am much more optimistic than before I look at software development in general. I know that there are no “too complex” tasks. There are tasks requiring a lot of time for implementation. I hope that my checklist will be useful to other developers.