D E A D L I N E…

As a developer, this is one of your biggest nightmares or should I say your enemy? Name it whatever you want.

Admit it. It scares you a lot. Even now, while you are reading these sentences, it makes your hair stand on the end.

Wondering how I know that?

I know because I've felt the same. But now the fear is in the past. I've made peace with deadlines. I've embraced them.

So I suggest you do the same thing. Embrace them, make peace with them. This is the only way that you can defeat them.

Ok but, how you can do that?

There are some facts that we all tend to ignore when it comes to setting a deadline. My aim here is to show them to you so you can see that it takes so little to bury the fear and start enjoying life while you are working on your project without worrying about dates.

Work in a calm environment

Don't rush. Don't force anything.

The first thing first you should know is that you can't find your peace by setting unrealistic dates and forcing your team to work in a rush. There are companies that throw out big words and show unrealistic things to motivate their team to move forward. But while there are some facts obvious to everyone in the team, how can you expect them to believe in what you are saying if it is far away from reality?

Without a fixed - and most importantly believable - deadline, you can't work calmly. Yes, keeping the calm is the key here. When you don't trust the date, or when someone tells you to do everything within a limited period of time, or someone adds more tasks to the project without giving you more time, you start working maniacally. This is not work anymore. This is hell.

When you are under stress and pressure, you can't be productive. When you are calm, you are also conscious which means that you can make better decisions.

Our estimates suck

Windows users will remember that window dialog. The estimation in the dialog is exactly like our estimations, isn’t it?

Let’s admit it. Our estimates suck. We think we can guess how much time something will take. We have a tendency to believe that whatever we guess will come true.

However, generally, when we are guessing, we ignore some important factors that can affect our assumptions. Why? Because we are too optimistic.

To me, the first step in making peace with the deadline and getting better at setting deadlines is to admit that we are terrible estimators. When you embrace this fact, you will be conscious next time and it will prevent you from underestimating the requirements. And here is a solution for you to get better at estimating:

Divide the big things into smaller things. The smaller it is, the easier it is to estimate. This will increase your chances of having more accurate estimations.

Good enough is fine

“Perfect is the enemy of good.” — Voltaire

People like big challenges. We are best at finding a complicated solution for a simple problem. But here is a fact:

Every problem has its own simple solution that you probably ignore.

Don’t chase a perfect solution. Your first version doesn’t have to be perfect. Build a half product that can work. If you wait too much, you will waste your limited resources and precious time, or you will miss the deadline and even worse do nothing at all because you are chasing perfection. The solution is:

Find the solution that will bring you a lot of value and requires little effort. And don’t forget, good can be turned into great later.

Don’t be too optimistic. Be realistic.

I see managers that are too optimistic which makes them set optimistic deadlines to motivate the team. This is so wrong. I’m not telling you that you should be pessimistic about the future. On the contrary, I am telling you that you should be able to see every possibility that can create a bottleneck. Once you can see them, you can consider them and have a more accurate estimation.

There are different teams in the company. Engineering, business development, marketing, etc. When the business development team forces you to give them a deadline in the very near future, you shouldn’t get affected by them. They want their job to be done as soon as possible.

Remember that every team thinks about their own side.

Differentiate between “you have to do”, “you could do” and “you want to do”

Understanding is the key here. What are the core requirements for releasing your product? Usually, the product team has a hard time differentiating them.

When you have a meeting, one of the team members will say, “we could implement it, it will bring us that much value” or another one will say “We should put this into release.” They are looking from their own perspective. Ok, we can implement this and it can bring us some value, but the important question is that “do we need it now? In the first version?”

The answer is NO in most cases.

The things that you have to do are what you should focus on. Eliminate things you could do and you want to do. They are not even negotiable in most cases.

Say no by default

There is one important fact that we usually forget when we say “Yes” to something. We are saying no to the things we already need to complete.

When you say yes to something new, you’re not thinking about the impact it will have on your existing to do’s.

“Let’s add more tasks to the project after we’ve set the deadline. (Your project should get smaller over time, not larger.)”NO.

“We focused on what matters, ok. But what about the details? Let’s consider what kind of details we have that can make problems in the future.” NO. Ignore every detail for the first version. Don’t try to predict the future.

Finding more time for things isn’t the problem here. Too much stuff to do is the problem. Differentiate between “must-haves” and “nice-to-haves”.

The only way to get more done is to have less to do.

Never change the deadline

I see development teams with a bad habit that can affect their product development badly: deadline rescheduling.

When they miss the deadline, they set a new one. If they can’t meet this one, they set another one. When they do this repeatedly, it becomes a habit. Then this bad habit turns into their culture. Other teams in the company lose trust and question the developers’ work. Even worse, the developer team itself can lose trust in each other. In themselves as well.

Changing the deadline is essentially an admission of failure. It is making statements like, “We failed to plan requirements, we didn’t say no enough, we didn’t focus on what matters, we pushed our teams to do unreasonable things in an unreasonable time.”

Be aware that there will be always some problems

Being too optimistic causes you to ignore the fact that there may be some problems. Be aware. Probably something will go wrong. And this will cause you to lose some time on fixing things. So better to be prepared for bad scenarios. I am not saying that you should be pessimistic and you should try to predict the future and prepare yourself and your team for the unknown. Just find a balance between optimism and pessimism. Be realistic.

My experience showed me that, in software development, some things always go wrong. My advice to you is:

Add some time to your deadline before you set it by considering that something may go wrong.

Don’t add more people to a project

A lot of people think that they can speed up the process if they add more people to the project. However, they miss a very important point. Let’s remember Brooks’s law:

Adding human resources to a late software project makes it later. — Freed Brooks

According to Brooks on Wikipedia, there is an incremental person who, when added to a project, makes it take more, not less time. So why does it work this way?

• It takes some time for the people added to a project to become productive. You will have to educate them first. You have already limited human resources and you will have to dedicate those resources to educate new member. Also since they are new, they will introduce new bugs that move the project further away from completion.
• Communication overheads increase as the number of people increases.
• Adding more people to a highly divisible task, such as cleaning rooms in a hotel, decreases the overall task duration. However, other tasks including many specialties in software projects are less divisible. Another great example of this by Brooks is: while it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”.

Another bit of evidence from Richard Dalton to understand why adding more people is wrong is:

“Teams are immutable. Every time someone leaves or joins, you have a new team, not a changed team.” — Richard Dalton

Don’t procrastinate

Let me help you to understand what I mean. Last week, we had a meeting about defining the deadline for a new feature of our product. We were talking about which tasks are our priority and how we should implement them in an effective way.

There was a task on which we have heavily wasted our time. There were three ways to implement that task but somehow we were stuck. We couldn’t choose because developers were trying to predict the future. They were starting each sentence with “What if”.

You can’t predict what the future will bring you. Don’t over-prepare yourself for the unknown.

I am not talking about big technical decisions here. Of course, if you have to decide on your core technology, you should sleep on it to find the right solution. But don’t spend your time on small things. Uncertain things increase meetings and block your progress because your backend process is continuously working on them.

Don’t procrastinate it, decide on it and move forward.

Change your mentality from “Let’s think about it” to “Let’s decide now”. Decisions will speed up your progress. When something is decided, it will be clear to everyone in the team. Everyone will exactly know what to do.

Communicate: See where is the bottleneck?

You planned everything. You defined what to focus on and what to do. You know exactly how much time it will take (probably you will be wrong). So, the deadline has been settled. Is it enough?

NO.

As I mentioned above, there is always a possibility that something can go wrong. While your team members are working on their tasks, something can block them. Something can stop them to finish their tasks on time. You have to see where is the bottleneck and what it is.

Communication is the key here. You have to keep teams synced. Sometimes team members can go into a box and it can be very hard for them to see what is happening out of it. This is where you should enter the scene. Once you have identified the bottleneck, remove it so your team members can continue from where they were stuck.

I wish you to meet all deadlines:)

Thanks for reading.