5 Tips to Avoid Short Deadlines and Prevent Bugs

1 – Learn how to say no

What developer has never worked with short deadlines? I believe most of us have already had this experience and, as you know, it’s extremely stressful!

Sometimes managers want to show numbers instead of quality. So what do we have to do? We have to say no! We can’t accept short deadlines.

Provide clear reasons against short deadlines – unnecessary stress, poor quality, and an increase of bugs! In the end, shorter deadlines can result in greater expenses for the company including overtime for developers and loss of credibility with clients.

If you don’t say no to short deadlines:

Master Yoda would say:
Your project, in chaos, will be.  Multiply, bugs will.

2 – Break up your task into sub-tasks

If your task seems too broad, you have to break it up! It is impossible to know how much time you will take to deliver a task if you don’t know exactly what it is.

If you don’t know the business rules, the database model, or the technology you will use, for sure you will take more time just to understand what you have to do. Remember, even breaking up the tasks will take time.

3 – Use a development methodology (SCRUM, XP, LEAN, KANBAN, etc)

Yes, use a development methodology. Using a methodology is much better than not. There are a lot of very good methodologies like SCRUM, Extreme Programming, Lean, and Kanban. You can mix and match parts of different methodologies and adapt them to your project.

For example, you can use SCRUM with KANBAN and use pair programming from the Extreme Programming methodology.

Pair programming is very useful. It can balance the team experience and developers can learn from each other. For complex tasks, it’s extremely useful. If you have never tried, when you do, you will think the same!

It’s easier to control software development with a methodology. You can define how much you can deliver on your “sprint”. Most times the sprint lasts 2 weeks.

4 – Use complex points! (Define the complexity of your task)

At first, break up all of your tasks so your team is capable of understanding what must be done. Once you have organized your tasks, you will assign a point to each task.

On SCRUM methodology, we use Fibonacci numbers, 1, 2, 3, 5, 8, 13, 21, 34, 55…

These numbers are very subjective. You can define your own pattern, but typically, it is like this:

• 1 to 2       – Easy
• 3 to 8       – Medium
• 13 to …    – Hard

 You must consider everything when you are defining complex points – business requirements, database model, architecture, dependencies with other projects, and technologies.

 5 – Be persuasive

It’s not enough to be only technical, many times we need to be persuasive to convince others of our ideas. Therefore, it’s great to develop our soft skills too! How can you convince your manager or your client if you don’t practice persuasion skills? Learn how to negotiate and save your project!

Books to read for learning how to be persuasive:

• Getting More, How You Can Negotiate to Succeed in Work and Life, Stuart Diamond
• Crucial Conversations, Tools for Talking When Stakes Are High Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler
• Influence, The Psychology of Persuasion, Robert B. Cialdini

If you don’t have enough time to read the books, just think about how a short deadline can damage the project and explain it. Make them understand they are making a mistake!