Tyap-bang and in production? Why not
What happens during normal automation? A technical task, functional requirements, architecture, and a lot of other papers are being compiled. It describes all the conditions, restrictions, operation algorithms, depending on the environment, the appearance of forms, data verification, etc. Often, the design and coordination of these papers takes more time than the automation itself.
A project, a schedule, a decomposition of tasks, a certain project manager, or even a few appear. The formalities take the upper hand, i.e. form, not content.
It is clear that in some situations this is the way to act. For example, if an external company is engaged in automation, it will not survive without such papers, since only will chase for the attainment of evading demands. Papers guarantee stability, predictability of payments and delivery of work. But here these pieces of paper guarantee only one thing to the customer - a long, boring project that will not bring any benefit.
In business programming, this approach is not suitable. Let me remind you that business programming is a complex change, simultaneously for processes, motivation, goals, management systems, supported by automation.
For example, you decide to change the process. Not one that affects a thousand people - there is no solution on your knee. The process, for example, concerns five people of one department. All these people, like their leader, are sitting next to you - here they are, at arm's length. And you decided, together with them, to change the process. They sat down, talked, figured, thought, and decided. It took you one day to change the process.
In most cases, after changing the process, you need automation - you need to make changes to the information system. If you say, you need a technical task, a schedule, a project with a manager, a curator and a sponsor, then that's all. On this your changes will end. A long automation project, hung with formalities, will nullify the process change.
What is especially important: changes in processes are experiments. You, even as an experienced business programmer, cannot know for sure whether your change will work or not. The selected method could have performed well in a different process, or even in exactly the same, but in a different company, but in this context it may turn out to be inoperative.
Since this is an experiment, it has time limits - it was invented today, launched tomorrow, we look at the week and make a decision. If all is well, leave. If not, we think further - either we cancel the change, or we refine and improve it.
And what about the automation for this week? If the traditional way is chosen, then in a week you will only have a technical task, and then at best. Accordingly, the implementation of changes will have to be done manually, without automation. Well, if you make such changes that do not require automation - you can check "by eye". And if not?
This is where the principle of fast automation is needed. Actually, its essence lies in the title - changes to the system need to be made quickly, without coordination and requirements, exactly to the extent that is required to test the main hypothesis that you put forward, changing the process.
You do not have to worry much about the interface, validation of the input data, code optimality, data structure, and other pillars of "proper" automation. Your task is to quickly support change automation in the process, to check whether they work or not.
The principle of fast automation is known to all programmers. Only they know it not as a principle, but as a great evil - it is considered that ignoramuses, mediocrity and newcomers are engaged in such automation.
Partly programmers are right. But they have a fundamentally different context. Usually how it is done. There are some “changeers” - business analysts, users and their leaders. They invented something there, and they say - so quickly make me a form / field / window. What, how, why, why - do not explain. More added - quickly come on, felt boots. What remains for the programmer? If there is an opportunity, it will start to covet - to say that it is impossible so that a technical task, a well thought-out architecture, refactoring, etc. are needed. But, usually, there is no possibility of pobukhtet, and the programmer simply does - quickly, “on the knee”, in the mode of extreme programming.
Well, sort of, okay, to hell with him, right? I suggested exactly that - quickly, without problems, just to make it work?
The key moment arises when the “changeers” see the meaninglessness of change. The business programmer simply cancels such changes and asks the programmer to remove the pieces of code that have been inserted. And the “treacher”? Or, more precisely, "grief-treason"?
He will not cancel anything. Just leave as is, and, at best, just continue to make changes. Do you understand? Without canceling the previous ones, will wind down new, more and more.
There is a political moment here, especially if the head of the department came up with the changes. It is extremely important for him not to look stupid, therefore, no matter what nonsense he comes up with, it will not be canceled. Moreover, if you pin it to the wall, it will protect its changes.
Most often it happens that just no one will use the changes. If you are a programmer, then you may be familiar with this situation. They asked, ordered, demanded to make some kind of system, and then they did not use it. It can even be done not “on the knee”, but normally, in compliance with all the requirements and conditions of the “correct” automation, but all the same - they do not use it. Now you know why. And why nobody removes this functionality from the system - now they also know.
This is how the meaningless, patchwork automation puff cakes are made and grow. Programmers chuckle, but do whatever they say. The filth, non-optimality, the curve structure and architecture grow like a snowball. And the further, the more difficult it will be to stop this process and reverse it.
Another problem is the senselessness of the proposed changes in general.
In business programming, any change has a goal that all participants understand. The process should become faster, or more reliable, or more controlled. Therefore, it is always clear how the purpose of changes, and the criteria for evaluating their effectiveness.
But when changes are made “just like that,” or “so that it is more convenient for me,” or “well, that's just as right!”, The result cannot be assessed. Therefore, changes, no matter how meaningless they are, remain to live - both in the process and in automation.
Now you understand what the problem is - the gap between process change and automation. When some people come up with changes in the process, and then set tasks to automate other people, without explaining the meaning and essence, it turns out to be an ordinary mess that does not benefit anyone.
According to the standards of business programming, work goes on as a team - there are people from processes and people from automation. Even better, when this work is managed by one person - a business programmer. Even better, when he does the automation himself.
In this case, the life cycle of temporary changes is understandable and manageable - why they are made, when they start, and, most importantly, when and under what conditions they end.
Suppose the changes were wrong - this is normal, there is nothing wrong with that. Then programmers have an unusual job - to delete changes in the system. Of course, they sometimes do this kind of work themselves — refactoring, for example. But in the case of business programming, such work must be done periodically.
And if the changes were correct? Then all the skills of “correct” automation come into play, which programmers are so proud of. It is necessary to estimate the architecture, data structure, algorithms, validation of the entered data, interface, etc. But what is the difference, see?
The difference in the form of the problem. Usually this is a technical task, that is, a certain piece of paper. In our case, the task is a prototype. Worker who showed his usefulness and effectiveness, proven, so to speak, in battle. It is necessary only to bring it to mind. To coordinate and discuss nothing special is necessary - just take it and make the system according to the rules and standards of the environment in which the program is created.
If you practice fast programming all the time, you will quickly acquire the skill of doing it right away so that you can fix it less quickly. Here the “right laziness” of the programmer will play into our hands - he will not solve the same task twice, and he will come up with himself, like a prototype will be done quickly, and turn it into a complete solution with minimal effort. Although, in business programming, of course, there are no complete solutions.
Nowadays, such a practice as prototyping and modeling has become common, when, before starting a large automation project, quickly, with minimal effort, without problems with the interface, create a prototype of the future system. As you understand, this is very similar to the principle of fast automation, although the point, of course, is not how the prototype is created, but how it will adapt to the changing environment.
If prototyping is just a marketing move by an integrator company, and then a big piece of paper will appear, like a technical task, then this is just a trick. It creates the illusion of the customer that "everything will be as I need it," but, alas, it will not be so in life. The prototype will not last long and will disappear into obscurity.
And now you understand why. Automation is almost always a cart, not a horse. The horse is a change of processes, and the cart goes after it. But rides only if attached to the horse.
The horse turned, the cart - after. With a delay, with backlashes and drifts, but turned. And if the horse and the cart live each their own lives, then the cart has to be haughty hapless programmers. A large prototype of a large system created in front of a large automation project is a snapshot, snapshot of a horse harnessed to a cart. Everything is beautiful, everyone is happy, everyone likes it, but a day passes, or a week, or even a month, and the horse throws the cart and goes where it needs to go. A cart - beautiful, elegant, made according to all canons, is left standing alone in the field.
Therefore, you should not get involved in “big” prototyping. As well as the "big" automation. In order to start and execute a large automation project, one must have a hell of an outstanding mind, foresight and incredible talent in management. If these words are about you, then I sincerely congratulate you and wish you every success.
I recommend the rest to use the principle of fast automation.
And I remind you once again: automation goes after changing processes. Not before the change, not instead of the change, not separately from the changes. Changed the process, quickly automated, looked at the result. Good - quickly bring to mind. Not good, throwing away.
A project, a schedule, a decomposition of tasks, a certain project manager, or even a few appear. The formalities take the upper hand, i.e. form, not content.
It is clear that in some situations this is the way to act. For example, if an external company is engaged in automation, it will not survive without such papers, since only will chase for the attainment of evading demands. Papers guarantee stability, predictability of payments and delivery of work. But here these pieces of paper guarantee only one thing to the customer - a long, boring project that will not bring any benefit.
In business programming, this approach is not suitable. Let me remind you that business programming is a complex change, simultaneously for processes, motivation, goals, management systems, supported by automation.
For example, you decide to change the process. Not one that affects a thousand people - there is no solution on your knee. The process, for example, concerns five people of one department. All these people, like their leader, are sitting next to you - here they are, at arm's length. And you decided, together with them, to change the process. They sat down, talked, figured, thought, and decided. It took you one day to change the process.
In most cases, after changing the process, you need automation - you need to make changes to the information system. If you say, you need a technical task, a schedule, a project with a manager, a curator and a sponsor, then that's all. On this your changes will end. A long automation project, hung with formalities, will nullify the process change.
What is especially important: changes in processes are experiments. You, even as an experienced business programmer, cannot know for sure whether your change will work or not. The selected method could have performed well in a different process, or even in exactly the same, but in a different company, but in this context it may turn out to be inoperative.
Since this is an experiment, it has time limits - it was invented today, launched tomorrow, we look at the week and make a decision. If all is well, leave. If not, we think further - either we cancel the change, or we refine and improve it.
And what about the automation for this week? If the traditional way is chosen, then in a week you will only have a technical task, and then at best. Accordingly, the implementation of changes will have to be done manually, without automation. Well, if you make such changes that do not require automation - you can check "by eye". And if not?
This is where the principle of fast automation is needed. Actually, its essence lies in the title - changes to the system need to be made quickly, without coordination and requirements, exactly to the extent that is required to test the main hypothesis that you put forward, changing the process.
You do not have to worry much about the interface, validation of the input data, code optimality, data structure, and other pillars of "proper" automation. Your task is to quickly support change automation in the process, to check whether they work or not.
The principle of fast automation is known to all programmers. Only they know it not as a principle, but as a great evil - it is considered that ignoramuses, mediocrity and newcomers are engaged in such automation.
Partly programmers are right. But they have a fundamentally different context. Usually how it is done. There are some “changeers” - business analysts, users and their leaders. They invented something there, and they say - so quickly make me a form / field / window. What, how, why, why - do not explain. More added - quickly come on, felt boots. What remains for the programmer? If there is an opportunity, it will start to covet - to say that it is impossible so that a technical task, a well thought-out architecture, refactoring, etc. are needed. But, usually, there is no possibility of pobukhtet, and the programmer simply does - quickly, “on the knee”, in the mode of extreme programming.
Well, sort of, okay, to hell with him, right? I suggested exactly that - quickly, without problems, just to make it work?
The key moment arises when the “changeers” see the meaninglessness of change. The business programmer simply cancels such changes and asks the programmer to remove the pieces of code that have been inserted. And the “treacher”? Or, more precisely, "grief-treason"?
He will not cancel anything. Just leave as is, and, at best, just continue to make changes. Do you understand? Without canceling the previous ones, will wind down new, more and more.
There is a political moment here, especially if the head of the department came up with the changes. It is extremely important for him not to look stupid, therefore, no matter what nonsense he comes up with, it will not be canceled. Moreover, if you pin it to the wall, it will protect its changes.
Most often it happens that just no one will use the changes. If you are a programmer, then you may be familiar with this situation. They asked, ordered, demanded to make some kind of system, and then they did not use it. It can even be done not “on the knee”, but normally, in compliance with all the requirements and conditions of the “correct” automation, but all the same - they do not use it. Now you know why. And why nobody removes this functionality from the system - now they also know.
This is how the meaningless, patchwork automation puff cakes are made and grow. Programmers chuckle, but do whatever they say. The filth, non-optimality, the curve structure and architecture grow like a snowball. And the further, the more difficult it will be to stop this process and reverse it.
Another problem is the senselessness of the proposed changes in general.
In business programming, any change has a goal that all participants understand. The process should become faster, or more reliable, or more controlled. Therefore, it is always clear how the purpose of changes, and the criteria for evaluating their effectiveness.
But when changes are made “just like that,” or “so that it is more convenient for me,” or “well, that's just as right!”, The result cannot be assessed. Therefore, changes, no matter how meaningless they are, remain to live - both in the process and in automation.
Now you understand what the problem is - the gap between process change and automation. When some people come up with changes in the process, and then set tasks to automate other people, without explaining the meaning and essence, it turns out to be an ordinary mess that does not benefit anyone.
According to the standards of business programming, work goes on as a team - there are people from processes and people from automation. Even better, when this work is managed by one person - a business programmer. Even better, when he does the automation himself.
In this case, the life cycle of temporary changes is understandable and manageable - why they are made, when they start, and, most importantly, when and under what conditions they end.
Suppose the changes were wrong - this is normal, there is nothing wrong with that. Then programmers have an unusual job - to delete changes in the system. Of course, they sometimes do this kind of work themselves — refactoring, for example. But in the case of business programming, such work must be done periodically.
And if the changes were correct? Then all the skills of “correct” automation come into play, which programmers are so proud of. It is necessary to estimate the architecture, data structure, algorithms, validation of the entered data, interface, etc. But what is the difference, see?
The difference in the form of the problem. Usually this is a technical task, that is, a certain piece of paper. In our case, the task is a prototype. Worker who showed his usefulness and effectiveness, proven, so to speak, in battle. It is necessary only to bring it to mind. To coordinate and discuss nothing special is necessary - just take it and make the system according to the rules and standards of the environment in which the program is created.
If you practice fast programming all the time, you will quickly acquire the skill of doing it right away so that you can fix it less quickly. Here the “right laziness” of the programmer will play into our hands - he will not solve the same task twice, and he will come up with himself, like a prototype will be done quickly, and turn it into a complete solution with minimal effort. Although, in business programming, of course, there are no complete solutions.
Nowadays, such a practice as prototyping and modeling has become common, when, before starting a large automation project, quickly, with minimal effort, without problems with the interface, create a prototype of the future system. As you understand, this is very similar to the principle of fast automation, although the point, of course, is not how the prototype is created, but how it will adapt to the changing environment.
If prototyping is just a marketing move by an integrator company, and then a big piece of paper will appear, like a technical task, then this is just a trick. It creates the illusion of the customer that "everything will be as I need it," but, alas, it will not be so in life. The prototype will not last long and will disappear into obscurity.
And now you understand why. Automation is almost always a cart, not a horse. The horse is a change of processes, and the cart goes after it. But rides only if attached to the horse.
The horse turned, the cart - after. With a delay, with backlashes and drifts, but turned. And if the horse and the cart live each their own lives, then the cart has to be haughty hapless programmers. A large prototype of a large system created in front of a large automation project is a snapshot, snapshot of a horse harnessed to a cart. Everything is beautiful, everyone is happy, everyone likes it, but a day passes, or a week, or even a month, and the horse throws the cart and goes where it needs to go. A cart - beautiful, elegant, made according to all canons, is left standing alone in the field.
Therefore, you should not get involved in “big” prototyping. As well as the "big" automation. In order to start and execute a large automation project, one must have a hell of an outstanding mind, foresight and incredible talent in management. If these words are about you, then I sincerely congratulate you and wish you every success.
I recommend the rest to use the principle of fast automation.
And I remind you once again: automation goes after changing processes. Not before the change, not instead of the change, not separately from the changes. Changed the process, quickly automated, looked at the result. Good - quickly bring to mind. Not good, throwing away.