Rules of development talk given at the DrupalCon EU 2024 in Barcelona. Opinionated rules for software development.

1. Rules of development
And everything else for what matters

2. On the basics

3. Learn to read
Books, not online bat shit.
The worse book is better than any blog. Editorial
process.
In a world where no one reads, reading books will give
you expert knowledge in a subject in matter of weeks.
Incremental improvement. Compound gains.
Reclaim your capability to focus (not a caveman).

4. Know the basics
HTTP protocol and web caching.
Vanilla HTML/CSS/Javascript/PHP/…
Technical debt.
Basic design concepts. Everyone.
Diagrams, decision making and problem solving.
Systems thinking.

5. Start by making your bed
“Start your day with a task completed. If you want to
change your life and may be the world, start off by
making your bed. The simple act of making your bed
can give you the lift to start your day and provide you
the satisfaction to end it right.”
Admiral William H. McRaven

6. Sturgeon’s law
90% of everything is crud.

7. Shirky principle
Institutions will try to preserve the problem to which
they are the solution.

8. Postel’s law
Be conservative in what you do; be liberal in what you
accept from others.

9. Brandolini’s law
The amount of energy needed to refute bullshit is an
order of magnitude bigger than to produce it.

10. Hanlon’s razor
Never attribute to malice that which can be adequately
explained by stupidity.
Do not invoke conspiracy as explanation when ignorance
and incompetence will suffice, as conspiracy implies
intelligence.
Everyone has an agenda. Everyone has blind spots of
understanding.

11. Pareto principle
For many phenomena 80% of consequences stem from
20% of the causes.

12. Set you morals straight
What makes you always try your best?
Luke: Is the dark side stronger?
Yoda: No, no, no. Quicker, easier, more seductive.

13. On development

14. Start failing
Always (this means every single time) start
development with error and failing conditions.
Errors will always happen and can’t be avoided.
Have prepared an error handling strategy.
This way failure will always be graceful.
Nothing tells worse of you than an unhandled error
response. Or many.

15. Special cases
Special cases kill projects. They increase complexity so
much that the failures and bugs become unpredictable.

16. One is a case of many
One is a special case of many.
Single returns should be treated as multiple ones.

17. Shit happens
Sod’s law
If something can go wrong, it will.
Murphy’s law
Anything that can go wrong will go wrong.

18. Brook’s law
Adding manpower to a late software project makes it
later.
(What a developer does in one month, two developers do in
two months).

19. A team is not a person
A team is a loosely coupled system (agile definition),
not a tightly coupled system (a person), nor a heap.
Members of modern teams tend to be highly
specialised (tightly coupled).
No rockstars. No lone wolfs.

20. One ticket one thing
One ticket represents an indivisible issue.
Each ticket requires a new development instance.
Tickets are the smallest units of information in a PM
system. Everything else build up from here.

21. Single responsibility principle
Just take it seriously.

22. Software are complex systems
Systems are not the sum of their parts but the product
of their interactions.
Only interfaces matter. Define them, respect the, abode
by them. Anything else is easily fixable.

23. Complex systems run in degraded mode
Prioritise maintainability. It is the most important
factor on complex and lasting systems.
Complex systems contain changing mixtures of
failures latent within them.
Change introduces new forms of failure.

24. On maintainability
The only valid dev QA measurements are
maintainability and reliability.
No one will care about feature x if the application keeps
crashing.
And coding for maintainability will make you code well,
clean, beautiful.

25. On maintainability
“The central enemy of reliability is complexity.”
Geer et al.
“Simplicity is prerequisite for reliability.”
Edsger W. Dijkstra

26. On maintainability
“Always code as if the guy who ends up maintaining
your code will be a violent psychopath who knows
where you live.”
Rick Osborne

27. Development guidelines
Always start a project with a guidelines document
where common friction points are detailed
(indentation rules, local development environments,
rules for introducing new libraries, testing minimums,
code checking standards, etc).

28. On bugs
“Don’t track bugs, fix them.”
Allen Holub

29. On bugs
Bugs are first and foremost. Now, convince your PM.
Boy scout rule: always live the campament better than
when you found it.

30. On good development
“Good” developers are artisans, craftsmen. Beautiful.
I am an engineer. An average developer with good
principles. More scalable. Better team results. Become
an engineer.

31. On optimisation
“Humans build stuff as badly as possible, but not
worse.”
Jorge Lopez-Lago
It is an strategy that works pretty well… until it doesn’t.
When it doesn’t it is usually because we crossed the crap
line. An expert is someone that has failed many times. That
helps to estimate the crap line in projects.

32. Never start everything at the same time!
I have seen things… whole development teams coding
frantically, directed by the PM, before the architect
joins the project. Someone hired them early and they
must work (write code!) as they are being paid to warm
up their chairs.
The train can not stop: timber!#
This is agile! Iterate but never refactor… emergent
architecture.

33. On problem solving
“First, solve the problem. Then, write the code.”
John Johnson

34. On problem solving
“Successful problem solving requires finding the right
solution to the right problem. We fail more often
because we solve the wrong problem than because we
get the wrong solution to the right problem.”
Russell Ackoff

35. Problems are universal
Any problem is universal and can be addressed in many
ways. We box them when we apply our limited knowledge to
them. When doing this we restrict the range of solutions by
limiting it to a subset of the applicable knowledge.
Advances to any discipline are usually done by non experts
of such discipline.
“I did it because I didn’t know it could not be done” effect.
Therefore teams must be heterogeneous.

36. On technical debt
Cheap: code related.
Expensive: architecture and interfaces related.

37. On management

38. On estimations

39. Do not estimate
If you pretend you are doing agile (whatever that
means in your world).
If you must, estimate on time. Speak the language of
your management team.
“Points” were invented by developers so no precise
time estimations were given to project managers.

40. Do not estimate
Humans are terrible at estimating. The estimations
worsen with duration/length and distance.
It doesn't matter how you do it. It only matters to do it
consistently.
Work iteratively. Value and estimations inferred from
work (and previous estimations) done.

41. How to estimate (if you must)
All developers to take part.
Avoid pressure or lead from experienced ones.
Anonymous (just give it a go).
Learning opportunity.
No observers or managers. Private party for devs.

42. Tools to estimate
Cone of uncertainty.
Experience modifiers.
3 point estimation (optimistic, most likely,
pessimistic). Always share upwards the conservative
value.
Track estimations and results. Adjust. Repeat.

43. Dunning-Kruger effect
Cognitive bias in which unskilled individuals suffer
from illusory superiority, mistakenly rating their
ability much higher than average.
Or why people always estimate too low the work they
don't know how to do.

44. On risk

45. On risk analysis
Humans are terrible estimating risks (but better than
any other living creature).
Proximity overcomes any other factors in risk analysis.
Geographical, emotional, personal and economic
(immediate personal gain).

46. On risk management
Prepare for the consequences/disruptions, not for the
disasters. This way you will be prepared for everything
that can go wrong.

47. On testing

48. Dirty deeds done dirt cheap
Unit/integration/regression/smoke testing are part of
the developer’s responsibilities. Professional integrity.
Non negotiable.
Lie, if needed, to prevent testing being squeezed out of
your development work.

49. Test now
“A good plan today is better than a perfect one
tomorrow.”
General George Patton

50. Test now!
“A good plan test today is better than a perfect one
tomorrow.”
“Tomorrow never comes.” Proverb
Some testing, any testing, now it is better than perfect
testing never.

51. Automate your tests
Choose your flavour and tool and master them (TDD,
BDD, PHPUnit, SimpleTests, Selenium, etc). Get used to
coding tests as you code features (or before, up to you).
Tests are your QA metric, your benchmark for
improvements, your professional standard seal.
Identify your smoke tests and keep them updated.
And, for God's sake, test patches and bug fixes.

52. Metcalfe's law
“The value of a system grows as approximately the
square of the number of users of the system.”
The cost of interrelated or connected operations
increases exponentially with the number of
connections. Testing becomes more expensive as the
software grows and relations increase between
components.

53. Action points
Reduce friction to write tests. Minimise reasons,
opportunities and incentives to not do testing.
Make testing as cheap as possible.
Decouple it from infrastructure or delivery (local).
Simplify it so everyone can participate.
Plan your QA teams sensibly (Metcalfe’s law).

54. Be part of it

55. If you want to help
Send me your rules.
Explain briefly why and
how they were verified.
Help with translations.
Let’s do this amongst
humans, right?