🍞 📜 🤝 How to avoid programming outrage? Integrator Tips 👧🏼 🐿️ 🐛

In a previous article about the problems of introducing ERP in industrial enterprises as a case study, one of the points was brought to the "Programmatic chaos."

We have a customer whose employees now, sending us dubious requirements, specify whether this is a programmatic lawlessness. And some do not specify, but create it.

The topic is relevant, and I decided to write a separate article about it.

What is it?

What kind of paintings does your imagination paint when you hear the phrase “programmatic lawlessness”?

A bearded man with a thoughtful clever gaze hits the tearful chief accountant with a volume of Knut, saying: “Kopek, you say you didn’t agree on the invoice? The consignee does not fit in the cell? Now we will stamp it with a book and everything will fit! ”

, - . , : « 10 , ? ? , ?» — , - … : « – : , . : … …»

This phenomenon is less colorful than you can imagine, but more terrible. In the end, the chief accountant can calm down, wipe away tears and send to a psychologist, the masters can be untied from a chair and sent to work. But the posting curves in InventTrans and broken due to miscalculations in the architecture of the solution and unnecessary improvements, the psychologist will not correct the summary planning.

Programmatic lawlessness is a situation when as a result of programming, the purpose of which was to solve certain problems of a business, other, often more serious, problems for business are created.

Let me give you a couple of examples:

, , . - , .
. , , «» . . , , .

I wanted to name the article “Programmer's chaos. Crying integrator ”, but realized that no one cares about our tears. But tips on how to avoid such situations may come in handy.

I will try to outline the boundaries of my recommendations in advance - we are talking about:

programmers who are involved in the implementation or maintenance of ERP-systems. I think that they have slightly different requirements than, for example, the developers of a new product or technology;
programmers who work with the client. Integrator developers are less prone to "outrage."

So what are the causes of this phenomenon and what can be done about it?

Unwillingness or inability to look at the essence of the process

I often see this with novice analysts and programmers. They simply answer the question that the customer asked them. They don’t think about it - why did he ask about it, does he really need it? Over time, this passes, but at first you have to catch and explain.

“And can you increase the number of decimal places for this coefficient to 4?” - "Of course". But nothing that this coefficient is used to index the parameter, which has an accuracy of 1 decimal place, and the values do not exceed 50? All coefficient accuracy will go into rounding. So maybe it's better not to do this?

“Add a new field of this type to the nomenclature reference” - “Good. The complexity of 15 minutes. " So, why do you need this field in the nomenclatures? This is a characteristic that varies from party to party. Perhaps it is better to add this field to the directory of parties?

A developer in ERP does not have to be just an implementer of the changes that users make. He needs to understand the logic of the system and act as its protector against all nonsense. To do this, it would be nice to understand business processes at least at the level of common sense and be able to ask uncomfortable questions to users.

Therefore, if one of the users has never resorted to you with complaints about the impudence of a programmer who refused to implement his Wishlist, this developer should take a closer look. Perhaps he just does what they say. And this rarely ends with something good.

Lack of stamina in the fight against the desire to leave everything the old way

This is the case when programmer mess is not created by developers, but with their connivance.

Any serious product carries not only a set of certain functions, but also an ideology, best practices. And people want to work the old way. And they put pressure on the programmer to provide him this opportunity. And if he could not prove that this should not be done, then everything could end sadly.

, , , . . : « 1974 , , ». , , , , . « , , – ». , , , . , . , , . : , , - , . : «».

What can be done with this? To begin with, do not subordinate the programmer to economic services. He must work in another unit and have some independence from the management of departments whose work is automated.

It would be nice to add one link to this chain: any serious improvements should be approved not only by the contractor, but also by someone who understands the business of the enterprise as a whole and has power. Such a person can definitely say: "No."

The habit of solving all problems by programming

A love of automation leads to progress, but sometimes harms. I have witnessed how, instead of instructing people to manually enter data into the system, this input was automated. Automated, forgetting some details or features that would have necessarily been noticed, discussed and most likely corrected with manual entry. And so - everyone is sure that there are no errors, but after a while the consequences come out en masse, which is already much more difficult to fix than the root cause.

, , . , , , . . , . , , . : .

Therefore, when a programmer is asked to write a script to fix 200 errors that arose due to the fact that users did not work according to instructions, he should not rush headlong into the keyboard. We need to estimate how much time it takes to fix one error manually, and if the time to manually fix all errors does not exceed the complexity of writing a script by an order of magnitude, get users to fix these errors on their own: there is more chance that they will work according to instructions in the future. This should be introduced as a rule, hung on the wall near the programmer so that he can poke all visitors into this piece of paper.

In addition, for some reason we think that if people are freed from routine work due to automation, they will do something useful: they will begin to offer ideas for improving business processes, optimize reporting, and train less experienced colleagues. But most likely they will simply have more time for tea, smoke breaks and the Internet at work. So is it worth it?

Self confidence

There is a functionality that should not be modified. In Axapt, this is, for example, master planning. In my memory, we touched him only 2 times. And each time it was not embedding in the code, but a kind of “blotch” - functions that were performed before or after the consolidated planning. And even so, I recall these improvements with longing.

There are less obvious places where you should not climb. And a great way to distinguish an experienced programmer from a beginner is to offer to refine such functionality: an experienced one will be surprised and refuse, may advise to optimize the business process, and the beginner will say: “Come on.”

Here one thing can be advised: to hire people with experience who, already from other customers or on other projects, got all the bumps that, in principle, could be filled.

Lack of development regulations

When we take a project for support, one of the first documents that we ask the customer is the development regulations that describe the development environment, rules for naming objects, prohibitions and restrictions. The strangest thing is that sometimes it does not happen. And this is a sure sign - there will be trash in the code: starting from the classic lack of comments and ending with situations when specific values from directories for different branches of the algorithm were written directly in the text. And trash in the code is the first step to problems with the business.

Therefore, do not talk about the fact that “programming is an art. It is not regulated "," but what about agile? " and that’s all. If you are developing, then there should be a regulation. And this is not 3 points:

development is carried out on the dev application;
testing is carried out on the test application;
The code must have comments.

This should be a full-fledged document with ten pages with sections:

Requirements for development applications.
Requirements for writing the statement of the problem.
Requirements for writing code.
Testing requirements.
Migration requirements between applications.

As a rule, the entire hardcode is done according to the principle “Let's do it fast, and then do it normally”. It is done quickly, and then it is forgotten ... And when there is a signed document that states that this cannot be done, you can always poke into it and tell the user: “It won’t work out quickly, I’m forbidden to work like that. Sorry, Alevtina Svetozarovna, I’d be glad to comment on all the checks right on the worker, but then they will fire me. ”

Loneliness and lack of control

A lonely programmer is evil. There should always be someone who says: "Well, what have you, a fool, done?" - Otherwise, the developer relaxes, forget about the rules, forget about responsibility. This is where the hardcode begins, dubious architectural decisions, mistakes affecting the business.

In a clever way, this is called a “code review” and this is something that should always go along with development regulations. After each revision, before testing it, there should be a check for compliance of the code with the development regulations and best practices. A code review will allow:

control the quality of development;
train less experienced programmers.

Therefore, developers should be at least 3 pieces (two will always agree that you can do nothing, a third party to the system will significantly reduce the likelihood of collusion). And they must work according to internal regulations, one of the key points of which is the mandatory code review.

Conclusion

Thus, in order to reduce the likelihood of "programmatic lawlessness," you need to form your own internal development department according to the following rules:

This must be a team of at least 3 people.
At least one of this team should have experience in implementing or maintaining an ERP system, it should be his n-th project, where n> 3.
The development department should ideally report directly to the CEO.
End users must sometimes complain that programmers refuse to implement some of their requirements.
Even for such a small department, regulations must be developed, for the violation of which must be punished.

Naturally, this is my vision. It can be argued, for each of these points even I can give counterexamples from my experience when the requirement was not met, but everything was perfect. But these recommendations can be used as a starting point for the formation of their principles of combating programmatic lawlessness.

How to avoid programming outrage? Integrator Tips