Meeting Deadlines at All Costs is a Mistake!

Table of Contents

The Necessity of Deadlines

Deadlines are necessary. Whether you work in Scrum (Agile) or a waterfall-like methodology, one thing is certain: without deadlines, there is no motivation. According to Parkinson’s Law (no relation to the disease), deadlines are essential.

The Problem with Rigid Deadline Adherence

The problem arises when it becomes apparent that a deadline cannot be met. The classic approach is to meet the deadline at all costs. This is a mistake!

The Dark Side of Meeting Deadlines at All Costs

Take a moment to consider the dark side of rigid deadline adherence…

(For those who don’t enjoy thinking for themselves, you may skip to the next section ;-) )

Commonly discussed consequences include:

  • Overtime (detrimental to mental health and inefficient—debatable),
  • Technical debt.

However, the consequences are more severe:

Teams That Meet Deadlines at All Costs Do Not Learn!

They learn that it’s acceptable to indulge in poor practices, inefficient work methods, and lack assertiveness if the deadline approaches and working hours are stretched while ignoring (or turning a blind eye to) quality. I call this Stress-Driven Development! :-)

Rigid Deadline Adherence Reinforces Poor Project Practices

It’s naive to believe that simply missing a deadline is a solution. It is not! By itself, it achieves nothing. Tools for drawing conclusions and implementing them are also necessary.

Facing the Reality of Unmet Deadlines

When you realize you will not meet a deadline, you must inform your team lead if you are a developer. If you are a team lead, tell the project manager. If you are the manager, inform the client and/or a higher-level manager/director—it may hurt. That’s why you often don’t do it; you prefer to be non-assertive or stretch your time or principles to meet the deadline. That’s the entire mechanism.

When it hurts (though there are less painful/painless methods), you will have a real chance to learn something. Then, you will truly grow and have the motivation to change the process instead of reinforcing its inefficiency.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Tags

Related Posts

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

The Natural Order of Refactoring Examined Part 4: Refactoring to Patterns

By following the steps outlined previously, we begin to see a more structured solution, predominantly consisting of methods grouped into classes. It’s now time to apply object-oriented principles, such as those encapsulated by the SOLID principles. We analyze the code for patterns of repetition, the need for flexibility, and code smells, and introduce design patterns where appropriate.

Read More

Make Room for Progress...

From the collection Poetry for Project Enthusiasts

Make Room for Progress

There is never a good time for the first child,
There is never a good time for the second child,
There is never a good time to build a house,
There is never a good time for renovations,
There is never a good time for a wedding,
There is never a good time to introduce refactoring,
And there is never a good time to start writing unit tests.
In each of these cases, you simply need to make a decision,
Start doing it, and time and resources will appear,
Because they will have to…

Read More
Programming with LLMs for programmers - Beyond the Hype

Programming with LLMs for programmers - Beyond the Hype

Introduction

The field of software development is currently abuzz with discussions about Large Language Models (LLMs), AI agents, and autonomous systems. New libraries and frameworks emerge daily, each promising to revolutionize our coding practices. However, amidst this flurry of buzzwords and complex tools, it’s easy to overlook that many programming tasks involving LLMs can be accomplished with a straightforward approach; it’s not rocket science. While crafting production-ready LLM-based systems is not trivial, using LLMs as part of a system is quite manageable, especially if you avoid over-reliance on the abundance of dedicated frameworks.

Read More