February 11, 2013 at 16:24Job safety driven development
While supporters of modern agile development methodologies are inventing more and more new practices, their opponents are also not standing 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 cares about the details, welcome to cat.
Any methodology should be based on certain principles and values. Further from them specific practices are obtained, and only then tools for effective adherence to practices. Now let's start with the principles ...
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 runs the risk of being left behind, having missed the moment and lag behind the market. But many developers have families that need to be fed. Someone already feels the onset of an age barrier, after which companies are reluctant to hire a once-promising specialist.
And also the onset of Agile approaches from all sides only aggravates the situation. One must be sociable, social and progressive, introduce new practices and approaches. But what if it doesn’t work out? What if you can no longer be a high-level professional compared to the rest? These questions give rise to fear and anxiety, as an impetus to specific actions.
Supporters of JSDD try to make every effort so that the stability of their position could not shake anything.
The following are practices that help JSDD followers achieve their goals.
Opaque planning - task planning should be as short as possible. All details and discussions are postponed until later, in personal communication. Design sessions are not conducted at all, it is believed that a professional will be able to come up with the most suitable implementation for the task, based on business requirements. This practice helps to collect domain knowledge about the product, architecture and design exclusively in the minds of developers. At the same time, none of them will have knowledge of other people's modules, and this makes them difficult to replace on the project.
Antirefactoring- The most important task is the operability of the code, not its comprehensibility and simplicity. Therefore, as soon as the solution begins to work, the developer must move on 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.
Hateful framework - you should not use popular frameworks and libraries, it is much better to write your solution for specific tasks. After all, then you need to support the product and perhaps for this role you will need new cheaper developers. It’s much easier to find a developer on the market with knowledge of popular frameworks than those who can deal with self-written ones. And this means that you are provided with work for a long time.
Robust solutions- architectural decisions that are made on the project should be as less susceptible to change. They must solve strictly current problems and not one step more. Any changes in the future should be expensive and make them without the participation of the author should be extremely difficult. This practice is perfectly disguised as an Agile practice of "evolving architecture" and the rejection of BDUP (Big Design Up Front). This means that it is easy to implement even with Agile approaches.
Opt out of code testing- We are professionals, and so we write working code. Nobody allocates time for tests, the customer will not pay for them, and there are testers for testing. These arguments and self-confidence will easily convince everyone else that you are right. Failure to test at the module level and their integration allows you to destroy the already fragile bridge that could help figure out the existing code and make changes to it for other developers. Now, without you certainly can not do!
Individual work- there is no time to sit and work in pairs or organize other group activities. We need to make a working code faster, we get paid for it. This practice allows you not to share your knowledge and skills with others, which gives you the opportunity to stay at the same level as your teammates. Also, practice contributes to the narrow profile of knowledge in different areas of the product and thereby strengthens your confidence in the future.
Bicycle construction- as soon as you see the opportunity to implement somewhere from scratch, without using well-known tools and approaches, you should not miss this opportunity. In addition to the benefits of a similar framework of hatred frameworks, you significantly stretch the duration of the project. And the longer the project lasts, the more influence your other 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 must be able to quickly implement the tasks. Naturally without troubles on the quality of the code and other activities. Turn on the stream of consciousness and go! Then you will have the opportunity to reproach the rest with slowness and resist the introduction of new practices and approaches, which means it will protect your stable position from encroachments.
There are many other interesting practices in this wonderful methodology. You probably came 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 give your imagination a try ...
If you are a supporter of Agile, you should be prepared to deal with alternative methodologies, one of which is presented in the article. Your arsenal must include 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 JSDD adept, and then either 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 from them specific practices are obtained, and only then tools for effective adherence to practices. Now let's start with the principles ...
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 runs the risk of being left behind, having missed the moment and lag behind the market. But many developers have families that need to be fed. Someone already feels the onset of an age barrier, after which companies are reluctant to hire a once-promising specialist.
And also the onset of Agile approaches from all sides only aggravates the situation. One must be sociable, social and progressive, introduce new practices and approaches. But what if it doesn’t work out? What if you can no longer be a high-level professional compared to the rest? These questions give rise to fear and anxiety, as an impetus to specific actions.
Supporters of JSDD try to make every effort so that the stability of their position could not shake anything.
Practices Job Safety Driven Development
The following are practices that help JSDD followers achieve their goals.
Opaque planning - task planning should be as short as possible. All details and discussions are postponed until later, in personal communication. Design sessions are not conducted at all, it is believed that a professional will be able to come up with the most suitable implementation for the task, based on business requirements. This practice helps to collect domain knowledge about the product, architecture and design exclusively in the minds of developers. At the same time, none of them will have knowledge of other people's modules, and this makes them difficult to replace on the project.
Antirefactoring- The most important task is the operability of the code, not its comprehensibility and simplicity. Therefore, as soon as the solution begins to work, the developer must move on 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.
Hateful framework - you should not use popular frameworks and libraries, it is much better to write your solution for specific tasks. After all, then you need to support the product and perhaps for this role you will need new cheaper developers. It’s much easier to find a developer on the market with knowledge of popular frameworks than those who can deal with self-written ones. And this means that you are provided with work for a long time.
Robust solutions- architectural decisions that are made on the project should be as less susceptible to change. They must solve strictly current problems and not one step more. Any changes in the future should be expensive and make them without the participation of the author should be extremely difficult. This practice is perfectly disguised as an Agile practice of "evolving architecture" and the rejection of BDUP (Big Design Up Front). This means that it is easy to implement even with Agile approaches.
Opt out of code testing- We are professionals, and so we write working code. Nobody allocates time for tests, the customer will not pay for them, and there are testers for testing. These arguments and self-confidence will easily convince everyone else that you are right. Failure to test at the module level and their integration allows you to destroy the already fragile bridge that could help figure out the existing code and make changes to it for other developers. Now, without you certainly can not do!
Individual work- there is no time to sit and work in pairs or organize other group activities. We need to make a working code faster, we get paid for it. This practice allows you not to share your knowledge and skills with others, which gives you the opportunity to stay at the same level as your teammates. Also, practice contributes to the narrow profile of knowledge in different areas of the product and thereby strengthens your confidence in the future.
Bicycle construction- as soon as you see the opportunity to implement somewhere from scratch, without using well-known tools and approaches, you should not miss this opportunity. In addition to the benefits of a similar framework of hatred frameworks, you significantly stretch the duration of the project. And the longer the project lasts, the more influence your other 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 must be able to quickly implement the tasks. Naturally without troubles on the quality of the code and other activities. Turn on the stream of consciousness and go! Then you will have the opportunity to reproach the rest with slowness and resist the introduction of new practices and approaches, which means it will protect your stable position from encroachments.
There are many other interesting practices in this wonderful methodology. You probably came 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 give your imagination a try ...
Conclusion
If you are a supporter of Agile, you should be prepared to deal with alternative methodologies, one of which is presented in the article. Your arsenal must include 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 JSDD adept, and then either attract him to your side or be able to get rid of him. Otherwise, your Agile deployment may stop before it starts ...