Skip to main content

Unreasonable Deadlines

“This is the last time I am doing overtime hours. It won’t happen again for sure.” You are thinking about this and in the meantime your team lead comes into the office and interrupts your thoughts with the similar story: ”Hey guys, only this time we need to do extra effort and after that we will be more concerned about deadlines.” Few months later, a new project and the same story. Sounds familiar? 


Reasons

This can be due to vary of reasons. Some of them could be:

  • Poor planning is reflected by inadequate scoping and requirements. Without a clear understanding what needs to be done, it's impossible to give a good estimate.
  • False optimism by decision makers. Tendency to not think about the details, thinking everything would go smoothly. But if something could go wrong, it will (always) ☺
  • Pressure from clients who are pushing for fast results to meet market demands.
  • Underestimating external dependencies. Not giving enough attention to the third party interface integration.
  • Hero Culture. Teams may embrace a toxic "work harder, not smarter" mentality, leading to overpromising and underdelivering.


What to do in order to fix it?

Allthough there is no silver bullet that can fix everything at once, some of the approaches that could help are:

  • Make communication more transparent. Encourage open discussions and stick to realistic goals.
  • Automate repetitive tasks. Automate testing and CI/CD pipelines.
  • Adopt agile practices. Divide scope, try to give realistic estimates on smaller pieces. Make use of retrospectives and reviews of previous projects.
  • Divide project to more deliverable portions. Clients would be happy to see that something is happening, and also would be able to give some initial feedback. On the other side, you will have clearer picture on what needs to be done and how fast it can be delivered.
  • Hold leaders accountable. Good leaders push back against unreasonable deadlines, first to maintain good team morale, and second to build trustworthiness with clients.


Conclusion

Unreasonable deadlines might seem unavoidable, but their long-term costs outweigh short-term gains. Foster realistic expectations, plan effectively, and communicate openly to build a sustainable, productive engineering culture. 



Labels:

Comments

Post a Comment

Popular posts from this blog

Design Patterns: Strategy

The Strategy Pattern is a behavioral design pattern that defines a family of algorithms, encapsulates each one, and makes them interchangeable. This pattern allows the algorithm to be selected at runtime, providing flexibility in designing software. It’s particularly useful when you have multiple ways of performing a task, and you want to choose the implementation dynamically without altering the client code. When To Use It? You Have Multiple Algorithms or Behaviors. Use it when you have a need for muplitple ways of performing a task, and you want to make these implementations interchangeable. Examples: Different sorting algorithms, payment methods, discount calculations... You Want to Eliminate Conditional Logic.  If you find yourself writing large if-else or switch statements to decide which algorithm to use, this pattern can simplify and clean up your code. Examples: A game character with different attack styles  You Need Runtime Flexibility.  Use this pattern if the ...
Post a Comment
Read more

Design Patterns: Builder

This is also, like a Singleton , one of the creational design patterns. It provides the way of creating complex objects step by step by simple chaining and every particular step is independent of other steps. Let us dive into the real example of usage. For showing purpose we have created an example in C# which creates simple SQL queries using described pattern.  using System; using System.Text; namespace BuilderPatternExample { public interface ISqlQueryBuilder { ISqlQueryBuilder Select(string columns); ISqlQueryBuilder From(string table); ISqlQueryBuilder Where(string condition); ISqlQueryBuilder OrderBy(string columns); string Build(); } public class SelectQueryBuilder : ISqlQueryBuilder { private readonly StringBuilder _queryBuilder; public SelectQueryBuilder() { _queryBuilder = new StringBuilder(); } public ISqlQueryBuilder Select(string columns) { ...
Post a Comment
Read more

Design Patterns: Singleton

Tyipically the first design pattern most people learn, often wrongly ☺ To give an introduction, we can say that singleton is one of the creational design patterns which ensures only one class instance with single point of access thru entire application.  Because it is relatively simple to implement, the Singleton pattern is sometimes misapplied in situations where it is not the most suitable choice. When to use it? Here are the few examples of corrent usage of singleton: Configuration Management  Centralized configuration settings for consistent use thru entire application Caching Maintaning  Single istance of cached objects for easy and fast acces Logging  Ensure unified mechanism to avoid duplication of log files, formats, etc Global State Management  Centralized management of the state which is needed to be shared accross the application Resource sharing  Thread pools, database connection, I/O operations When not to use it? On the other hand, here are fe...
Post a Comment
Read more