DEV Community

loading...

Practicing PDD - Panic Driven Development

maurofrezza profile image Mauro Frezza ・2 min read

After the initial wave of success of agile development techniques, one particular technique has survived and emerged throughout the years: PDD Panic Driven Development.
This technique shares the core concepts of agile development methodologies but removes all the ceremonies and process burden that reduces velocity in teams.
Let's see more in detail what are the principles of this methodology.

Recent issues have priority

Whenever a new issue comes up in the middle of the sprint, it takes priority over any planned work. New is always better and has higher priority. As a matter of fact it should be one of the principles of the agile development as well.
The focus on delivering value to customer requires the team to take care of new items and postpone previously defined work.

Write enough code to fix the issue

Developers write code for a living. Bugs can be fixed only by code. Design and UX discussion can only slow down the development. Code a solution first, verify your assumptions with the fix.
If the fix works, you solved the issue.

Tests should be a follow-up task

Once the fix is implemented, tests can be planned as a task to be done in the future. Tests are useful but not a priority. You can take care of them later. File a ticket and put it in the backlog.
Manual testing should enough to prove your fix.

Trust your instinct

Programming is art. Art has an intrinsic instinctive component. Trust your gut. Code your solution. Deploy it. Only the bold succeeds.

Process is flexible

Any process put in place to develop, test and release software is just a set of conventions and rules that are not written in stone. Critical fixes require different approaches. It is expected that you bend the process in order to act faster.

It’s a manager driven process

As part of one team, managers are entitled to give their opinions on development matters.
Refactoring or good practices can and should be overruled by business needs. Engineers can express their opinions but they should eventually commit to any need that comes from above.

Conclusion

PDD is a technique that can give great performance improvements in a short period time for every project.
It is practiced by several companies around the world. It represents the core of agile and extreme programming.

Discussion (4)

pic
Editor guide
Collapse
Sloan, the sloth mascot
Comment deleted
Collapse
maurofrezza profile image
Mauro Frezza Author

Ahem... I think I need to review my writing skills since this post was supposed to be sarcastic. I was actually making fun of the common misinterpretation of Agile methodologies and software development practices I've experienced.

I'm sorry you spent so much time writing this long response when we actually already agree on these things :D

I guess the software development world is really in bad shape if what I wrote can be seen as something that someone would take in consideration as a process to actually use.

Collapse
thejeff77 profile image
thejeff77

Haha that is awesome. Also very possible I'm dense. You did a great job of defining it at least. And.. I'm laughing now.

Was actually on my list to delete that since its a bit of a hot reply.

Collapse
rjaros profile image
Robert Jaros

Believe me, this technique was practiced even before the words "agile manifesto" were introduced to the world ;-)