Let ME INTRODUCE MYSELF

I traveled here from Poland, specifically from Gdańsk—a city on the Baltic Sea.

I’ve been programming in PHP since 2007.

From time to time, I contribute to open-source projects;

throughout my career, I’ve made few contributions to Symfony, Doctrine, Gaufrette, and SymfonyDocs and Composer.

I am organizing polish PHP community "PHPers" meetups in Gdańsk

I work at                        as a tech lead, where I often help our clients work with existing (legacy) code, SOFTWARE DESIGN, SELECT ARCHITECTURES and support teamS developing their technical skillS

entropy AND Second Law of Thermodynamics

In a thermodynamically isolated system, there exists a state function that does not decrease over time. This function is called entropy.

It is impossible to have a process whose sole effect is to absorb energy and convert it entirely into an equivalent amount of work.

 What does this have to do with software development?

 Thesis 1:

It’s impossible to build a system that, if left unmaintained, will retain the same business value. Entropy does not decrease over time in isolated systems. ;)

System/Microservice = Isolated system.

Entropy = code rot, dependencies, accidental complexity, chaos — things suddenly stop working.
To increase entropy, it’s enough to do nothing—for example, not updating dependencies for three years.

 Thesis 2:

It is impossible to design a system in such a way that the effort (energy) developers invest in particular features can be directly converted into an equivalent amount of energy needed to deliver business value - some energy is always lost during that process

What is technical debt?

Consciously or unconsciously increasing the potential for entropy growth—or simply raising entropy in the code.

Conditions and behaviors that foster the creation of technical debt

Ignorance regarding code structure AND USED PACKAGES

• No static analysis tools (PHPStan, psalm, phpcsfixer)
• Missing configuration for IDE (no .editorconfig)
• No defined standard related with code structure in Team
• Use outdated packages

Projects that have been deployed to production without any plan for NEEDED support

• Lack of awareness among the business and decision-makers about the need for ongoing maintenance and support of operational projects, leading to an absence of allocated budgets

• Missing automation and documentation of project setup, so after release we lost much more time to do some fixes and improvements

Lack of knowledge about the prevailing communication within the company and silos between teams

• Missing knowledge about boundaries in company
• Lack of knowledge about company goals and targets
• Very poor coordination and management of how teams communicate within the company
• Micromanagement and ticket driven development
• Inter-departmental politics

Lack of automated tests

Very long intervals between deployments

• long-lived branches
• manual integration and deployments
• missing or not efficient CI/CD
• complicated branching policies
• no feature flags
• lack of knowledge about code review, QA and release process in team
• fossilized (rigid/outdated) deployment processes

PRESSURE

• Deadlines that cannot be exceeded due to the company’s obligations or legal requirements

• A company culture that doesn’t allow employees to give feedback to superiors and lacks procedures that empower employees to decide how to solve various problems.

• Lack of an MVP (Minimum Viable Product) approach and iterative, agile methodologies within the company

• Missing good leaders

MISSING business context within the development team

• Ticket driven development - get a ticket but do not why it is needed
• Lack of structured information from the business
• Team or some individuals behave in such way that is not treated as partners to discussion by business
• Business ignorance from team side
• Lack of a sense of agency by team

Excessive egos among some team members And poorly thought-out decisions CAUSE OF THAT EGOS

Insufficient self-confidence in making decisions

Fear of making changes IN

the code

• "broken windows theory"
• No tests, No static analysis
• Lack of clear ownership of the code, with code being passed between teams or shared by multiple teams
• Legacy code
• No code review
• Lack of ideas how to refactor code without breaking something

over engineering FOR SIMPLE PROBLEMS

Under engineering  FOR COMPLEX PROBLEMS

Insufficient KNOWLEDGE

• Missing trainings in company

• Team not attending for meetups and conferences

• Organizational constraints that prevent the company from hiring external consultants or agencies

• Lack of technical mentors

How can we address growing technical debt?

TEACH TEAM about Code STRUCTURE IMPORTANCE,  STATIC ANALYSIS TOOLS and IDE FEATURES

R AISE AWARENESS IN THE bUSINESS That SUPPORt Is IMPORTANT  

CREATE automation (FOR EXAMPLE AS COMPOSER SCRIPT, MAKEFILE, DEPANDABOT, RECTOR) and ADD DOCUMENTATION FOR TEAM NEAR THE CODE (LIVING DOCUMENATION WOULD BE THE BEST)

“Leave the cAMPSITE better than you found it.” - ScOUT RULE

Context Mapping, EVENT STORMING, IMPACT MAPPING AND OTHER WORKSHOPS WITH BUSINESS, TRY TO RAISE AGILITY IN TEAM AND BUSINESS

Maintaining so-called “internal quality,” for example by learning Automated tests AND FOR EXAMPLE TDD PRACTICE

• CHECK YOU branching POLICY

• TRY TO MERGE AS SOON AS POSSIBLE TO MAIN BRANCH, AND INTEGRATE OFTEN

• USE FEATURE FLAG WHEN NEEDED

• CODE REVIEW LOGIC AND IMPORTANT STUFF, REST OF IT AUTOMATE

• DOCUMENT YOUR PROCESSES

physical and mental health and well-being are important and affect code and technical debt

Clear communication within the company and explaining why the company makes certain decisions and why and for what purpose we set certain deadlines can help team build the right solution

We should teach the team to give and receive feedback

SELF-ORGANIZING TEAMS OR MORE INDEPENDENT TEAMS WITH CLEAR BOUNDARIES CAN MAKE THINGS BETTER

• INVEST IN KNOWLEDGE SHARING

• GO TO SOME CONFERENCES OR MEETUPS WITH YOUR TEAM (MEETUPS ARE OFTEN FREE AND YOU CAN GET SOME PIZZA ;) )

• GO TO SOME WORKSHOP OR ORGANIZE INTERNAL ONES

• BOOKS, BOOKS EVERYWHERE

CAN TECHNOLOGICAL DEBT BE AVOIDED?

NO

We can only mitigate it

SOMETIMES YOU HAVE TO LIVE WITH TECHNOLOGICAL DEBT SOMETIMES IT'S OK. IT'S BEST WHEN YOU DON'T HAVE TO PAY IT OFF