PDD Manifesto

| Comments

Hi everyone.

I’ve been talking about PDD for a while. Pragmatism-Driven Development, a methodology that takes in account the development environment and the circumstances before of deciding the tools and the architectural decisions of your projects.

Pragmatic Driver Development

Some people asked me for the manifesto. And because I think that some people will appreciate another way of doing things more realistic, I started the first draft of that manifesto some time ago.

After discussions with the ecosystem where I work, finally, I can release the first version of the manifesto.

These are just some ideas, not a dogma, so please, don’t use them as the only way of doing things, making the same mistake again and again.

I will appreciate as well your constructive comments, so the real objective of that kind of things are, indeed, to make people more comfortable with their projects.

The more useful projects, the more knowledge shared, the more fun for everyone.

Be happy!

PDD Manifesto

Good practices

  • All good practice is only good if it is.
  • A good practice is good, indeed, if the executor knows it enough.
  • Otherwise, a good practice becomes always a bad practice; Ipso Facto.

Bad practices

  • All bad practice can be accepted, if, and only if, is well known by the executor.
  • Knowing them means to have a strict control of your current bad practices.
  • The absence of this control turns any bad practice in a poorly executed project.


  • Every project must be analyzed according to needs and own tools.
  • Accepting that these needs and tools are static is accepting their failure.
  • Starting a project destined to fail is the worst practice of all.


  • These needs can change along the time, so the tools have to change as well.
  • Internal and staff training is essential for the evolution of a team, and therefore a project.
  • All components of such team must evolve to self-acceptance and practice of good practices.