Job Safety Driven Development
While supporters of modern flexible development methodologies invent new and new practices, their opponents also do not stand still. Against the background of various XDDs (FDD - Feature Driven Development, TDD - Test Driven Development, BDD - Behavior Driven Development, ATDD - Acceptance Test Driven Development), they formulated their methodology - JSDD (Job Safety Driven Development). Who are interested in the details, welcome under cat.
')
Any methodology should be based on certain principles and values. Further, concrete practices are obtained from them, and only then tools for effective adherence to the practices. Let's start with the principles and begin ...
The most important principle of JSDD is stable operation and a reliable source of food for the developer. In our unstable time, technologies are developing very quickly and the developer risks remaining behind, losing momentum and lagging behind the market. But many developers have families that need to be fed. Someone already feels the onset of the age barrier, after which companies are reluctant to hire the once promising specialist.
But also the Agile approach from all sides only aggravates the situation. It is necessary to be sociable, social and progressive, to introduce new practices and approaches. What if it doesn't work out? What if you can no longer be a high-level professional compared to the rest? These questions generate fear and anxiety, being the impetus for concrete actions.
Proponents of JSDD are trying to exert maximum efforts so that the stability of their situation could not shake anything.
The following are practices that help JSDD followers achieve their goals.
Non-transparent planning - task scheduling should be as short as possible. All details and discussions are postponed for later, in personal communication. Session design is not conducted at all, it is believed that a professional will be able to come up with the most appropriate implementation for the task, based on business requirements. This practice helps to collect domain knowledge about the product, architecture and design exclusively in the heads of developers. In this case, none of them will have knowledge of foreign modules, and this makes them difficult to replace on the project.
Anti - refactoring - the most important task is to work the code, not its clarity and simplicity. Therefore, as soon as the solution begins to work, the developer must proceed to the next task. This practice should provide an opportunity to understand the code only to the author himself, which greatly reduces the likelihood of his dismissal.
Frame conjecture - you should not use popular frameworks and libraries, it is much better to write your solution for specific tasks. After all, then it is necessary to maintain the product and perhaps for this role, new, cheaper developers will be needed. It is much easier to find a developer in the market with knowledge of popular frameworks than those who are able to deal with self-written ones. And this means that you are permanently provided with work.
Decoupling decisions - architectural decisions that are made on a project should be as changeable as possible. They have to solve strictly current tasks and not a step more. Any changes in the future should be expensive and it should be extremely difficult to make them without the participation of the author. This practice is perfectly masked by the Agile practice of "evolving architecture" and the rejection of the BDUP (Big Design Up Front). And this means that it is easy to implement even when using the “Agile approaches”.
Refusal to test the code - we are professionals and so we write working code. Nobody gives time for tests, the customer will not pay for them and there are testers for testing. These arguments and confidence in your own opinion will easily convince everyone else that you are right. The refusal of testing at the level of modules and their integration allows you to destroy that already fragile bridge that could help to understand the existing code and make changes to it by other developers. Now you certainly can not do without you!
Individual work - there is no time to sit and work in pairs or organize other group activities. It is necessary to quickly make a working code, we are paid for it. This practice allows you to not share your knowledge and skills with others, which gives you the opportunity to remain at the same level with your teammates. Also, the practice contributes to the narrow profile of knowledge in different areas of the product and thereby strengthens your confidence in the future.
Cycling - as soon as you see the opportunity to realize something from scratch somewhere, without using well-known tools and approaches, you should not miss this opportunity. In addition to the benefits of similar practice of frame-building hatred, you significantly stretch the terms of the project. And the longer the project lasts, the more influence your rest practices have, making your dismissal almost a disaster for the project.
Rate of fire - in order for your arguments to be more compelling and other practices implemented faster, you should be able to quickly accomplish the tasks you have set. Naturally without problems on the quality of the code and other activities. Turn on the stream of consciousness and go! Then you will have the opportunity to blame the rest for sluggishness and resist the introduction of new practices and approaches, and therefore will save your stable position from encroachment.
There are many other interesting practices in this wonderful methodology. You must have come across many of them in life and I will be glad to see their description in the comments. I also specifically missed the tools section to let your imagination work ...
If you are one of the supporters of Agile, then you should be prepared to combat alternative methodologies, one of which is presented in the article. In your arsenal should be static code analysis, code review, pair programming, simple design and architecture, a solid understanding of the processes and principles of agile development. Only in this case you will be able to calculate the adept JSDD, and then either to attract him to your side or be able to get rid of him. Otherwise, your Agile deployment may stop before it starts ...
What is Job Safety Driven Development?
')
Any methodology should be based on certain principles and values. Further, concrete practices are obtained from them, and only then tools for effective adherence to the practices. Let's start with the principles and begin ...
The most important principle of JSDD is stable operation and a reliable source of food for the developer. In our unstable time, technologies are developing very quickly and the developer risks remaining behind, losing momentum and lagging behind the market. But many developers have families that need to be fed. Someone already feels the onset of the age barrier, after which companies are reluctant to hire the once promising specialist.
But also the Agile approach from all sides only aggravates the situation. It is necessary to be sociable, social and progressive, to introduce new practices and approaches. What if it doesn't work out? What if you can no longer be a high-level professional compared to the rest? These questions generate fear and anxiety, being the impetus for concrete actions.
Proponents of JSDD are trying to exert maximum efforts so that the stability of their situation could not shake anything.
Job Safety Driven Development Practices
The following are practices that help JSDD followers achieve their goals.
Non-transparent planning - task scheduling should be as short as possible. All details and discussions are postponed for later, in personal communication. Session design is not conducted at all, it is believed that a professional will be able to come up with the most appropriate implementation for the task, based on business requirements. This practice helps to collect domain knowledge about the product, architecture and design exclusively in the heads of developers. In this case, none of them will have knowledge of foreign modules, and this makes them difficult to replace on the project.
Anti - refactoring - the most important task is to work the code, not its clarity and simplicity. Therefore, as soon as the solution begins to work, the developer must proceed to the next task. This practice should provide an opportunity to understand the code only to the author himself, which greatly reduces the likelihood of his dismissal.
Frame conjecture - you should not use popular frameworks and libraries, it is much better to write your solution for specific tasks. After all, then it is necessary to maintain the product and perhaps for this role, new, cheaper developers will be needed. It is much easier to find a developer in the market with knowledge of popular frameworks than those who are able to deal with self-written ones. And this means that you are permanently provided with work.
Decoupling decisions - architectural decisions that are made on a project should be as changeable as possible. They have to solve strictly current tasks and not a step more. Any changes in the future should be expensive and it should be extremely difficult to make them without the participation of the author. This practice is perfectly masked by the Agile practice of "evolving architecture" and the rejection of the BDUP (Big Design Up Front). And this means that it is easy to implement even when using the “Agile approaches”.
Refusal to test the code - we are professionals and so we write working code. Nobody gives time for tests, the customer will not pay for them and there are testers for testing. These arguments and confidence in your own opinion will easily convince everyone else that you are right. The refusal of testing at the level of modules and their integration allows you to destroy that already fragile bridge that could help to understand the existing code and make changes to it by other developers. Now you certainly can not do without you!
Individual work - there is no time to sit and work in pairs or organize other group activities. It is necessary to quickly make a working code, we are paid for it. This practice allows you to not share your knowledge and skills with others, which gives you the opportunity to remain at the same level with your teammates. Also, the practice contributes to the narrow profile of knowledge in different areas of the product and thereby strengthens your confidence in the future.
Cycling - as soon as you see the opportunity to realize something from scratch somewhere, without using well-known tools and approaches, you should not miss this opportunity. In addition to the benefits of similar practice of frame-building hatred, you significantly stretch the terms of the project. And the longer the project lasts, the more influence your rest practices have, making your dismissal almost a disaster for the project.
Rate of fire - in order for your arguments to be more compelling and other practices implemented faster, you should be able to quickly accomplish the tasks you have set. Naturally without problems on the quality of the code and other activities. Turn on the stream of consciousness and go! Then you will have the opportunity to blame the rest for sluggishness and resist the introduction of new practices and approaches, and therefore will save your stable position from encroachment.
There are many other interesting practices in this wonderful methodology. You must have come across many of them in life and I will be glad to see their description in the comments. I also specifically missed the tools section to let your imagination work ...
Conclusion
If you are one of the supporters of Agile, then you should be prepared to combat alternative methodologies, one of which is presented in the article. In your arsenal should be static code analysis, code review, pair programming, simple design and architecture, a solid understanding of the processes and principles of agile development. Only in this case you will be able to calculate the adept JSDD, and then either to attract him to your side or be able to get rid of him. Otherwise, your Agile deployment may stop before it starts ...
Source: https://habr.com/ru/post/169017/
All Articles