PDD Principles - Panic Driven Development

Hello, Habr! Dear readers, this is a translation of a wonderful article by Mauro Frezza. I hope you enjoy it and keep you up to date on trends in development methodologies.



image


After the wave of success of the Agile family of development methodologies, few have stood the test of time. But among them there is one special technique: PDD Panic Driven Development - Development through panic .



This technique shares the basic tenets of Agile development methodology, but it is devoid of the unnecessary ceremony and technological load that only slows down the team's speed. Let's take a closer look at the principles of this methodology.



The newer the task, the higher the priority



As soon as a new task arises in the middle of a sprint, its priority soars over all previously planned work. After all, everything new is always better and more important. In general, this point should be included in the basic principles of the Agile methodology.



The focus on delivering value to the customer suggests that the team should put previously planned work aside and take care of new features.



We write exactly as much code as is required for the result



Developers make a living by writing code. Errors can only be corrected by code. Discussing design and UX only slows down development. Therefore, we do this: We write the solution, we make sure that the fix is ​​working. If everything is ok, then the problem is solved. Let's go further.



Don't rush to test



After the fix is ​​implemented, tests should be scheduled as pending tasks. Tests are useful, of course, but don't go overboard. You can take care of them later. Create a ticket and upload it to the backlog. To check the functionality, it is quite possible to do with manual testing.



Trust your senses



Programming is an art. Instincts and intuition are an integral part of any art. Listen to your heart. Write the solution. Roll it out more boldly. Only the brave is lucky.



The process must adapt to you



Any process of developing, testing, and releasing software is simply a set of conventions and rules. They are not set in stone. Critical fixes require flexibility. It is quite expected that to increase speed, processes will be changed to suit the needs of the team.



Everything comes from the manager



The team manager is empowered to speak up on development issues. All refactoring and all adherence to good practice can and should be overridden by business needs. Engineers, of course, can express their opinions, but in the end they should work for the needs transmitted to them from above.



Conclusion



PDD is a technique that rapidly increases the speed of teamwork in any project in the shortest possible time.



It is used in companies around the world and is the foundation for flexible and uncompromising programming.



All Articles